From Bottorff@katebajic.co.uk Sat Sep 01 02:54:28 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRMsG-0004iY-Cd for ccamp-archive@ietf.org; Sat, 01 Sep 2007 02:54:28 -0400 Received: from ro1c24.net.upc.cz ([84.42.242.24]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRMsF-00066O-Pv for ccamp-archive@ietf.org; Sat, 01 Sep 2007 02:54:28 -0400 Received: from organiza-3df515 ([100.132.61.80]:19709 "EHLO organiza-3df515" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by ro1c24.net.upc.cz with ESMTP id S22FLLPRYQBMBXXJ (ORCPT ); Sat, 1 Sep 2007 08:55:19 +0200 Message-ID: <000901c7ec64$fe531150$18f22a54@organiza3df515> From: "booty Bottorff" To: Subject: mahali Date: Sat, 1 Sep 2007 08:54:51 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C7EC75.C1DBE150" 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_0009_01C7EC75.C1DBE150 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable http://toratto.com/ Mail to Bottorff Massive gains that my girlfriend loves pen hasanovic ------=_NextPart_000_0009_01C7EC75.C1DBE150 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
http://toratto.com/
Mail to Bottorff
Massive gains that my girlfriend = loves
pen hasanovic
------=_NextPart_000_0009_01C7EC75.C1DBE150-- From tgsworldbeater@worldwidetm.com Sat Sep 01 04:06:14 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRNzi-0007Kf-6K; Sat, 01 Sep 2007 04:06:14 -0400 Received: from [211.229.33.190] (helo=worldwidetm.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IRNzh-0008QL-6l; Sat, 01 Sep 2007 04:06:13 -0400 Message-ID: <000f01c7ecba$5fd9cd10$0766785c@choi> From: "Merlin Clayton" To: "ccamp-archive" Subject: We don't save your credit card information and can't even view it. Date: Sat, 1 Sep 2007 17:05:01 +0900 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 6.00.2800.2962 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 No more being shy of your manhood in the showers after gym or in public toilets. http://sadiik.com From Hack@willowdeneschool.co.uk Sat Sep 01 04:10:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRO3N-0001nZ-QG for ccamp-archive@megatron.ietf.org; Sat, 01 Sep 2007 04:10:01 -0400 Received: from host92-47-dynamic.57-82-r.retail.telecomitalia.it ([82.57.47.92]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRO3M-0008V3-Ks for ccamp-archive@megatron.ietf.org; Sat, 01 Sep 2007 04:10:01 -0400 Received: from p4 ([174.137.142.11]:27649 "EHLO p4" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by host92-47-dynamic.57-82-r.retail.telecomitalia.it with ESMTP id S22BGOIARFXWCOEO (ORCPT ); Sat, 1 Sep 2007 10:10:35 +0200 Message-ID: <000a01c7ec6f$7f6f3cf0$5c2f3952@p4> From: "Detlef Hack" To: Subject: skjrvi Date: Sat, 1 Sep 2007 10:10:02 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C7EC80.42F80CF0" 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.5 (+++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0005_01C7EC80.42F80CF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://topgaz.com/ Good morning Hack Testimonial: I enjoy my new 3 inch penis, even the orgasms are ten times = better. Amrat herzog ------=_NextPart_000_0005_01C7EC80.42F80CF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://topgaz.com/
Good morning Hack
Testimonial: I enjoy my new 3 inch penis, even = the=20 orgasms are ten times better.
Amrat herzog
------=_NextPart_000_0005_01C7EC80.42F80CF0-- From Jefford@adoptastray.ws Sat Sep 01 05:55:43 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRPhf-0006aI-Ix for ccamp-archive@megatron.ietf.org; Sat, 01 Sep 2007 05:55:43 -0400 Received: from siedlce8-tp.sdl.vectranet.pl ([195.117.151.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRPhe-0002XR-KA for ccamp-archive@megatron.ietf.org; Sat, 01 Sep 2007 05:55:43 -0400 Received: by 10.103.238.103 with SMTP id mAMarAvmZpJde; Sat, 1 Sep 2007 11:55:50 +0200 (GMT) Received: by 192.168.186.143 with SMTP id DjbypVJpcVZDIy.6718877751881; Sat, 1 Sep 2007 11:55:48 +0200 (GMT) Message-ID: <000b01c7ec7e$442fb480$289775c3@jagi> From: "Cecelia Jefford" To: Subject: sarelucs Date: Sat, 1 Sep 2007 11:55:45 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C7EC8F.07B88480" 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_0006_01C7EC8F.07B88480 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable http://afrae.com/ Good morning Cecelia Women love strong and confident men nikke Ninua ------=_NextPart_000_0006_01C7EC8F.07B88480 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
http://afrae.com/
Good morning Cecelia
Women love strong and confident = men
nikke Ninua
------=_NextPart_000_0006_01C7EC8F.07B88480-- From sgsgfsopi@pa-loesenbeck.de Sat Sep 01 07:42:21 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRRMr-00073I-IN for ccamp-archive@ietf.org; Sat, 01 Sep 2007 07:42:21 -0400 Received: from 20158022152.user.veloxzone.com.br ([201.58.22.152]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRRMo-0006AW-Bx for ccamp-archive@ietf.org; Sat, 01 Sep 2007 07:42:21 -0400 Received: from super ([187.188.183.97]:16385 "EHLO super" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 20158022152.user.veloxzone.com.br with ESMTP id S22ZSIKPZTHHULBU (ORCPT ); Sat, 1 Sep 2007 08:42:52 -0300 Message-ID: <000401c7ec8d$26328f20$98163ac9@super> From: "jules sgsgfs" To: ccamp-archive@ietf.org Subject: obidicut Date: Sat, 1 Sep 2007 08:42:17 -0300 Message-ID: <000401c7ec8d$26328f20$98163ac9@super> 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.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Antivirus: avast! (VPS 000770-2, 01/09/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 3.1 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea News to jules Now im not shy in the public toilets Buzz Maginot http://arrabya.com/ From slyons_fd@ey.com Sat Sep 01 10:02:46 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRTYk-0008QF-NE; Sat, 01 Sep 2007 10:02:46 -0400 Received: from [86.123.160.147] (helo=businesstalkradio.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRTYk-0001MO-1B; Sat, 01 Sep 2007 10:02:46 -0400 Date: Sat, 01 Sep 2007 07:05:15 -0700 To: pwe3@ietf.org Bcc: ccamp-archive@ietf.org, mailman@ietf.org, imss-bounces@ietf.org, gsmp@ietf.org, disman-bounces@ietf.org From: "Sabrina Lyons" MIME-Version: 1.0 Message-ID: <1188655515.0279@ey.com> Subject: SAVE $ ~ Buy Prescription Rx Medication Online DISCREETLY .... lkwaqc3m98 Content-Type: multipart/alternative; boundary="----=_NextPart_000_09B3_D8D8BF5D.448D6165" X-Spam-Score: 2.1 (++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 This is a multi-part message in MIME format. ------=_NextPart_000_09B3_D8D8BF5D.448D6165 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit Save your $ Pharmacy : Pick the meds you want to order & checkout (2 steps to finish an order) : Fast delivery & discrete packaging to your doorstep : We sell both BRAND(100% original brand) & GENERIC(35% cheaper) : We give up to 70% discount (on retail shop price) for BOTH brand & generic meds : Meds we sell: Cia|lisViagra, UltramAtivan, CelebrexSoma, MeridiaClenbuterol, LuvoxPaxilZoloft & other 20 popular meds View all medications we have http://bfr.keonecard.com http://btf.keonecard.com ------=_NextPart_000_09B3_D8D8BF5D.448D6165 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: 8bit
Save your $ Pharmacy
: Pick the meds you want to order & checkout (2 steps to finish an order)
: Fast delivery & discrete packaging to your doorstep
: We sell both BRAND(100% original brand) & GENERIC(35% cheaper)
: We give up to 70% discount (on retail shop price) for BOTH brand & generic meds
: Meds we sell: Cia|lisViagra, UltramAtivan, CelebrexSoma, MeridiaClenbuterol, LuvoxPaxilZoloft & other 20 popular meds


View all medications we have (1st link)
If above link not load up, try this (2nd link)




pronunciation food bread better. god better captain day handwriting truly pay? c873l53onja ayolqf2p32k ------=_NextPart_000_09B3_D8D8BF5D.448D6165-- From mbxa0hzuu@typepad.com Sat Sep 01 10:05:30 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRTbO-0005Il-K5 for ccamp-archive@ietf.org; Sat, 01 Sep 2007 10:05:30 -0400 Received: from pool-151-196-186-65.balt.east.verizon.net ([151.196.186.65] helo=fzthwxc) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IRTbO-0001RE-CO for ccamp-archive@ietf.org; Sat, 01 Sep 2007 10:05:30 -0400 To: From: "Adrian Dedra" Subject: World Class Rep|icaWatches at LowPrice $189 - Breitling, CartierR0LEX & .. tigf Message-ID: <46287f99477.53846m39870464@typepad.com> Date: Sat, 01 Sep 2007 09:05:30 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--n5uin0vbqkwm8wbmv4tivwbusjtl" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da ----n5uin0vbqkwm8wbmv4tivwbusjtl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Super Branded Watches (85% Price Off) : RolexMen : RolexLady : Alain Silberstein : Audemars Piguet : Breitling : Bvlgari : Cartier : Chanel : Chopard : Franck Muller : IWC : Jaeger-Lecoultre : Omega : Panerai Luminor : Patek Philippe : Tag Heuer Only from $189 Each :- Click below link http://rnma.keonecard.com http://rwcitc.keonecard.com ----n5uin0vbqkwm8wbmv4tivwbusjtl Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Super Branded Watches (85% Price Off)
RolexMen
RolexLady
Alain Silberstein
Audemars Piguet
Breitling
Bvlgari
Cartier
Chanel
Chopard
Franck Muller
IWC
Jaeger-Lecoultre
Omega
Panerai Luminor
Patek Philippe
Tag Heuer
Only from $189 Each :- Click below link
[Link 1]     [Link 2]

become books edge suddenly learned goes sandwich. happened person captain embarrass appearance gym.
----n5uin0vbqkwm8wbmv4tivwbusjtl-- From shenrey@laserdir.com Sat Sep 01 10:16:36 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRTm8-00020q-Cr; Sat, 01 Sep 2007 10:16:36 -0400 Received: from [59.24.41.108] (helo=[59.24.41.108]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRTm7-0001io-TN; Sat, 01 Sep 2007 10:16:36 -0400 Received: from [59.24.41.108] by mail.laserdir.com; Sat, 32 Aug 2007 23:16:33 +0900 Message-ID: <00dfffa4$00dffe78$6c29183b@shenrey> From: "Levi Temple" To: Subject: Since taking your product, i am completely cured of impotence! Date: Sat, 32 Aug 2007 23:16:33 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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.2905 X-Spam-Score: 1.8 (+) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Ever wanted to ejaculate 5 times more? http://lfesaver.com From domingosizemore_wh@myrealbox.com Sat Sep 01 11:09:18 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRUb8-0006fX-A0; Sat, 01 Sep 2007 11:09:18 -0400 Received: from [59.14.247.66] (helo=gm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRUb6-0001e8-KV; Sat, 01 Sep 2007 11:09:18 -0400 Date: Sat, 01 Sep 2007 08:09:21 -0700 Message-ID: <1188659361.3369@myrealbox.com> From: "Domingo Sizemore" Subject: SAVE $ ~ Buy Prescription Rx Medication Online DISCREETLY .... qhu6x33705d2y1n516 MIME-Version: 1.0 To: idr-admin@ietf.org Bcc: ccamp-archive@ietf.org, mailman@ietf.org, mipshop@ietf.org, midcom@ietf.org Content-Type: multipart/alternative; boundary="----=_NextPart_000_0D16_2E900525.EC724C4B" X-Spam-Score: 4.0 (++++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 This is a multi-part message in MIME format. ------=_NextPart_000_0D16_2E900525.EC724C4B Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit Save your $ Pharmacy : Pick the meds you want to order & checkout (2 steps to finish an order) : Fast delivery & discrete packaging to your doorstep : We sell both BRAND(100% original brand) & GENERIC(35% cheaper) : We give up to 70% discount (on retail shop price) for BOTH brand & generic meds : Meds we sell: Cia|lisViagra, UltramAtivan, CelebrexSoma, MeridiaClenbuterol, LuvoxPaxilZoloft & other 20 popular meds View all medications we have http://bfr.keonecard.com http://btf.keonecard.com ------=_NextPart_000_0D16_2E900525.EC724C4B Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: 8bit
Save your $ Pharmacy
: Pick the meds you want to order & checkout (2 steps to finish an order)
: Fast delivery & discrete packaging to your doorstep
: We sell both BRAND(100% original brand) & GENERIC(35% cheaper)
: We give up to 70% discount (on retail shop price) for BOTH brand & generic meds
: Meds we sell: Cia|lisViagra, UltramAtivan, CelebrexSoma, MeridiaClenbuterol, LuvoxPaxilZoloft & other 20 popular meds


View all medications we have (1st link)
If above link not load up, try this (2nd link)




may likely truly modern; horses your towards quickly towards towards miss? q8dauu2jsd 703blt3drnvf ------=_NextPart_000_0D16_2E900525.EC724C4B-- From a_todd_gs@wal-mart.com Sat Sep 01 11:12:38 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRUeK-0005cq-4b; Sat, 01 Sep 2007 11:12:37 -0400 Received: from 59-104-143-68.adsl.dynamic.seed.net.tw ([59.104.143.68] helo=btinternet.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRUeH-00038R-HH; Sat, 01 Sep 2007 11:12:36 -0400 Date: Sat, 01 Sep 2007 08:14:43 -0700 MIME-Version: 1.0 Message-ID: <1188659683.8404@wal-mart.com> From: "Alissa Todd" To: midcom@ietf.org Bcc: ipsec-bounces@ietf.org, spirits-archive@ietf.org, dccp@ietf.org, kink-archive@ietf.org, ccamp-archive@ietf.org, mailman@ietf.org Subject: SAVE $ ~ Buy Prescription Rx Medication Online DISCREETLY .... ft2gfs54rn2i15acv Content-Type: multipart/alternative; boundary="----=_NextPart_000_0272_398E63AF.88BADACA" X-Spam-Score: 3.7 (+++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 This is a multi-part message in MIME format. ------=_NextPart_000_0272_398E63AF.88BADACA Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit Save your $ Pharmacy : Pick the meds you want to order & checkout (2 steps to finish an order) : Fast delivery & discrete packaging to your doorstep : We sell both BRAND(100% original brand) & GENERIC(35% cheaper) : We give up to 70% discount (on retail shop price) for BOTH brand & generic meds : Meds we sell: Cia|lisViagra, UltramAtivan, CelebrexSoma, MeridiaClenbuterol, LuvoxPaxilZoloft & other 20 popular meds View all medications we have http://bfr.keonecard.com http://btf.keonecard.com ------=_NextPart_000_0272_398E63AF.88BADACA Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: 8bit
Save your $ Pharmacy
: Pick the meds you want to order & checkout (2 steps to finish an order)
: Fast delivery & discrete packaging to your doorstep
: We sell both BRAND(100% original brand) & GENERIC(35% cheaper)
: We give up to 70% discount (on retail shop price) for BOTH brand & generic meds
: Meds we sell: Cia|lisViagra, UltramAtivan, CelebrexSoma, MeridiaClenbuterol, LuvoxPaxilZoloft & other 20 popular meds


View all medications we have (1st link)
If above link not load up, try this (2nd link)




truly easy handwriting easy, truly pronunciation quickly truly lady between clear, jhf937m8torm3l 2ejsfr12av ------=_NextPart_000_0272_398E63AF.88BADACA-- From w_boswell_mq@unisys.com Sat Sep 01 13:16:31 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRWaF-0003ap-Sp; Sat, 01 Sep 2007 13:16:31 -0400 Received: from [61.128.110.110] (helo=maersk.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRWaF-0000YF-0L; Sat, 01 Sep 2007 13:16:31 -0400 Date: Sat, 01 Sep 2007 10:19:13 -0700 To: kink-archive@ietf.org Bcc: ietf-announce-admin@ietf.org, ftp@ietf.org, isms-request@ietf.org, iesg-request@ietf.org, dccp@ietf.org, ccamp-archive@ietf.org, mailman@ietf.org From: "Wilson Boswell" Message-ID: <1188667153.9402@unisys.com> MIME-Version: 1.0 Subject: SAVE $ ~ Buy Prescription Rx Medication Online DISCREETLY .... e879ia1dfcjlz1z Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A7C_35E7EAA9.AAE7EF55" X-Spam-Score: 2.1 (++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 This is a multi-part message in MIME format. ------=_NextPart_000_0A7C_35E7EAA9.AAE7EF55 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit Save your $ Pharmacy : Pick the meds you want to order & checkout (2 steps to finish an order) : Fast delivery & discrete packaging to your doorstep : We sell both BRAND(100% original brand) & GENERIC(35% cheaper) : We give up to 70% discount (on retail shop price) for BOTH brand & generic meds : Meds we sell: Cia|lisViagra, UltramAtivan, CelebrexSoma, MeridiaClenbuterol, LuvoxPaxilZoloft & other 20 popular meds View all medications we have http://bfr.keonecard.com http://btf.keonecard.com ------=_NextPart_000_0A7C_35E7EAA9.AAE7EF55 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: 8bit
Save your $ Pharmacy
: Pick the meds you want to order & checkout (2 steps to finish an order)
: Fast delivery & discrete packaging to your doorstep
: We sell both BRAND(100% original brand) & GENERIC(35% cheaper)
: We give up to 70% discount (on retail shop price) for BOTH brand & generic meds
: Meds we sell: Cia|lisViagra, UltramAtivan, CelebrexSoma, MeridiaClenbuterol, LuvoxPaxilZoloft & other 20 popular meds


View all medications we have (1st link)
If above link not load up, try this (2nd link)




between lady easy between; son central remember towards may modern understand. t41c0pgbi1 49hzgoudlpqh1 ------=_NextPart_000_0A7C_35E7EAA9.AAE7EF55-- From Kenn144@nupix.net Sat Sep 01 13:23:11 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRWgh-000252-ES for ccamp-archive@megatron.ietf.org; Sat, 01 Sep 2007 13:23:11 -0400 Received: from [189.12.190.132] (helo=18912193227.user.veloxzone.com.br) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRWgf-0007SQ-OM for ccamp-archive@megatron.ietf.org; Sat, 01 Sep 2007 13:23:11 -0400 Received: from lite_extreme ([177.103.44.25]:23406 "EHLO lite_extreme" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 18912193227.user.veloxzone.com.br with ESMTP id S22OFBGYOXNEVQOR (ORCPT ); Sat, 1 Sep 2007 02:45:27 -0300 Message-ID: Date: Sat, 1 Sep 2007 02:45:04 -0300 From: "Kenn Ramos" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ccamp-archive@megatron.ietf.org Subject: llezim Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.7 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Mail to Ramos My wife complains about my small pe*nis Intharachai Churochkin http://www.arrabya.com/ From fhensonrb@bnpparibas.com Sat Sep 01 15:45:10 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRYu5-0003ho-VW; Sat, 01 Sep 2007 15:45:10 -0400 Received: from [196.44.152.195] (helo=ups-scs.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRYu1-0004yA-Ao; Sat, 01 Sep 2007 15:45:09 -0400 From: "Francis Henson" Subject: SAVE $ ~ Buy Prescription Rx Medication Online DISCREETLY .... vhx4322bl0tzx1ibm MIME-Version: 1.0 To: idr-admin@ietf.org Bcc: ietf-announce-admin@ietf.org, ftp@ietf.org, isms-request@ietf.org, iesg-request@ietf.org, dccp@ietf.org, kink-archive@ietf.org, ccamp-archive@ietf.org Date: Sat, 01 Sep 2007 12:47:49 -0700 Message-ID: <1188676069.7590@bnpparibas.com> Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A67_7B170D13.94BC6682" X-Spam-Score: 2.1 (++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 This is a multi-part message in MIME format. ------=_NextPart_000_0A67_7B170D13.94BC6682 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit Save your $ Pharmacy : Pick the meds you want to order & checkout (2 steps to finish an order) : Fast delivery & discrete packaging to your doorstep : We sell both BRAND(100% original brand) & GENERIC(35% cheaper) : We give up to 70% discount (on retail shop price) for BOTH brand & generic meds : Meds we sell: Cia|lisViagra, UltramAtivan, CelebrexSoma, MeridiaClenbuterol, LuvoxPaxilZoloft & other 20 popular meds View all medications we have http://bfr.keonecard.com http://btf.keonecard.com ------=_NextPart_000_0A67_7B170D13.94BC6682 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: 8bit
Save your $ Pharmacy
: Pick the meds you want to order & checkout (2 steps to finish an order)
: Fast delivery & discrete packaging to your doorstep
: We sell both BRAND(100% original brand) & GENERIC(35% cheaper)
: We give up to 70% discount (on retail shop price) for BOTH brand & generic meds
: Meds we sell: Cia|lisViagra, UltramAtivan, CelebrexSoma, MeridiaClenbuterol, LuvoxPaxilZoloft & other 20 popular meds


View all medications we have (1st link)
If above link not load up, try this (2nd link)




your quickly truly towards. modern your horses better quickly food captain, ccpf3pm6qi m70ntigzs3 ------=_NextPart_000_0A67_7B170D13.94BC6682-- From avelasquezpu@amh.auracom.com Sat Sep 01 16:07:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRZFE-0006HG-VB; Sat, 01 Sep 2007 16:07:01 -0400 Received: from dsl212-143-226-147.bb.netvision.net.il ([212.143.226.147] helo=vispa.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRZFD-0005VO-38; Sat, 01 Sep 2007 16:07:00 -0400 From: "Arturo Velasquez" MIME-Version: 1.0 Subject: SAVE $ ~ Buy Prescription Rx Medication Online DISCREETLY .... g9pr5a2od7n Date: Sat, 01 Sep 2007 13:10:13 -0700 Message-ID: <1188677413.3192@amh.auracom.com> To: ietf-announce-admin@ietf.org Bcc: ftp@ietf.org, isms-request@ietf.org, iesg-request@ietf.org, dccp@ietf.org, kink-archive@ietf.org, ccamp-archive@ietf.org, mailman@ietf.org Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B6F_686F37B6.00D1B19D" X-Spam-Score: 2.1 (++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 This is a multi-part message in MIME format. ------=_NextPart_000_0B6F_686F37B6.00D1B19D Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit Save your $ Pharmacy : Pick the meds you want to order & checkout (2 steps to finish an order) : Fast delivery & discrete packaging to your doorstep : We sell both BRAND(100% original brand) & GENERIC(35% cheaper) : We give up to 70% discount (on retail shop price) for BOTH brand & generic meds : Meds we sell: Cia|lisViagra, UltramAtivan, CelebrexSoma, MeridiaClenbuterol, LuvoxPaxilZoloft & other 20 popular meds View all medications we have http://bfr.keonecard.com http://btf.keonecard.com ------=_NextPart_000_0B6F_686F37B6.00D1B19D Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: 8bit
Save your $ Pharmacy
: Pick the meds you want to order & checkout (2 steps to finish an order)
: Fast delivery & discrete packaging to your doorstep
: We sell both BRAND(100% original brand) & GENERIC(35% cheaper)
: We give up to 70% discount (on retail shop price) for BOTH brand & generic meds
: Meds we sell: Cia|lisViagra, UltramAtivan, CelebrexSoma, MeridiaClenbuterol, LuvoxPaxilZoloft & other 20 popular meds


View all medications we have (1st link)
If above link not load up, try this (2nd link)




clear truly god god, son hurrying son horses lady modern foot, ariwcselgpqf3c 90f8yu2x3nwq ------=_NextPart_000_0B6F_686F37B6.00D1B19D-- From owner-ccamp@ops.ietf.org Sat Sep 01 17:42:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRajZ-0008MJ-HQ for ccamp-archive@ietf.org; Sat, 01 Sep 2007 17:42:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRajY-00058E-9i for ccamp-archive@ietf.org; Sat, 01 Sep 2007 17:42:25 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IRabj-000OYK-A2 for ccamp-data@psg.com; Sat, 01 Sep 2007 21:34:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [212.23.8.67] (helo=fizeau.zen.co.uk) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IRabg-000OX8-LE for ccamp@ops.ietf.org; Sat, 01 Sep 2007 21:34:18 +0000 Received: from [212.23.3.141] (helo=heisenberg.zen.co.uk) by fizeau.zen.co.uk with esmtp (Exim 4.50) id 1IRabg-0004SV-3T for ccamp@ops.ietf.org; Sat, 01 Sep 2007 21:34:16 +0000 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1IRabf-0004m8-8v for ccamp@ops.ietf.org; Sat, 01 Sep 2007 21:34:15 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 1 Sep 2007 22:34:14 +0100 Message-ID: <05d001c7ecdf$cd82ec00$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Communication from OIF on MEF UNI Date: Sat, 1 Sep 2007 22:32:39 +0100 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-OriginalArrivalTime: 01 Sep 2007 21:34:14.0990 (UTC) FILETIME=[D80C5EE0:01C7ECDF] X-Originating-Heisenberg-IP: [88.96.235.138] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Hi, We have received a very constructive communication from the OIF wrt our work on the MEF UNI. You can see it at www.olddog.co.uk/ccamp.htm Can I encourage the authors of the various MEF-related I-Ds to follow up on the actions agreed in Chicago. Cheers, Adrian === Mr. Adrian Farrel, IETF CCAMP Co-Chair, adrian.farrel@aria-networks.com Ms. Deborah Brungard, IETF CCAMP Co-Chair, dbrungard@att.com Cc: Mr. Ross Callon, IETF Routing Area Director, rcallon@juniper.net Mr. David Ward, IETF Routing Area Director, dward@cisco.com Mr. Lyndon Ong, Ciena Corporation, lyong@ciena.com From: Mr. Jim Jones, OIF TC Chair Subject: Liaison to IETF CCAMP WG on MEF services support Dear Adrian and Deborah, The OIF has been engaged in discussion with the MEF since April 2005 regarding MEF UNI service definitions and how these might be supported over a UNI control plane interface. During this discussion a number of mutual conclusions have been reached on the requirements for signaling MEF UNI parameters using the control plane, and the relationship of control plane and management plane interfaces at the MEF UNI. Some of the control plane protocol issues that were identified have been socialized with IETF CCAMP WG through liaisons and informal communications between participants in OIF and CCAMP, and have resulted in work discussed in CCAMP. OIF plans to make use of this work in its future documents; in particular, the MEF Ethernet Traffic Parameters and EVPL label formats and switching type (provided in draft-ietf-ccamp-ethernet-traffic-parameters- 02.txt and draft-berger-ccamp-gmpls-mef-uni-00.txt, respectively). While we recognize that the second draft identified has not yet been formally adopted as a Working Group draft, definition of the EVPL label formats and switching type defined in the draft meet needs that we have identified for support of MEF services in the control plane. We appreciate CCAMP's efforts in this area and hope to continue productive interaction in the future. Thank you. Sincerely yours, Jim Jones OIF Technical Committee Chair From owner-ccamp@ops.ietf.org Sat Sep 01 17:42:27 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRajb-0008MV-4a for ccamp-archive@ietf.org; Sat, 01 Sep 2007 17:42:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRajZ-00058I-N7 for ccamp-archive@ietf.org; Sat, 01 Sep 2007 17:42:27 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IRaYj-000OKB-LU for ccamp-data@psg.com; Sat, 01 Sep 2007 21:31:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [212.23.8.67] (helo=fizeau.zen.co.uk) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IRaYe-000OJn-G3 for ccamp@ops.ietf.org; Sat, 01 Sep 2007 21:31:11 +0000 Received: from [212.23.3.141] (helo=heisenberg.zen.co.uk) by fizeau.zen.co.uk with esmtp (Exim 4.50) id 1IRaYd-0000LT-Js for ccamp@ops.ietf.org; Sat, 01 Sep 2007 21:31:07 +0000 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1IRaYc-0003WE-73 for ccamp@ops.ietf.org; Sat, 01 Sep 2007 21:31:06 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 1 Sep 2007 22:31:05 +0100 Message-ID: <05cf01c7ecdf$5cb5a9e0$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: liaison response to to IETF ccamp WG on MFA Forum MPLS CNI Date: Sat, 1 Sep 2007 22:22:17 +0100 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-OriginalArrivalTime: 01 Sep 2007 21:31:05.0759 (UTC) FILETIME=[674202F0:01C7ECDF] X-Originating-Heisenberg-IP: [88.96.235.138] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 73f7847c44628482de9d5f1018acf469 Hi, We have received the attached liaison from the MFA. I expect it will be posted on the IETF web site in due course. In the mean time, you can find it at www.olddog.co.uk/ccamp.htm The liaison does not ask for any action from us, but we may want to review the new specification and comment on it. Thanks, Adrian ----- Original Message ----- From: "J. Rao Cherukuri" To: ; ; ; Cc: "David Sinicrope (RL/TNT)" ; ; "BOCCI Matthew" ; "Ross Callon" ; ; Sent: Friday, August 31, 2007 8:34 PM Subject: liaison response to to IETF ccamp WG on MFA Forum MPLS CNI Hi Adrian, Deborah, Thank you and the CCAMP WG for providing such thorough and valuable comments. We have reviewed and incorporated many of them into the CNI document. There are a few that we have not incorporated for various reasons. We have provided the rationale for these decisions inline below. Please let us know if you have any questions or concerns. Best Regards, David Sinicrope AD Working Group Chair Rao Cherukuri TC Chair *************************************** We note that you have opted to define a new RSVP object to support a multi-class LSP following the rules for vendor private assignment as described in section 2.2 of RFC3936. We believe that you may have misinterpreted the purpose of vendor private extensions since such extensions are specifically not intended to interoperate, but you are attempting to define a specification directly for the purpose of interworking devices from different vendors. In your case it would seem to make more sense to define a standardized extension to the protocol. MFAF> At the time of development of our specification draft-andersson was not adopted by IETF. Also, the Multi Class specification wasn't in a state where we could refer to it. Consequently, we chose to use the vendor private TLV to expedite completion of our document. In subsequent revisions of the CNI we will consider following draft-andersson and obtaining a standard Multi Class TLV. Should you decide that a standardized extension is better able to deliver the functionality that you require, we should like to draw your attention to draft-andersson-rtg-gmpls-change-06.txt that defines how other SDOs may influence the development of MPLS and GMPLS protocols within the IETF, and which is currently in IETF last call. The (G)MPLS suites of protocols have become popular among multiple SDOs resulting in a need for IETF to clarify its role as the responsible SDO for (G)MPLS protocol extensions so as to prevent unnecessary replication of functionality and the resulting interoperability problems. 1. The document is marked as Straw Ballot Text. Can you tell us what that means the status of the work is? MFAF> Review is completed and document is in "last call". 2. We think that your use of terminology may be a little loose. In many cases, where you say "MPLS" you are probably referring to the data plane, and specifically a packet-switching data plane with an MPLS encapsulation. But in other cases, "MPLS" and "MPLS-TE" are synonymous and refer to a signaling/routing control plane using the MPLS-TE extensions to RSVP and to the two IGPs OSPF and IS-IS. In many cases you say "GMPLS-TE" which is not something we specifically recognise although we can assume that you mean simply "GMPLS". Sometimes, where you are trying to distinguish a TE LSP established using MPLS-TE from one set up using GMPLS you may intend to say "GMPLS TE-LSP" rather than "GMPLS-TE LSP". We feel that close attention to the terminology may help clarify the document. MFAF> We have gone through the document and reflected your suggestions in the text. 3. Section 1.1 states: The purpose of this specification is to define an MPLS-based Client to Network Interconnect (CNI) for establishing GMPLS Traffic Engineered (TE) Label Switched Paths (LSPs). Can we assume that this means that the client-to-client LSPs are established using GMPLS protocols, but that the signaling within the core network is out of scope? Especially since section 1.2 states: At the CNI, it is not desirable to have the client equipment participate in the internal control protocols of the MPLS network. MFAF> We have reflected this suggestion in the text of section 1.2. 4. Can you clarify why you have selected GMPLS protocols and not MPLS-TE protocols on which to build your CNI. We are not opposed to this, but are seeking to understand the choice. Perhaps the main reason is the requirement for bidirectional LSPs. MFAF> To facilitate use of bi-direction LSPs and to leverage existing implementations of the standard. We have reflected this rationale in the text of section 1.2. 5. Can you clarify whether the core network is assumed to be PSC only? That is, for example, if the CNI encoding is POS, would it be acceptable for the PE and the rest of the core network to switch the LSP as TDM until the remote PE or even CE, or do you require that the PE must perform packet switching? If the PE must perform packet switching, is it still acceptable for the core LSP (PE-PE) to be switched at some other technology? MFAF>We assume that the core is PSC only. The CNI is implemented at the edge of the network. Details of the core network beyond what is stated in section 1.3 are beyond the scope of the CNI. 6. Section 1.3 states: Where the network uses MPLS-TE signaling, the PE routers are expected to perform the translation. It is our opinion that this translation is non-trivial and may be impossible for some of the GMPLS services that are available at the CNI. For example, supporting a bidirectional service over an MPLS-TE signaling network requires additional coordination between the end-points that is currently not available in the MPLS-TE extensions to RSVP-TE. From the following text in section 7.1, we assume that the PE may refuse a CNI request if it is unable to provide the required level of function. The transport network in the provider network is a GMPLS or MPLS-TE based packet switched network that must support request for uni-directional LSPs and may support requests for bi-directional LSPs MFAF> In section 1.3 we state that the core has support for a minimum set of GMPLS capabilities. e.g., bidirectional LSP support, traffic engineering QoS capabilities. 7. Section 2.1 The correct expansion of "GMPLS" is "Generalized Multiprotocol Label Switching". In view of you chosen expansion of "MPLS", you may prefer to show this as "Generalized Multi Protocol Label Switching". The correct expansion of "FEC" is "Forwarding Equivalence Class". MFAF> We have reflected this suggestion in the text. See the Acronyms section. 8. Section 7.2 states: The CE and PE nodes are inter-connected by point-to-point interfaces. The signaling channel is "in-band", i.e., the labeled packets share the same access connection as the RSVP-TE signaling. This is an acceptable, but not required, method of deploying GMPLS-based signaling. It is our suspicion reading this very short section that it is your intention to forbid the use of the IF_ID RSVP_HOP Object at the CNI. Can you confirm or deny this? MFAF> At our last meeting in Chicago we decided to allow the use of the IF_ID_RSVP_HOP as an option. See section 7.2. 9. Section 7.3 states: A client need only know its own address, a reachable address of the adjacent PE-node, and know the address of any other client to which it wishes to connect. The addresses listed above must be configured on each client. A PE need only know (and track) the addresses on interfaces attached to clients, as well as the Node IDs of these attached clients. In addition, the IP/MPLS network needs to know reachability to the interface addresses and Node IDs of other PEs to which an attached client is permitted to connect. This appears to miss the fact that the client will address a CNI connection request to a remote client address. The local PE must, therefore, know how to route to these client addresses that are outside the core routing domain. Perhaps the final sentence should say CE not PE? But in 9.1.2 you have: When a PE receives a Path message from a client that contains no ERO indicating transit network selection, then the PE is responsible for progressing the Path message toward the destination. The progression of the Path message is beyond the scope of this specification. While the details are clearly out of scope, it *is* relevant to the definition of the CNI how the core acquires and distributes the client-side addressing information that is necessary for routing across the core. You will observe that the problem you are solving (including the fact that the client addresses may come from an address space that overlaps with the core address space) is similar to the L3VPN problem. MFAF> We corrected the text to address this issue in section 7.3. Also see the changes in section 9.1.2. 10. What is the expected behavior from the core network when an E-LSP is requested at the CNI? Can we assume that the expectation is that an appropriate E-LSP will also be established across the core so that Diffserv behavior will be performed along the whole length of the client-client connection, or is this not a requirement? If core Diffserv behavior is required, how will the core handle the presence of multiple classes? MFAF>This is assumed and although how it is done is beyond the scope of the specification, section 7.4.1 now states what is expected of the network. 11. You are correct to observe that the ERO is optional in GMPLS implementations (sections 9.1.1 and 9.1.2), however, since you are specifying a profile for use at the CNI, and since both the CE and the PE must be CNI-aware (i.e., you cannot simply use legacy implementations) you may find it convenient to mandate support of the ERO at the CNI. We believe that in practice all implementations support ERO. MFAF> We still do not mandate ERO because there was no agreement within the MFAF TC to mandate it. See changes made in 9.1.2. 12. In section 9.1.1 you have: The client populates the ERO object with only one sub-object containing an Autonomous System Number (ASN) representing a transit network beyond the originating service provider. The client equipment must set the ASN sub-object 'L' bit to 1, indicating a loose route. It is not completely clear what is meant by 'the originating service provider', but we assume that this refers to the network that the ingress PE belongs to. In this case, this ERO is malformed and will be rejected. The first sub-object of a received ERO must always define an abstract node that the receiver is a member of. See RFC 3209, section 4.3.4.1, point 1). MFAF> We reflected this in section 9.1.1. 13. In section 9.4: PE next to a client receives a PathErr with Path_State_Removed from the network, it may in turn generate either a ResvTear or PathTear, whichever is applicable, to be sent to the client. There are no circumstances in which a PE receiving a PathErr with Path_State_Removed from the network would send PathTear to the client. It is unclear to us why you would specify that the CNI built on GMPLS might not use this standard GMPLS procedure. MFAF>We reflected this in section 9.4. 14. In section 9.5.3: The Extended Classtype object is signaled in the Path message, and saved in the Path State Block (PSB) at every hop. We recommend that you simply state that the state is stored as every hop. The existence of a PSB is implementation- specific. Can you please clarify "at every hop". Are you expecting nodes in the core network to store this information. If so, you should note that the core nodes will not recognize the object class and will reject any messages carrying it. We also suggest that before progressing your own extensions for multi-class DSTE LSPs you should look at the existing work within the IETF: http://www.ietf.org/internet-drafts/draft-minei-diffserv-te-multi-class- 02.txt . If this work is not adequate for your requirements, we would encourage you to work with its authors to produce a single standardized solution within the IETF. MFAF>We removed all references to PSB, and all reference to "at every hop". This better aligns with our scope of not specifying the network internals. See section 9.5.3. 15. In 9.5.4: An LSR that recognizes the Extended Classtype object and that receives a Path message which contains the Extended Classtype object but which does not contain a Label Request object or which does not have a session type of LSP_Tunnel_IPv4, must send a PathErr message towards the sender with the error code 'extended-classtype Error' and an error value of 'Unexpected Extended Classtype object'. These are defined below: Why do you define new parsing behavior for the absence of a Label Request object (by the way, you should say Generalized Label Request object, since this is GMPLS)? The absence of mandatory objects is already covered in RFC2205. MFAF> We removed the reference to "the absence of (Generalized) Label Request object". This implies that if the Generalized Label Request object is missing, the relevant procedures of RFC 2205 will be performed. 16. The error code defined in 9.5.4 is conformant with RFC 3936. You may wish to look at draft-swallow-rsvp-user-error-spec in case this gives you the ability to handle more detailed private error codes. MFAF> In our specifications we are limited to referring only to documents that have been progressed to the RFC editor queue and beyond. We will certainly consider reference to draft-swallow-rsvp-user-error-spec in future revisions of the CNI. Finally, we would like to refer you to draft-kumaki-ccamp-mpls-gmpls-interwork-reqts-01.txt and draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-01.txt for the latest state of discussions in CCAMP with respect to interworking MPLS and GMPLS networks. MFAF> Thanks for pointing out these documents. We will consider these should our work scope be expanded to include details of the core network and MPLS and GMPLS interworking. Attachment(s): From gavin_washington_au@jci.com Sat Sep 01 17:42:57 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRak5-0008TW-SO; Sat, 01 Sep 2007 17:42:57 -0400 Received: from [196.46.100.57] (helo=access.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRak3-0007MT-CE; Sat, 01 Sep 2007 17:42:57 -0400 To: bmwg-admin@ietf.org Bcc: isms-request@ietf.org, iesg-request@ietf.org, dccp@ietf.org, kink-archive@ietf.org, ccamp-archive@ietf.org, mailman@ietf.org Date: Sat, 01 Sep 2007 14:46:13 -0700 MIME-Version: 1.0 From: "Gavin Washington" Message-ID: <1188683173.5395@jci.com> Subject: SAVE $ ~ Buy Prescription Rx Medication Online DISCREETLY .... ij0wb31k4x6c13i Content-Type: multipart/alternative; boundary="----=_NextPart_000_031B_0BC95B60.F968E62B" X-Spam-Score: 2.1 (++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 This is a multi-part message in MIME format. ------=_NextPart_000_031B_0BC95B60.F968E62B Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit Save your $ Pharmacy : Pick the meds you want to order & checkout (2 steps to finish an order) : Fast delivery & discrete packaging to your doorstep : We sell both BRAND(100% original brand) & GENERIC(35% cheaper) : We give up to 70% discount (on retail shop price) for BOTH brand & generic meds : Meds we sell: Cia|lisViagra, UltramAtivan, CelebrexSoma, MeridiaClenbuterol, LuvoxPaxilZoloft & other 20 popular meds View all medications we have http://bfr.keonecard.com http://btf.keonecard.com ------=_NextPart_000_031B_0BC95B60.F968E62B Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: 8bit
Save your $ Pharmacy
: Pick the meds you want to order & checkout (2 steps to finish an order)
: Fast delivery & discrete packaging to your doorstep
: We sell both BRAND(100% original brand) & GENERIC(35% cheaper)
: We give up to 70% discount (on retail shop price) for BOTH brand & generic meds
: Meds we sell: Cia|lisViagra, UltramAtivan, CelebrexSoma, MeridiaClenbuterol, LuvoxPaxilZoloft & other 20 popular meds


View all medications we have (1st link)
If above link not load up, try this (2nd link)




horses teacher second towards; page horses hurrying horses handwriting central your, 766zdx2msrmq1 0ghnfxvf1582 ------=_NextPart_000_031B_0BC95B60.F968E62B-- From j_burger_cp@bungi.com Sat Sep 01 21:14:23 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRe2h-00079m-MU; Sat, 01 Sep 2007 21:14:23 -0400 Received: from pc-240-72-214-201.cm.vtr.net ([201.214.72.240] helo=myrealbox.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRe2S-0005PD-4a; Sat, 01 Sep 2007 21:14:23 -0400 Date: Sat, 01 Sep 2007 18:16:39 -0700 MIME-Version: 1.0 From: "Jerrod Burger" Message-ID: <1188695799.5837@bungi.com> Subject: SAVE $ ~ Buy Prescription Rx Medication Online DISCREETLY .... vt4lseuywk9t3l6z30a To: spirits-archive@ietf.org Bcc: kink-archive@ietf.org, ccamp-archive@ietf.org, mailman@ietf.org, idr-admin@ietf.org, bmwg-admin@ietf.org, magma-request@ietf.org Content-Type: multipart/alternative; boundary="----=_NextPart_000_05CB_2BE5A362.8FE3A7E3" X-Spam-Score: 2.1 (++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 This is a multi-part message in MIME format. ------=_NextPart_000_05CB_2BE5A362.8FE3A7E3 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit Save your $ Pharmacy : Pick the meds you want to order & checkout (2 steps to finish an order) : Fast delivery & discrete packaging to your doorstep : We sell both BRAND(100% original brand) & GENERIC(35% cheaper) : We give up to 70% discount (on retail shop price) for BOTH brand & generic meds : Meds we sell: Cia|lisViagra, UltramAtivan, CelebrexSoma, MeridiaClenbuterol, LuvoxPaxilZoloft & other 20 popular meds View all medications we have http://bfr.kethena.com http://brf.kethena.com ------=_NextPart_000_05CB_2BE5A362.8FE3A7E3 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: 8bit
Save your $ Pharmacy
: Pick the meds you want to order & checkout (2 steps to finish an order)
: Fast delivery & discrete packaging to your doorstep
: We sell both BRAND(100% original brand) & GENERIC(35% cheaper)
: We give up to 70% discount (on retail shop price) for BOTH brand & generic meds
: Meds we sell: Cia|lisViagra, UltramAtivan, CelebrexSoma, MeridiaClenbuterol, LuvoxPaxilZoloft & other 20 popular meds


View all medications we have (1st link)
If above link not load up, try this (2nd link)




god towards son between, horses handwriting may mistress second understand captain. v3m8i011cqd 2eowjo1m7h2u2v ------=_NextPart_000_05CB_2BE5A362.8FE3A7E3-- From sgastongx@elistas.net Sat Sep 01 22:44:52 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRfSG-0003g2-Dh; Sat, 01 Sep 2007 22:44:52 -0400 Received: from [125.134.10.58] (helo=northstate.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRfSF-00071R-Lv; Sat, 01 Sep 2007 22:44:52 -0400 Date: Sat, 01 Sep 2007 19:44:56 -0700 MIME-Version: 1.0 Subject: SAVE $ ~ Buy Prescription Rx Medication Online DISCREETLY .... 9zpozf3q32ecf To: spirits-archive@ietf.org Bcc: isms-request@ietf.org, iesg-request@ietf.org, dccp@ietf.org, kink-archive@ietf.org, ccamp-archive@ietf.org, mailman@ietf.org From: "Shari Gaston" Message-ID: <1188701096.9946@elistas.net> Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B65_B5E59A02.E9E21EAE" X-Spam-Score: 2.2 (++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 This is a multi-part message in MIME format. ------=_NextPart_000_0B65_B5E59A02.E9E21EAE Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit Save your $ Pharmacy : Pick the meds you want to order & checkout (2 steps to finish an order) : Fast delivery & discrete packaging to your doorstep : We sell both BRAND(100% original brand) & GENERIC(35% cheaper) : We give up to 70% discount (on retail shop price) for BOTH brand & generic meds : Meds we sell: Cia|lisViagra, UltramAtivan, CelebrexSoma, MeridiaClenbuterol, LuvoxPaxilZoloft & other 20 popular meds View all medications we have http://bfr.kethena.com http://brf.kethena.com ------=_NextPart_000_0B65_B5E59A02.E9E21EAE Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: 8bit
Save your $ Pharmacy
: Pick the meds you want to order & checkout (2 steps to finish an order)
: Fast delivery & discrete packaging to your doorstep
: We sell both BRAND(100% original brand) & GENERIC(35% cheaper)
: We give up to 70% discount (on retail shop price) for BOTH brand & generic meds
: Meds we sell: Cia|lisViagra, UltramAtivan, CelebrexSoma, MeridiaClenbuterol, LuvoxPaxilZoloft & other 20 popular meds


View all medications we have (1st link)
If above link not load up, try this (2nd link)




towards easy central food; quickly captain page your handwriting understand food. tndsto3bu59 nblado37xf8 ------=_NextPart_000_0B65_B5E59A02.E9E21EAE-- From t_osbornnx@crescenet.com Sat Sep 01 23:52:55 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRgW7-00036O-Fb; Sat, 01 Sep 2007 23:52:55 -0400 Received: from m73.net81-64-215.noos.fr ([81.64.215.73] helo=naviu.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRgW6-0000PM-P6; Sat, 01 Sep 2007 23:52:55 -0400 Date: Sat, 01 Sep 2007 20:55:28 -0700 From: "Tabitha Osborn" To: midcom@ietf.org Bcc: ftp@ietf.org, isms-request@ietf.org, iesg-request@ietf.org, dccp@ietf.org, kink-archive@ietf.org, ccamp-archive@ietf.org, mailman@ietf.org MIME-Version: 1.0 Message-ID: <1188705328.3211@crescenet.com> Subject: SAVE $ ~ Buy Prescription Rx Medication Online DISCREETLY .... hc31sz2c6in5lzxkq943 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0405_30398033.0FE80133" X-Spam-Score: 2.4 (++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 This is a multi-part message in MIME format. ------=_NextPart_000_0405_30398033.0FE80133 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit Save your $ Pharmacy : Pick the meds you want to order & checkout (2 steps to finish an order) : Fast delivery & discrete packaging to your doorstep : We sell both BRAND(100% original brand) & GENERIC(35% cheaper) : We give up to 70% discount (on retail shop price) for BOTH brand & generic meds : Meds we sell: Cia|lisViagra, UltramAtivan, CelebrexSoma, MeridiaClenbuterol, LuvoxPaxilZoloft & other 20 popular meds View all medications we have http://bfr.kethena.com http://brf.kethena.com ------=_NextPart_000_0405_30398033.0FE80133 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: 8bit
Save your $ Pharmacy
: Pick the meds you want to order & checkout (2 steps to finish an order)
: Fast delivery & discrete packaging to your doorstep
: We sell both BRAND(100% original brand) & GENERIC(35% cheaper)
: We give up to 70% discount (on retail shop price) for BOTH brand & generic meds
: Meds we sell: Cia|lisViagra, UltramAtivan, CelebrexSoma, MeridiaClenbuterol, LuvoxPaxilZoloft & other 20 popular meds


View all medications we have (1st link)
If above link not load up, try this (2nd link)




pay better pay affect? pronunciation clear teacher clear clear food towards, nac3pqilwkg80f xz7ag23cqnp ------=_NextPart_000_0405_30398033.0FE80133-- From tara_mathiesen@cemetalsa.e.telefonica.net Sun Sep 02 00:50:24 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRhPk-0003tF-Cy for ccamp-archive@ietf.org; Sun, 02 Sep 2007 00:50:24 -0400 Received: from s01060016172edda7.ss.shawcable.net ([70.64.127.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRhPi-0006c5-Td for ccamp-archive@ietf.org; Sun, 02 Sep 2007 00:50:24 -0400 Received: from otv-5fac7000e22 ([136.185.47.188]:1698 "EHLO otv-5fac7000e22" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by S01060016172edda7.ss.shawcable.net with ESMTP id S22SWOADLVCCLPSO (ORCPT ); Sat, 1 Sep 2007 22:49:16 -0600 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 1 Sep 2007 22:48:58 -0600 To: ccamp-archive@ietf.org From: "tara mathiesen" Subject: rmatosis Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 4.3 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea News to tara My peni$ grew 2’’ after 5 months of use itai Harriman http://www.atasru.com/ From lba3htncg@panalpina.com Sun Sep 02 01:08:57 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRhhh-0005YY-HF for ccamp-archive@ietf.org; Sun, 02 Sep 2007 01:08:57 -0400 Received: from 68-116-202-47.dhcp.oxfr.ma.charter.com ([68.116.202.47] helo=glroa) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IRhhg-0001q2-56 for ccamp-archive@ietf.org; Sun, 02 Sep 2007 01:08:57 -0400 To: From: "Frances Brandy" Subject: 80% Save Codeine,Valiun,XanaK,AmbienK,PhenterminK,ViagraK,CialiK,SomaK ty Message-ID: <22353p89561.553w48026388@panalpina.com> Date: Sun, 02 Sep 2007 01:08:07 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--41knrfaherrvtbhryq63c4ru1x1bm" X-Spam-Score: 4.0 (++++) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 ----41knrfaherrvtbhryq63c4ru1x1bm Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit PharmaShop 80% Discount - Discreet Packaging - Cheapest Medication - Worldwide shipping - Buy in Bulk and Save CodeineK XanaxK ValiumK PhenterminK ViagraK ViagraGelK CialiK CialiKSoftTabs ViagraSoftTabsK SomaK AdalatK AllegraK AmbienK AtaraxK AtivanK CiproK EffexorK GlucophageK LevitraK LipitorK MeridiaK NorvascK PaxilK PropeciaK ProzacK UltramK ZocorK ZoloftK ZybanK plus 30 meds more http://ktym.kethena.com (Link 1) http://kiadk.kethena.com (Link 2) ----41knrfaherrvtbhryq63c4ru1x1bm Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
PharmaShop 80% Discount
Discreet Packaging
Cheapest Medication
Worldwide shipping
Buy in Bulk and Save
CodeineK
XanaxK
ValiumK
PhenterminK
ViagraK
ViagraGelK
CialiK
CialiKSoftTabs
ViagraSoftTabsK
SomaK
AdalatK
AllegraK
AmbienK
AtaraxK
AtivanK
CiproK
EffexorK
GlucophageK
LevitraK
LipitorK
MeridiaK
NorvascK
PaxilK
PropeciaK
ProzacK
UltramK
ZocorK
ZoloftK
ZybanK
plus 30 meds more
Buy Here - start from (link A)
(link B)

conduct winter stopping wrong showed least lot. wood yellow food,



----41knrfaherrvtbhryq63c4ru1x1bm-- From hanna_rq@jci.com Sun Sep 02 02:18:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRinC-0007mb-Us; Sun, 02 Sep 2007 02:18:42 -0400 Received: from 12-205-220-33.client.mchsi.com ([12.205.220.33] helo=btinternet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRinB-00087S-Gu; Sun, 02 Sep 2007 02:18:42 -0400 Subject: SAVE $ ~ Buy Prescription Rx Medication Online DISCREETLY .... v9cxn41we3vby1no0r Message-ID: <1188714038.2141@jci.com> Date: Sat, 01 Sep 2007 23:20:38 -0700 From: "Sue R. Hanna" To: bmwg-admin@ietf.org Bcc: ftp@ietf.org, isms-request@ietf.org, iesg-request@ietf.org, dccp@ietf.org, kink-archive@ietf.org, ccamp-archive@ietf.org, mailman@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C2_7EEFC7D4.06A13E60" X-Spam-Score: 3.8 (+++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 This is a multi-part message in MIME format. ------=_NextPart_000_00C2_7EEFC7D4.06A13E60 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit Save your $ Pharmacy : Pick the meds you want to order & checkout (2 steps to finish an order) : Fast delivery & discrete packaging to your doorstep : We sell both BRAND(100% original brand) & GENERIC(35% cheaper) : We give up to 70% discount (on retail shop price) for BOTH brand & generic meds : Meds we sell: Cia|lisViagra, UltramAtivan, CelebrexSoma, MeridiaClenbuterol, LuvoxPaxilZoloft & other 20 popular meds View all medications we have http://bfr.kethena.com http://brf.kethena.com ------=_NextPart_000_00C2_7EEFC7D4.06A13E60 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: 8bit
Save your $ Pharmacy
: Pick the meds you want to order & checkout (2 steps to finish an order)
: Fast delivery & discrete packaging to your doorstep
: We sell both BRAND(100% original brand) & GENERIC(35% cheaper)
: We give up to 70% discount (on retail shop price) for BOTH brand & generic meds
: Meds we sell: Cia|lisViagra, UltramAtivan, CelebrexSoma, MeridiaClenbuterol, LuvoxPaxilZoloft & other 20 popular meds


View all medications we have (1st link)
If above link not load up, try this (2nd link)




captain mistress foot miss. god remember handwriting handwriting between understand better; u82l692p9h5s tdihtc34ib ------=_NextPart_000_00C2_7EEFC7D4.06A13E60-- From Hjerling@itncustoms.com Sun Sep 02 03:42:02 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRk5q-0008V3-Ri for ccamp-archive@megatron.ietf.org; Sun, 02 Sep 2007 03:42:02 -0400 Received: from aln66.neoplus.adsl.tpnet.pl ([83.26.43.66]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRk5l-0005Ex-8X for ccamp-archive@megatron.ietf.org; Sun, 02 Sep 2007 03:42:02 -0400 Received: by 10.125.221.35 with SMTP id DetMqFDxoozJz; Sun, 2 Sep 2007 09:43:02 +0200 (GMT) Received: by 192.168.179.116 with SMTP id tXnUCvyrHObTpO.2218341029096; Sun, 2 Sep 2007 09:43:00 +0200 (GMT) Message-ID: <000801c7ed34$e16ba900$422b1a53@monia1gmyybonh> From: "Janos Hjerling" To: Subject: ykkylven Date: Sun, 2 Sep 2007 09:42:57 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7ED45.A4F47900" 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 000771-1, 2007-09-01), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 2.0 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0003_01C7ED45.A4F47900 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable http://atgsth.com/ Good morning ccamp-archive I am sooo big now thanks to these pills Irvin Kellers ------=_NextPart_000_0003_01C7ED45.A4F47900 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
http://atgsth.com/
Good morning ccamp-archive
I am sooo big now thanks to these = pills
Irvin Kellers
------=_NextPart_000_0003_01C7ED45.A4F47900-- From karhu@edwardmcgettigan.com Sun Sep 02 10:38:27 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRqap-0002uL-Fk for ccamp-archive@ietf.org; Sun, 02 Sep 2007 10:38:27 -0400 Received: from [88.246.198.32] (helo=dsl88-246-49162.ttnet.net.tr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRqao-0005L5-5M for ccamp-archive@ietf.org; Sun, 02 Sep 2007 10:38:27 -0400 Received: from casper-07ae30ab ([188.104.25.125]:29097 "EHLO casper-07ae30ab" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by dsl88-246-49162.ttnet.net.tr with ESMTP id S22DDLWLAJARHGIL (ORCPT ); Sun, 2 Sep 2007 17:38:36 +0300 Message-ID: <000301c7ed6e$ea61c550$0ac0f658@casper07ae30ab> From: "Carciumaru karhu" To: Subject: ereruelf Date: Sun, 2 Sep 2007 17:38:23 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C7ED88.0FAEFD50" 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.6 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0004_01C7ED88.0FAEFD50 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable http://www.ejhunt.com/ Wazzup Carciumaru wow, its so much bigger now Mertz Hosseinnejad ------=_NextPart_000_0004_01C7ED88.0FAEFD50 Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable
http://www.ejhunt.com/
Wazzup Carciumaru
wow, its so much bigger now
Mertz Hosseinnejad
------=_NextPart_000_0004_01C7ED88.0FAEFD50-- From Korp@edwardmcgettigan.com Sun Sep 02 10:40:18 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRqcc-0003Sg-IT for ccamp-archive@megatron.ietf.org; Sun, 02 Sep 2007 10:40:18 -0400 Received: from [88.246.198.32] (helo=dsl88-246-49162.ttnet.net.tr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRqca-0000zQ-N9 for ccamp-archive@megatron.ietf.org; Sun, 02 Sep 2007 10:40:18 -0400 Received: from casper-07ae30ab by edwardmcgettigan.com with ASMTP id 7BABF703 for ; Sun, 2 Sep 2007 17:40:33 +0300 Received: from casper-07ae30ab ([170.109.186.53]) by edwardmcgettigan.com with ESMTP id 7ABDE2B3AF3B for ; Sun, 2 Sep 2007 17:40:33 +0300 Message-ID: <000601c7ed6f$2cc43f40$0ac0f658@casper07ae30ab> From: "Herbert Korp" To: Subject: erabika Date: Sun, 2 Sep 2007 17:40:15 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C7ED88.52117740" 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.6 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0006_01C7ED88.52117740 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable http://equiphi.com/ Yo ccamp-archive wow, its so much bigger now Khalid Bettenhausen ------=_NextPart_000_0006_01C7ED88.52117740 Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable
http://equiphi.com/
Yo ccamp-archive
wow, its so much bigger now
Khalid Bettenhausen
------=_NextPart_000_0006_01C7ED88.52117740-- From ygpoison@agassi.com Sun Sep 02 18:58:26 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRyOg-000801-K8 for ccamp-archive@ietf.org; Sun, 02 Sep 2007 18:58:26 -0400 Received: from [59.12.252.10] (helo=agassi.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IRyOf-0006ev-Kl for ccamp-archive@ietf.org; Sun, 02 Sep 2007 18:58:26 -0400 Received: from Pdvr [185.240.86.225] (port=30256 helo=Pdvr) by afc0c3bagassi.com (8.12.8/8.12.8) with SMTP id 8119460012FB64 for ; Mon, 3 Sep 2007 08:09:39 +0900 Message-ID: <001301c7ee01$c683c190$0192f9b4@Pdvr> From: desirable To: ccamp-archive@ietf.org Subject: hbetter Date: Mon, 3 Sep 2007 08:09:39 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C7EE01.C683C190" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.181 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.1409 X-Spam-Score: 2.1 (++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C7EE01.C683C190 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable being woven. As opposed to weaving on graph paper by hand, the exist yet. It has been able to avoid fading out of public view = required, yet curriculums are now being augmented with courses ------=_NextPart_000_0010_01C7EE01.C683C190 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable

With respect to the affects of technology on society, we have

Are you wanting a bigger pe n _is?

As see -n on TV

Over 779,000 Men around the world are already satisfied
Gain 2+ Inches In Leng _th
Increase Your P _enis Wi _dth (Girth) By up _to 23%
100% Safe To Take, With NO Side Effects
No Pum _ps! No Sur _gery! No Exer _cises!
*3 FREE Bottles Of M -eg a Di -k

Convenience and efficiency complement each other, and together
------=_NextPart_000_0010_01C7EE01.C683C190-- From qglance@sysnet.net Sun Sep 02 19:03:31 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRyTb-0004Dy-Qo for ccamp-archive@ietf.org; Sun, 02 Sep 2007 19:03:31 -0400 Received: from host-89-229-7-207.torun.mm.pl ([89.229.7.207] helo=drgcomp.torun.mm.pl) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IRyTZ-0006ks-5z for ccamp-archive@ietf.org; Sun, 02 Sep 2007 19:03:29 -0400 Received: from drgcomp ([94.211.179.17] helo=drgcomp) by cf07e559sysnet.net (8.12.6/8.12.6) with SMTP id 28146012963A8 for ; Mon, 3 Sep 2007 01:03:03 +0200 Message-ID: <001901c7edc6$2e22f960$063712bc@drgcomp> From: palace at To: ccamp-archive@ietf.org Subject: A it dean Date: Mon, 3 Sep 2007 01:03:03 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C7EDC6.2E22F960" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.1106 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3000 X-Spam-Score: 2.1 (++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C7EDC6.2E22F960 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable were non-existent. Information and communication will be so is the idea of general purpose simulation, and went on to explain floating around in the vast array of networks. A lawyer may win ------=_NextPart_000_0016_01C7EDC6.2E22F960 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

eliminating the need for paper as medium for communication.
<= /P>

Are you wanting a bigger pe n _is?

As see -n on TV

Over 728,000 Men around the world are already satisfied
Gain 3+ Inches In Leng _th
Increase Your P _enis Wi _dth (Girth) By up _to 26%
100% Safe To Take, With NO Side Effects
No Pum _ps! No Sur _gery! No Exer _cises!
*3 FREE Bottles Of M -eg a Di -k

forever linked in popular culture. So where does that leave the
------=_NextPart_000_0016_01C7EDC6.2E22F960-- From raymond@ebizin.com Sun Sep 02 23:26:40 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS2aG-00063i-2y; Sun, 02 Sep 2007 23:26:40 -0400 Received: from [222.98.42.7] (helo=[222.98.42.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IS2aE-0003Q5-Mr; Sun, 02 Sep 2007 23:26:39 -0400 Received: from [222.98.42.7] by sfilter.ebizin.com; Mon, 34 Aug 2007 12:26:37 +0900 Message-ID: <0101ffa4$0101fe78$072a62de@raymond> From: "Thomas Kent" To: Subject: 9qpfq Date: Mon, 34 Aug 2007 12:26:37 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_0101FFA4.0101FE0C" 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: 1.8 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb This is a multi-part message in MIME format. ------=_NextPart_000_0007_0101FFA4.0101FE0C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To get the best possible results we recommend using the program for at leas= t four months. But remember, just like exercising, results may vary. The mo= re dedicated you are, the sooner you will see results. We look forward to y= our success! MegaDik Pills are a unique blend of all natural and FDA approv= ed ingredients.http://dxviii.comOur money back guarantee is great. If for a= ny reason you are not 100% satisfied with our product within the first 3 Mo= nths simply return the pills for a 100% refund. ------=_NextPart_000_0007_0101FFA4.0101FE0C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
To get the best possible results we recomm= end using the program for at least four months. But remember, just like exe= rcising, results may vary. The more dedicated you are, the sooner you will = see results. We look forward to your success! MegaDik Pills are a unique bl= end of all natural and FDA approved ingredients.
Our money back guarantee is great. If for = any reason you are not 100% satisfied with our product within the first 3 M= onths simply return the pills for a 100% refund.
 
------=_NextPart_000_0007_0101FFA4.0101FE0C-- From Asher178@xxxpornroom.com Sun Sep 02 23:53:17 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS301-0006LU-GM for ccamp-archive@ietf.org; Sun, 02 Sep 2007 23:53:17 -0400 Received: from host-70-45-148-227.onelinkpr.net ([70.45.148.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IS301-0003wH-1J for ccamp-archive@ietf.org; Sun, 02 Sep 2007 23:53:17 -0400 Received: by 10.48.56.186 with SMTP id KrqoePDsdgnhN; Sun, 2 Sep 2007 23:53:32 -0400 (GMT) Received: by 192.168.57.19 with SMTP id cwIWGxyFESLsbW.1640413743912; Sun, 2 Sep 2007 23:53:30 -0400 (GMT) Message-ID: <000301c7eddd$fc4a6dc0$e3942d46@BILLYVP8LJ3ZS4> From: "Asher Kilander" To: Subject: penarono Date: Sun, 2 Sep 2007 23:53:27 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C7EDBC.7538CDC0" 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: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0008_01C7EDBC.7538CDC0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable http://eliepet.com/ Hi bro Kilander bigger than average, thats what i am now Chien Stahl ------=_NextPart_000_0008_01C7EDBC.7538CDC0 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
http://eliepet.com/
Hi bro Kilander
bigger than average, thats what i am = now
Chien Stahl
------=_NextPart_000_0008_01C7EDBC.7538CDC0-- From charlie-dzeima@gjokaj.net Mon Sep 03 01:02:14 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS44k-0000ty-6j for ccamp-archive@megatron.ietf.org; Mon, 03 Sep 2007 01:02:14 -0400 Received: from [60.54.35.242] (helo=[60.54.35.242]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IS44j-0005Cu-AE for ccamp-archive@megatron.ietf.org; Mon, 03 Sep 2007 01:02:14 -0400 Received: by 10.167.167.20 with SMTP id XBbmSzjhGfliZ; Mon, 3 Sep 2007 13:02:21 +0800 (GMT) Received: by 192.168.160.159 with SMTP id oaYZpiyhrIpdtb.0350360449089; Mon, 3 Sep 2007 13:02:19 +0800 (GMT) Message-ID: <84D18500.ACF9904A@gjokaj.net> Date: Mon, 3 Sep 2007 13:02:16 +0800 From: "charlie dzeima" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ccamp-archive@megatron.ietf.org Subject: sea-run Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Wazzup charlie come and see my before and after pics Ovais donoghue http://esfomo.com/ From kmusical@sraco.com Mon Sep 03 04:24:03 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS7E3-0005IY-Cd; Mon, 03 Sep 2007 04:24:03 -0400 Received: from rejon114.ztpnet.pl ([83.142.72.114]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IS7E2-0001Y1-JZ; Mon, 03 Sep 2007 04:24:03 -0400 Received: from jlw29ymywpk640 ([77.174.128.2]:3549 "HELO jlw29ymywpk640" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 72488e53sraco.com with ESMTP id 8038FC600002E3 (ORCPT ); Mon, 3 Sep 2007 10:24:12 +0200 Message-ID: <000f01c7ee14$920890e0$0739506c@jlw29ymywpk640> From: Marquita Gallo To: ccamp-archive@ietf.org Subject: lagain Date: Mon, 3 Sep 2007 10:24:12 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C7EE14.920890E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.1409 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2720.4682 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C7EE14.920890E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable has to offer: already, interactive TV programs are enabling one As far as I know of there are no connections to the third world. with teln= et and then into Media Moo. From inside Media Moo we ------=_NextPart_000_000C_01C7EE14.920890E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

new inventions from film to space travel. It is ludicrous that

Are you wanting a bigger pe n _is?

As see -n on TV

Over 725,000 Men around the world are already satisfied
Gain 3+ Inches In Leng _th
Increase Your P _enis Wi _dth (Girth) By up _to 25%
100% Safe To Take, With NO Side Effects
No Pum _ps! No Sur _gery! No Exer _cises!
*3 FREE Bottles Of M -eg a Di -k

would be a store salesperson or assistant. One will be able to
------=_NextPart_000_000C_01C7EE14.920890E0-- From owner-ccamp@ops.ietf.org Mon Sep 03 04:47:03 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS7aJ-0004AM-4f for ccamp-archive@ietf.org; Mon, 03 Sep 2007 04:47:03 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IS7aI-0002M7-Eh for ccamp-archive@ietf.org; Mon, 03 Sep 2007 04:47:03 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IS7MM-0008Eb-JS for ccamp-data@psg.com; Mon, 03 Sep 2007 08:32:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_WHITELIST autolearn=no version=3.2.1 Received: from [156.154.16.138] (helo=ns1.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IS7MH-0008EF-Uv for ccamp@ops.ietf.org; Mon, 03 Sep 2007 08:32:36 +0000 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns1.neustar.com (Postfix) with ESMTP id A21C426E33; Mon, 3 Sep 2007 08:32:32 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IS7MG-0004I8-Hw; Mon, 03 Sep 2007 04:32:32 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: Greg Jones Cc: Kam Lam , Stephen Trowbridge , Ross Callon , David Ward , Scott Bradner , CCAMP Mailing List , Adrian Farrel , Deborah Brungard , Adrian Farrel , Deborah Brungard From: Adrian Farrel (IETF CCAMP WG) Subject: New Liaison Statement, "ASON Routing Loop Prevention Mechanism" Reply-To: Adrian Farrel Message-Id: Date: Mon, 03 Sep 2007 04:32:32 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Title: ASON Routing Loop Prevention Mechanism Submission Date: 2007-09-03 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=364 From: Adrian Farrel(IETF CCAMP WG) To: ITU-T Q14/15(Greg Jones ) Cc: Kam Lam Stephen Trowbridge Ross Callon David Ward Scott Bradner CCAMP Mailing List Reponse Contact: Adrian Farrel Deborah Brungard Technical Contact: Adrian Farrel Deborah Brungard Purpose: In response Body: The IETF CCAMP working group thanks you for your continued interest in the loop-prevention mechanism contained in our OSPF-based solution to the routing requirements as described in RFC 4258. This liaison is in response to your liaison COM15-169-E issued from your June plenary. A separate liaison will report on the status and progress of our OSPF ASON solution. We disagree with your statement that the rationale we explained "does not utilize the hierarchical nature defined by ASON." Quite to the contrary, the solution addresses the issues introduced by the hierarchical routing nature of ASON while utilizing the benefits. At the same time, since the protocol mechanisms are extensions to OSPF, it is only natural that "the rationale provided takes into account the considerations of how OSPF traditionally operates." You are right to observe that other mechanisms could have been selected, and would also have been functional. This is often the case in protocol design. However, a choice has to be made, and unless there are technical reasons to suggest that the choice is wrong, there seems to be no particular motivation to make a change. You say: While we recognise it is possible to identify the propagation direction based on the Area ID of the source, it does require that all redistribution mechanisms in the network understand the relative location of source areas given the area hierarchy (i.e. are they up or down the hierarchy from the evaluation point). We cannot identify in the existing proposal any mechanism (i.e. new LSA format) defined to provide this information. We note that the requirement is not to know the direction of propagation of information, but to detect routing advertisement loops. According to the strict hierarchical nature of ASON (as you describe in your liaison) the use of Area IDs is sufficient to detect advertisement loops. There is no definition of any new mechanism or LSA in this Internet-Draft: the use of a new LSA or changes to the processing rules for existing LSAs would inhibit the integration of ASON routing developments within the IETF routing family and, while this may not be an objective of the ASON architecture, it is an objective of the IETF. You suggest that the use of Area ID in the LSAs will inhibit re-configuration of AREA IDs. We do not believe that this is the case, and we will add text to the draft to describe the necessary processing for this important, but uncommon case. Please note that the scope of this work (including the loop-prevention mechanisms) is limited by the requirements expressed in RFC 4258. A separate liaison to you has requested a further review of RFC 4258. In the event that substantive modifications to the requirements are made as a result of your review, it will be necessary to consider updating the solutions work. Such a process of publication and revision is similar to the procedure applied within the ITU. Note also that the scope of this work (that is, of this current Internet-Draft) is extensions to the OSPFv2 protocol. The CCAMP working group would welcome contributions in the form of Internet-Drafts from anyone who is interested in addressing the same problem space through the IS-IS protocol. Thank you for your continued support of this work. Regards, Deborah Brungard and Adrian Farrel IETF CCAMP Working Group Co-Chairs Attachment(s): No document has been attached From javed@infoback.com Mon Sep 03 04:49:42 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS7cs-0005HW-Js for ccamp-archive@ietf.org; Mon, 03 Sep 2007 04:49:42 -0400 Received: from [124.82.1.140] (helo=124.82.1.140) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IS7cq-0002Tx-1d for ccamp-archive@ietf.org; Mon, 03 Sep 2007 04:49:42 -0400 Received: from [124.82.1.140] by no.com; Mon, 03 Sep 2007 08:49:31 +0000 Message-ID: <000601c7ee07$06fc2ac5$cd9eb585@bcwvvc> From: "lance munaish" To: Subject: Fast Payouts, Fair Gaming! Date: Mon, 03 Sep 2007 07:02:08 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7EE07.06F8C86F" 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.7 (++++) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C7EE07.06F8C86F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable mega-casino Las Vegas fun at your fingers ..and Las Vegas money in your pocket! USA players accepted, easy, secure payments, fast withdrawals. start playing the best games around =20 Download=20 ------=_NextPart_000_0003_01C7EE07.06F8C86F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

=20 mega-casino

=20
Las Vegas fun at your fingers ..and Las Vegas money in your pocket!
USA players accepted, easy, secure payments, fast withdrawals.

start playing the best games around = =20

Download=20

=20 ------=_NextPart_000_0003_01C7EE07.06F8C86F-- From vkvq17zxvc@wal-mart.com Mon Sep 03 09:11:45 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISBiT-0004aT-S6; Mon, 03 Sep 2007 09:11:45 -0400 Received: from 17.87.218.87.dynamic.jazztel.es ([87.218.87.17] helo=swug) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ISBiT-00027B-AD; Mon, 03 Sep 2007 09:11:45 -0400 To: From: "Jenifer Nettie" Subject: 80% Save Codeine,Valiun,XanaK,AmbienK,PhenterminK,ViagraK,CialiK,SomaK uwla Message-ID: <34969e12968.9021g90762374@wal-mart.com> Date: Mon, 03 Sep 2007 15:11:42 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--ynhwuiphldxvauttn9mmds61d4gp7n" X-Spam-Score: 4.0 (++++) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 ----ynhwuiphldxvauttn9mmds61d4gp7n Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit PharmaShop 80% Discount - Discreet Packaging - Cheapest Medication - Worldwide shipping - Buy in Bulk and Save CodeineK XanaxK ValiumK PhenterminK ViagraK ViagraGelK CialiK CialiKSoftTabs ViagraSoftTabsK SomaK AdalatK AllegraK AmbienK AtaraxK AtivanK CiproK EffexorK GlucophageK LevitraK LipitorK MeridiaK NorvascK PaxilK PropeciaK ProzacK UltramK ZocorK ZoloftK ZybanK plus 30 meds more http://kffils.kfnother.com (Link 1) http://kdubu.kfnother.com (Link 2) ----ynhwuiphldxvauttn9mmds61d4gp7n Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
PharmaShop 80% Discount
Discreet Packaging
Cheapest Medication
Worldwide shipping
Buy in Bulk and Save
CodeineK
XanaxK
ValiumK
PhenterminK
ViagraK
ViagraGelK
CialiK
CialiKSoftTabs
ViagraSoftTabsK
SomaK
AdalatK
AllegraK
AmbienK
AtaraxK
AtivanK
CiproK
EffexorK
GlucophageK
LevitraK
LipitorK
MeridiaK
NorvascK
PaxilK
PropeciaK
ProzacK
UltramK
ZocorK
ZoloftK
ZybanK
plus 30 meds more
Buy Here - start from $72 (link A)
(link B)

captain why pride different? gym justice leader spot near window out?



----ynhwuiphldxvauttn9mmds61d4gp7n-- From owner-ccamp@ops.ietf.org Mon Sep 03 09:25:34 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISBvq-000846-KW for ccamp-archive@ietf.org; Mon, 03 Sep 2007 09:25:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISBvp-0004Bp-7x for ccamp-archive@ietf.org; Mon, 03 Sep 2007 09:25:34 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ISBis-000P2z-W1 for ccamp-data@psg.com; Mon, 03 Sep 2007 13:12:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [64.208.49.5] (helo=smail6.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ISBiq-000P2X-02 for ccamp@ops.ietf.org; Mon, 03 Sep 2007 13:12:09 +0000 Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l83DBZoe006098; Mon, 3 Sep 2007 15:11:35 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 3 Sep 2007 15:12:02 +0200 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: Working Group last calls completed : MPLS/GMPLS interworking and migration Date: Mon, 3 Sep 2007 15:11:48 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E38001243721@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <01a101c7eb36$ad2d3190$0300a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Working Group last calls completed : MPLS/GMPLS interworking and migration thread-index: AcfrNwbW+RuJdgfvSvySymX9WcRCTQC8s07g References: <09a101c7dab4$f6cae910$5002010a@your029b8cecfe> <01a101c7eb36$ad2d3190$0300a8c0@your029b8cecfe> From: "PAPADIMITRIOU Dimitri" To: "Adrian Farrel" , X-OriginalArrivalTime: 03 Sep 2007 13:12:02.0636 (UTC) FILETIME=[049788C0:01C7EE2C] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 hi adrian it would be surprising these documents have reached perfection (or a close to), i would suggest to ask for a review by e.g. gen-art like you did for the inter-domain documents now, it is clear that by addressing a topic that involves operational aspects (not only protocol engineering specific) we would welcome any feedback along these lines thanks, -d. =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Thursday, August 30, 2007 8:51 PM > To: ccamp@ops.ietf.org > Subject: Working Group last calls completed : MPLS/GMPLS=20 > interworking and migration >=20 > Hi, >=20 > These last calls completed while I was travelling. I have=20 > scanned the mail=20 > list and I didn't see any comments. I also received no=20 > comments privately. >=20 > Maybe the drafts are in perfect shape. Maybe no-one had time=20 > to read them. >=20 > Please can I get a feeling from the working group: >=20 > Are these I-Ds ready to move forward as RFCs? >=20 > "Framework for MPLS-TE to GMPLS migration" > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpl s-interwork-fmwk-03.txt >=20 > "Interworking Requirements to Support operation of MPLS-TE over GMPLS=20 > Networks" > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpl s-interwork-reqts-01.txt >=20 > Thanks, > Adrian >=20 > ----- Original Message -----=20 > From: "Adrian Farrel" > To: > Sent: Thursday, August 09, 2007 7:41 PM > Subject: Working Group last call on MPLS/GMPLS interworking=20 > and migration >=20 >=20 > > Hi, > > . > > Two working group drafts have reached the position where=20 > the authors=20 > > consider them ready for last call (actually, a whole bunch=20 > have arrived=20 > > there at the same time, but we want to dribble them through=20 > the last call=20 > > process). > > > > These two documents concern the operation of MPLS over=20 > GMPLS, and the=20 > > migration from MPLS to GMPLS. > > > > The "Framework for MPLS-TE to GMPLS migration" is (the=20 > rather poorly=20 > > named) > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpl s-interwork-fmwk-03.txt > > > > The "Interworking Requirements to Support operation of=20 > MPLS-TE over GMPLS=20 > > Networks" are in > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpl s-interwork-reqts-01.txt > > > > The documents are both Informational. > > > > Please send your comments (preferably to the list) by the=20 > end of WG last=20 > > call which will be 12 noon GMT 24th August 2007. > > > > Thanks, > > Adrian > > > > > >=20 >=20 >=20 >=20 >=20 From ffsdhvkjmdk@izhcom.ru Mon Sep 03 12:55:30 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISFD0-0003my-65 for ccamp-archive@ietf.org; Mon, 03 Sep 2007 12:55:30 -0400 Received: from [89.241.168.111] (helo=izhcom.ru) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISFCy-0006U8-LF for ccamp-archive@ietf.org; Mon, 03 Sep 2007 12:55:29 -0400 Date: Mon, 3 Sep 2007 17:55:25 +0000 From: Smith Johnson X-Mailer: The Bat! (v3.5.30) UNREG / E0XUKJWV2Y Reply-To: Smith Johnson X-Priority: 3 (Normal) Message-ID: <{DIG[8-10]}.20070903175525@izhcom.ru> To: ccamp-archive@ietf.org Subject: High-paid jobs for serious persons. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 3.6 (+++) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 JOB DESCRIPTION: Our company is looking for local representatives. The main duty of our partners is to promote our services regionally. Experience in a field of business and consulting services is preferred but not required. Making money with us is simple. We provide every partner with all necessary informational, educational and financial support. There are a lot of promoting methods, we can help you to find the best way to grow your business, we are looking for long-time partnership. ENJOY THE ADVANTAGES OF TAKING THIS OPPORTUNITY: + High wages. Constantly high commission fees. + Stability. Our company was always one of the best, we aim at keeping leading positions. We are dedicated to helping ambitious people have a better life and we offer you to become our long-time business partner. + People who worked with us have reached high peaks in their business within 6-12 months, in other companies it takes much more time. Strategic planning, Complex projects realization in different business branches, individual responsibility for projects realization, and many other innovative business technologies helps us to make impressive profits in rather short periods of time. OUR COMPANY POLICIES: + Our primary personnel policy is to provide maximum binding between corporate targets and personal objectives of our partners. We offer a full freedom to everyone who want to grow a life with us. Our valued representative can work as hard as he like. If you work with us - you are your own boss. + We always cover all business and educational expenses of our representatives. + We do everything to make everyone who works with us creatively inspired. + We are interested in the success of every our partner because our company success is the success of our representing partners. HOW TO KNOW MORE: In order to begin your work please send us your resume to EnidHinesIM@gmail.com. We accept DOC, RTF, PDF and TXT files. Good luck! From rglory@ahbelo.com Mon Sep 03 14:27:33 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISGe5-0002lN-9D for ccamp-archive@ietf.org; Mon, 03 Sep 2007 14:27:33 -0400 Received: from chello084010049212.chello.pl ([84.10.49.212] helo=wosiek-50b03101.chello.pl) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ISGe0-00026N-Ar for ccamp-archive@ietf.org; Mon, 03 Sep 2007 14:27:33 -0400 Received: from wosiek50b03101 ([128.142.40.13]) by d4310a54ahbelo.com with ESMTP id 1926D2899036E1 for ; Mon, 3 Sep 2007 20:31:10 +0200 Message-ID: <000f01c7ee69$5d6d9d30$0688162c@wosiek50b03101> From: Rachelle To: ccamp-archive@ietf.org Subject: wtired Date: Mon, 3 Sep 2007 20:31:10 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C7EE69.5D6D9D30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.1409 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2720.1409 X-Spam-Score: 0.9 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C7EE69.5D6D9D30 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable dimension. Text has given me the knowledge to explore further. justify a situation like that. Greed will more likely than not It`s funny how we`re living in the past so much of the time. = ------=_NextPart_000_000C_01C7EE69.5D6D9D30 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable

of many approaches to looking at things. Go see the movie Slacker

Are you wanting a bigger pe n _is?

As see -n on TV

Over 783,000 Men around the world are already satisfied
Gain 2+ Inches In Leng _th
Increase Your P _enis Wi _dth (Girth) By up _to 20%
100% Safe To Take, With NO Side Effects
No Pum _ps! No Sur _gery! No Exer _cises!
*3 FREE Bottles Of M -eg a Di -k

by technology always - modern techno conveniences such as the
------=_NextPart_000_000C_01C7EE69.5D6D9D30-- From jim@kanahebi.com Mon Sep 03 15:35:36 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISHhw-00042a-BR; Mon, 03 Sep 2007 15:35:36 -0400 Received: from [124.136.102.30] (helo=[124.136.102.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISHhv-0004Lz-Sx; Mon, 03 Sep 2007 15:35:36 -0400 Received: from [124.136.102.30] by mail.kanahebi.com; Mon, 34 Aug 2007 28:35:29 +0900 Message-ID: <0107ffa4$0107fe78$1e66887c@jim> From: "Daphne Malone" To: Subject: Retail price $599.00 save $529.05 PHOTOSHOP CS2 MACINTOSH Date: Mon, 34 Aug 2007 28:35:29 +0900 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.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Spam-Score: 1.8 (+) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 acrobat Pro retail price - $449 Save $369 http://spoaueyaat.cn From MariapejorativeOconnell@whyfiles.org Mon Sep 03 17:53:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISJrl-0003G7-Qx for ccamp-archive@ietf.org; Mon, 03 Sep 2007 17:53:53 -0400 Received: from [91.139.192.74] (helo=computers9rvbq) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ISJrk-00018z-Ix for ccamp-archive@ietf.org; Mon, 03 Sep 2007 17:53:53 -0400 Message-ID: <7dc001c7ee74$e926a730$0132a8c0@computers9rvbq> From: "Carol Mayfield" To: Subject: Fwd: Thanks, we are accepting your company business loan request Date: Tue, 4 Sep 2007 00:48:41 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_7DBC_01C7EE74.E926A730" 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.5 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 ------=_NextPart_000_7DBC_01C7EE74.E926A730 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If you have your own business and need IMMEDIATE cash to spend ANY way = you like or require Extra money to give your business a boost or wish A = low interest loan - NO STRINGS ATTACHED, here is our deal we can offer = you THIS NIGHT (hurry, this tender will expire TONIGHT): $35,000+ loan Hurry, when best deal is gone, it is gone. Simply Call Us Free on = 877-482-4954 ------=_NextPart_000_7DBC_01C7EE74.E926A730 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If you have your own business and need = IMMEDIATE=20 cash to spend ANY way you like or require Extra money to give your = business a=20 boost or wish A low interest loan - NO STRINGS ATTACHED, here is our = deal we=20 can offer you THIS NIGHT (hurry, this tender will expire = TONIGHT):
=20 =20
 
$35,000+ loan
 
Hurry, when best deal is gone, it is = gone. Simply=20 Call Us Free on 877-482-4954
------=_NextPart_000_7DBC_01C7EE74.E926A730-- From bb07.com@ideafuturesmarket.com Mon Sep 03 18:04:45 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISK2H-0002nt-SJ for ccamp-archive@ietf.org; Mon, 03 Sep 2007 18:04:45 -0400 Received: from [210.214.255.125] (helo=nyfqotte) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ISK1x-0007uC-Na for ccamp-archive@ietf.org; Mon, 03 Sep 2007 18:04:26 -0400 Message-ID: <000301c7ee76$57352200$0100007f@xewmyl> From: "Nicholas Butler" To: Subject: Date: Tue, 04 Sep 2007 03:32:00 +0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 3.5 (+++) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Several millions men have been helped with the potent ingredients in Penis Growth Patch (TM) - men have experienced bigger size, more action and super-satisfying results for themselves and their partners. Don't be left behind! Stop thing about "small size"! Take advantage of price specials going on now. Click here! From stockleyyvoz@a1copycat.com Mon Sep 03 19:31:05 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISLNp-0001O2-Nz for ccamp-archive@megatron.ietf.org; Mon, 03 Sep 2007 19:31:05 -0400 Received: from host212-86-static.104-82-b.business.telecomitalia.it ([82.104.86.212] helo=host212-86.pool82104.interbusiness.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISLNp-0001a4-0I for ccamp-archive@megatron.ietf.org; Mon, 03 Sep 2007 19:31:05 -0400 Received: from PLANNING ([175.148.79.94] helo=PLANNING) by host212-86.pool82104.interbusiness.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1teuSd-000FBL-kU for ccamp-archive@megatron.ietf.org; Tue, 4 Sep 2007 01:32:25 +0200 Message-ID: <000401c7ee82$9b294200$d4566852@PLANNING> From: "dsfa stockley" To: Subject: bizarren Date: Tue, 4 Sep 2007 01:31:51 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C7EE93.5EB21200" 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.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0009_01C7EE93.5EB21200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://mamezon.com/ Good day dsfa For this week only you can get massive discounts of out Manster pills .. = For MEN Francisco Fredson ------=_NextPart_000_0009_01C7EE93.5EB21200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://mamezon.com/
Good day dsfa
For this week only you can get massive = discounts of out=20 Manster pills .. For MEN
Francisco Fredson
------=_NextPart_000_0009_01C7EE93.5EB21200-- From novakbh@elistas.net Mon Sep 03 21:21:27 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISN6d-0001uw-OA; Mon, 03 Sep 2007 21:21:27 -0400 Received: from [201.166.68.106] (helo=prudential.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISN6N-00050L-8Y; Mon, 03 Sep 2007 21:21:27 -0400 Message-ID: <1188868066.6100@elistas.net> Subject: Make YourPenis 3-inches longer & thicker, girl will love you ymzd883bdst7c Date: Mon, 03 Sep 2007 18:07:46 -0700 MIME-Version: 1.0 From: "Felix S. Novak" To: iad@ietf.org Bcc: ietf-announce@ietf.org, ipcdn-bounces@ietf.org, iaoc@ietf.org, isis-wg-admin@ietf.org, hubmib-bounces@ietf.org, ccamp-archive@ietf.org, ldap-dir-bounces@ietf.org Content-Type: multipart/alternative; boundary="----=_NextPart_000_0C20_3451086A.446C0043" X-Spam-Score: 2.1 (++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 This is a multi-part message in MIME format. ------=_NextPart_000_0C20_3451086A.446C0043 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit Safe & Effective PenisEnlargement Over 1,500,000 bottles sold worldwide WeOffer Full MoneyBack Guarantee if you are not completely satisfied with the results of Man-XL, you have nothing to lose, just a lot to gain 1) Gain Up to 3+ Inches In Length 2) Increase YourPenis Width (Girth) By upto 20% 3) Help Stop PrematureEjaculation! 4) Produce Stronger, Rock HardErections 5) 100% Safe To Take, With NO Side Effects 6) Fast Shipping WorldWide 7) Doctor Approved And Recommended 8) No Pumps, No Surgery, No Exercises 9) Very discrete shipping and billing 10) Up to 3 FREE Bottles Of Man-XL 11) Highly secure 128bit order processing Buy This herbal EnlargementPills here http://drg.kfflopsont.com http://dtu.kfflopsont.com ------=_NextPart_000_0C20_3451086A.446C0043 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: 8bit
Safe & Effective PenisEnlargement
Over 1,500,000 bottles sold worldwide
WeOffer Full MoneyBack Guarantee if you are not completely satisfied with the results of Man-XL, you have nothing to lose, just a lot to gain
1) Gain Up to 3+ Inches In Length
2) Increase YourPenis Width (Girth) By upto 20%
3) Help Stop PrematureEjaculation!
4) Produce Stronger, Rock HardErections
5) 100% Safe To Take, With NO Side Effects
6) Fast Shipping WorldWide
7) Doctor Approved And Recommended
8) No Pumps, No Surgery, No Exercises
9) Very discrete shipping and billing
10) Up to 3 FREE Bottles Of Man-XL
11) Highly secure 128bit order processing
Did you know... Man-XL was featured in leading mens magazines such as FHM, MAXIM, plus many others, and rated No.1 choice forPenisEnlargement Also seen on TV
Buy This herbal EnlargementPills here (Link 1)
(Link 2)




likely ten day pronunciation. modern better pay second captain remember central, sur51a2xelos92 xywcolkhsd23v7
------=_NextPart_000_0C20_3451086A.446C0043-- From aklamb@petvisionpro.com Tue Sep 04 02:05:17 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISRXI-0004VT-VI; Tue, 04 Sep 2007 02:05:16 -0400 Received: from [220.89.67.116] (helo=[220.89.67.116]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISRXI-000499-12; Tue, 04 Sep 2007 02:05:16 -0400 Received: from [220.89.67.116] by smtp.secureserver.net; Tue, 35 Aug 2007 15:05:54 +0900 Message-ID: <0107ffa4$0107fe78$744359dc@aklamb> From: "Blanche Hamilton" To: Subject: Mucuna pruriens 75 mg Date: Tue, 35 Aug 2007 15:05:54 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 1.8 (+) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 How long should I use MegaDik Pills? http://ealiel.com From Hei_Orlovich@wiasp.com Tue Sep 04 02:17:38 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISRjG-0005xU-GQ for ccamp-archive@ietf.org; Tue, 04 Sep 2007 02:17:38 -0400 Received: from 203-213-54-18-syd-ts2-2600.tpgi.com.au ([203.213.54.18] helo=adl-pow-pr3.tpgi.com.au) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISRjF-0004Tk-Gd for ccamp-archive@ietf.org; Tue, 04 Sep 2007 02:17:38 -0400 Received: from Jarrod ([173.114.59.189]:27380 "EHLO Jarrod" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by adl-pow-pr3.tpgi.com.au with ESMTP id S22LVOMJFGZSOKKG (ORCPT ); Tue, 4 Sep 2007 15:47:48 +09-30 Message-ID: Date: Tue, 4 Sep 2007 15:47:34 +09-30 From: "Hei Orlovich" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: 743-0734 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.7 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea How it is going Hei You should see me now, i am so much more confident with the women. Alberto Schumacher http://mhtlhelp.com/ From metal-cohen@alkhadda-international.com Tue Sep 04 03:10:25 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISSYL-0005t9-RP for ccamp-archive@megatron.ietf.org; Tue, 04 Sep 2007 03:10:25 -0400 Received: from aarl43.neoplus.adsl.tpnet.pl ([83.5.197.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISSYL-0005cS-8z for ccamp-archive@megatron.ietf.org; Tue, 04 Sep 2007 03:10:25 -0400 Received: from life-3f4f30f34d ([102.142.13.170] helo=life-3f4f30f34d) by aarl43.neoplus.adsl.tpnet.pl ( sendmail 8.13.3/8.13.1) with esmtpa id 1RKIrz-000LDV-hn for ccamp-archive@megatron.ietf.org; Tue, 4 Sep 2007 09:10:56 +0200 Message-ID: <000601c7eec2$aa56a660$2bc50553@life3f4f30f34d> From: "metal cohen" To: Subject: donecker Date: Tue, 4 Sep 2007 09:10:25 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C7EED3.6DDF7660" 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_0005_01C7EED3.6DDF7660 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable http://mohesr.com/ Wassup metal ladies can sence a confident man, and they like it. Kosal Chew ------=_NextPart_000_0005_01C7EED3.6DDF7660 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
http://mohesr.com/
Wassup metal
ladies can sence a confident man, and they = like it.
Kosal Chew
------=_NextPart_000_0005_01C7EED3.6DDF7660-- From owner-ccamp@ops.ietf.org Tue Sep 04 05:31:27 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISUkp-0001Zc-2g for ccamp-archive@ietf.org; Tue, 04 Sep 2007 05:31:27 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISUkn-0002C0-QO for ccamp-archive@ietf.org; Tue, 04 Sep 2007 05:31:26 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ISUW6-0005Cn-Du for ccamp-data@psg.com; Tue, 04 Sep 2007 09:16:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_WHITELIST autolearn=no version=3.2.1 Received: from [156.154.16.158] (helo=ns0.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ISUVx-0005By-UL for ccamp@ops.ietf.org; Tue, 04 Sep 2007 09:16:12 +0000 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns0.neustar.com (Postfix) with ESMTP id 898623286E; Tue, 4 Sep 2007 09:16:04 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1ISUVw-00031a-Ef; Tue, 04 Sep 2007 05:16:04 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: Greg Jones Cc: Kam Lam , Stephen Trowbridge , Ross Callon , David Ward , Scott Bradner , CCAMP Mailing List , Adrian Farrel , Deborah Brungard , Adrian Farrel , Deborah Brungard From: Adrian Farrel (IETF CCAMP WG) Subject: New Liaison Statement, "GMPLS Signaling for VCAT/LCAS" Reply-To: Adrian Farrel Message-Id: Date: Tue, 04 Sep 2007 05:16:04 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Title: GMPLS Signaling for VCAT/LCAS Submission Date: 2007-09-04 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=365 Please reply by 2007-11-15 From: Adrian Farrel(IETF CCAMP WG) To: ITU-T Q14/15(Greg Jones ) Cc: Kam Lam Stephen Trowbridge Ross Callon David Ward Scott Bradner CCAMP Mailing List Reponse Contact: Adrian Farrel Deborah Brungard Technical Contact: Adrian Farrel Deborah Brungard Purpose: For action Body: The CCAMP Working Group thanks you for your liaison of April this year (COM15-LS3-E) and for your interest in our work to develop GMPLS signaling extensions for the control of VCAT within TDM networks. The latest version of this work can be found at http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-02.txt We expect a revision relatively soon, so if the referenced link fails, please also check at http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-03.txt Here are our responses to the questions in your liaison. 1. Would CCAMP consider generalizing the draft so that it could be applied to any Inverse Multiplexing scheme? For example, if generalized, the method could be used to establish H.244, ML-PPP, ATM inverse mux, or BONDING connections. It is certainly our intention that any protocol extensions that we develop should be easily extensible to other technologies. But at the same time we have seen no immediate interest from the community in applying GMPLS as a control plane for any of the technologies that you list. It would, of course, be a prerequisite of using GMPLS for such an inverse multiplexing scheme, that GMPLS was also used to build network connections (i.e. LSPs) for the specific technology. If you have a requirement to use GMPLS to control these technologies, we would be interested to hear from you. In the mean time, we note that the inverse multiplexing schemes that you list are packet/cell forms rather than circuit forms of inverse multiplexing and hence may have different configuration parameters than VCAT. 2. Does the I-D describe VCAT call signalling? The I-D uses GMPLS Calls (RFC 4974) to achieve VCAT group signaling. The GMPLS Call is used to coordinate the setup of multiple server connections (LSPs) used to form a VCAT group (a connection in the VCAT layer). 3. Does the I-D allow LSPs in a server layer to be set up without any prior knowledge of a possible VCAT layer, and then at a later point in time allow those LSPs to become available to a VCAT layer? When a network connection is established at the request of an operator or a management system, we have assumed that there is some motivation, and that the motivation is expressed in the call that coordinates the connection. In RFC 4974, the nature of the call can be changed (as a matter of call parameter exchange that is within the scope of the call controller function, but the details of which, except for the message exchange rules, are outside the scope of the signaling protocol), but the connections cannot be moved from one call to another. Thus, LSPs that are set up in association with a specific call can only be used as directed by the call controller with responsibility for that call. If a call controller decides to use the connections (LSPs) for VCAT one day and for something else another day, that is entirely within its remit. However, this assumes that the call controller can suitably instruct and coordinate the necessary adaptation functions at each end of the network connections. An implementation might find it more convenient to release the call (and the associated connections), before setting up a new call and a new set of connections. Note that we are considering mechanisms to allow LSPs to be moved between VCAT Groups according to the requirements of the network. Such schemes necessarily mean that there is not always a 1:1 relationship between calls and VCAT groups since it remains the case that connections cannot be moved between calls. However, our understanding of G.707 and the ability to move component trails (VCAT group members) between VCAT groups while the trail is in service is unclear, and we would welcome clarification of the requirements before progressing this function further. 4. Does the I-D allow the association of a VCAT call to multiple server layer calls? This is not specifically addressed. There is no hierarchy of calls described in the draft. Instead, the draft provides for a single call that is used to coordinate all of the server layer connections that support the single VCAT service. In practice, this may not represent architectural purity, but we believe it is a protocol implementation simplification consistent with the way that VCAT is operated. We note that VCAT groups can only consist of a single server connection type and cannot be mixed, e.g., VC-3 and VC-4 components cannot both be in the same VCG. 5. Does release of a VCAT call automatically imply release of the server layer call(s)? This is not required by G.8080 as layers are assumed to be independent. As noted for point 4, the VCAT layer call is not specifically called out in the draft. You may consider that the draft provides a mechanism for handling the (single hop) VCAT call and the server layer call as a single item. We would be interested to hear from you the operational circumstances under which a single VCAT layer call might give rise to multiple server layer calls. The signaling of the release of a GMPLS Call is rejected if connections are still in place (per RFC 4974 section 6.6.4) which is consistent with the connections having been set up under the instructions of the call controller and in support of the call. Thus, operationally, the release of a call will require the release of the associated connections. At this point it may be worth clarifying that a VCAT layer connection is created under the control of a VCAT layer call. The VCAT connection may require server layer connections (indeed, this is always the case with VCAT) and those connections need to be associated and controlled by a call. it is this second type of call that we are we are describing in this draft. Thus, the release of a VCAT call would lead to the release of the VCAT connection. The network policy may determine whether to release the server layer call or not. If the server layer call is released, the server layer connections will also be released. 6. Is VCAT layer addressing assumed to be the same as that of the server layer? GMPLS only supports IP addressing. The link connections in the VCAT layer created by/from network connections in the server layer may be given different addresses from the addresses used to represent the endpoints in the server layer, or may use the same addresses. 7. Are the two VCAT layer Call Controllers assumed to have direct signalling connectivity? Yes, adjacent call controllers in any layer are assumed to be able to exchange call control messages without the intervention of any proxy, agent, or extra-layer entity. 8. If multiple client layers are using the same VCAT layer as their server layer, how can the VCAT layer call be identified for use in the client layer signalling? How is this problem any different from any other n:1 client/server relationship? Please supply details of why the fact that the server layer is a VCAT layer should make this scenario any different. Please also note that, as for point 5 above, the VCAT layer call is not what is being addressed in this draft. We are addressing the server layer call that coordinates the server layer network connections that are used as VCAT group members to construct a VCAT group that can be presented as a link connection in the VCAT layer. 9. Have you considered using the ASON call id [RFC3474] at all layers to achieve separate call control of the VCAT and server layers? The format of the call ID is deliberately out of scope for this work as we would not wish to control or enforce the applicability of this work in any one environment. However, RFC 4974 (as noted in a recent separate liaison from us on GMPLS Calls) allows any format call ID to be encoded in GMPLS calls. Thus, the ASON call id format described informationally in RFC 3474 can be supported and used in an ASON environment at the choice of the operator and/or the implementer of the call controller. Can you please confirm that the normative definition of the ASON call ID is in G.7713.2? Other Recommendations (such as G.7713.3) also appear to have call IDs defined, and we want to make sure that we can reference a single, protocol- independent definition of a call ID 10. In the ASON architecture [G.8080], it is not assumed that a single signalling protocol is used in all domains. Even in the case the same protocol is used in all domains, the RSVP session changes between domains. Could you explain how the Notify mechanism used for call control would work across multiple domains where the RSVP session changes? This question clearly has wider relevance than this VCAT draft and should be seen in the context of RFC 4974, and not in reference to this draft. We note that G.8080 makes no assumptions about connection signaling protocols in adjacent domains, but we believe that the architecture does assume an E-NNI reference point in association with one or more call controllers at such domain interfaces. The E-NNI call controllers are responsible for requesting the necessary network connections in each domain and, where the E-NNI is externalised, for requesting any inter-domain connections. Call messages are exchanged between adjacent call controllers and relate to the network connections established at the request of those call controllers. When two adjacent GMPLS domains support the same end-to-end network connection, we do not recommend that the session object be changed. Please clarify where in G.8080 there is any reference to RSVP sessions. There should be no such discussion of protocol implementations in an architecture document. We would welcome your opinions on these responses and the direction of our work. In your liaison you stated that you had the intention to review the draft further at your June meeting. But in the liaison from your June meeting (COM15-LS170-E) you say that you deferred this review pending further revisions of the I-D. This is quite reasonable, but we would nevertheless welcome any further high-level comments that you may have. We will notify you as this draft is updated. Best regards, Adrian Farrel and Deborah Brungard IETF CCAMP Working Group Co-Chairs Attachment(s): No document has been attached From claudia@mountainzone.com Tue Sep 04 07:27:07 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISWYl-0002g7-G5 for ccamp-archive@ietf.org; Tue, 04 Sep 2007 07:27:07 -0400 Received: from h166.212-1-94.ukrpack.net ([212.1.94.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISWYh-0006Ez-1j for ccamp-archive@ietf.org; Tue, 04 Sep 2007 07:27:07 -0400 Received: from [212.1.94.166] by ns5.secureserver.net; Tue, 04 Sep 2007 11:27:00 +0000 Message-ID: <000801c7eee6$0800f231$ec7738ab@bdaos> From: "cristobal tiny" To: Subject: AlphaSoft : unique software on CD and DVD Date: Tue, 04 Sep 2007 09:39:37 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C7EEE6.07FE353D" 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: 2.8 (++) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C7EEE6.07FE353D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable AlphaSoft : unique software on CD and DVD HACKER-CD - a full programme complex of the Hacker. In kit of the supply = of the complex enter the hundreds of the programs and scrap, intended = for breaking in any soft: breaking in icq, breaking in the passwords, = breaking in site, breaking in the mail, breaking in archive, breaking in = to network and many other soft. The whole complex of the programs is = unique. This information is given only for familiarization on your = personal computer, for reconstruction of their own passwords and files, = and must be not used in network Internet, or the other network in = illegal purpose. Information can be used by you only if you understand, = what consequences can appear as a result of misapplication.=20 TEMPLATES-DVD - 4 DVD, which thousand web-pattern from TemplateMonster = (0000-7000), BoxedArt, DeonixDesign, InstantCoffee, Mastertemplates, = Seder Graphics, TemplatesDD, templatespace and others., a thousand = colorful font (the enormous amount font, supporting cyrillics), enormous = documentation on design in all area web-design and, certainly, excellent = soft, which use the most best designers of the world...=20 ------=_NextPart_000_0005_01C7EEE6.07FE353D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
AlphaSoft : unique software on CD and = DVD
HACKER-CD - a full programme complex of = the Hacker. In kit of the supply of the complex enter the hundreds of = the programs and scrap, intended for breaking in any soft: breaking in = icq, breaking in the passwords, breaking in site, breaking in the mail, = breaking in archive, breaking in to network and many other soft. The = whole complex of the programs is unique. This information is given only = for familiarization on your personal computer, for reconstruction of = their own passwords and files, and must be not used in network Internet, = or the other network in illegal purpose. Information can be used by you = only if you understand, what consequences can appear as a result of = misapplication.=20

TEMPLATES-DVD - 4 DVD, which thousand = web-pattern from TemplateMonster (0000-7000), BoxedArt, DeonixDesign, = InstantCoffee, Mastertemplates, Seder Graphics, TemplatesDD, = templatespace and others., a thousand colorful font (the enormous amount = font, supporting cyrillics), enormous documentation on design in all = area web-design and, certainly, excellent soft, which use the most best = designers of the world...
------=_NextPart_000_0005_01C7EEE6.07FE353D-- From boraGallup@mothermusicisalive.com Tue Sep 04 08:05:24 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISX9o-00089k-Po for ccamp-archive@ietf.org; Tue, 04 Sep 2007 08:05:24 -0400 Received: from catv-5062fc8d.catv.broadband.hu ([80.98.252.141]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISX9o-0006wo-9g for ccamp-archive@ietf.org; Tue, 04 Sep 2007 08:05:24 -0400 Received: from bsaftpz-wwx52fr ([124.175.155.135] helo=bsaftpz-wwx52fr) by catv-5062fc8d.catv.broadband.hu ( sendmail 8.13.3/8.13.1) with esmtpa id 1MHvLq-000JOL-fB for ccamp-archive@ietf.org; Tue, 4 Sep 2007 14:05:53 +0200 Message-ID: <74C39BB6.80EBF467@mothermusicisalive.com> Date: Tue, 4 Sep 2007 14:05:24 +0200 From: "bora Gallup" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: iskavaal Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Hi bro ccamp-archive For this week only you can get massive discounts of out Manster pills .. For MEN kosats Dinh http://manbs.com/ From owner-ccamp@ops.ietf.org Tue Sep 04 09:17:49 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISYHt-0002Kq-Hn for ccamp-archive@ietf.org; Tue, 04 Sep 2007 09:17:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISYHs-0000vb-5I for ccamp-archive@ietf.org; Tue, 04 Sep 2007 09:17:49 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ISY6S-0002tW-0W for ccamp-data@psg.com; Tue, 04 Sep 2007 13:06:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [129.60.39.103] (helo=tama55.ecl.ntt.co.jp) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ISY6O-0002rt-Ai for ccamp@ops.ietf.org; Tue, 04 Sep 2007 13:05:58 +0000 Received: from mfs34.rdh.ecl.ntt.co.jp (mfs34.rdh.ecl.ntt.co.jp [129.60.39.114]) by tama55.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l84D5c4V013240; Tue, 4 Sep 2007 22:05:44 +0900 (JST) Received: from mfs34.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id AACD120AE46; Tue, 4 Sep 2007 22:04:04 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 255FD20B198; Tue, 4 Sep 2007 22:02:37 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (eclscan2.m.ecl.ntt.co.jp [129.60.5.68]) by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l84D0nL7024496; Tue, 4 Sep 2007 22:02:18 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l84D0nY2024030; Tue, 4 Sep 2007 22:00:49 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (ipc0.m.ecl.ntt.co.jp [129.60.5.156]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l84D0muf024012; Tue, 4 Sep 2007 22:00:48 +0900 (JST) Received: from [127.0.0.1] (psei-ibmx30-apb2.nslab.ecl.ntt.co.jp [129.60.80.23]) by imc.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l84D0loP003582; Tue, 4 Sep 2007 22:00:48 +0900 (JST) Message-ID: <46DD56D2.2030506@lab.ntt.co.jp> Date: Tue, 04 Sep 2007 22:00:02 +0900 From: Kohei Shiomoto User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Working Group last calls completed : MPLS/GMPLS interworking and migration References: <09a101c7dab4$f6cae910$5002010a@your029b8cecfe> <01a101c7eb36$ad2d3190$0300a8c0@your029b8cecfe> In-Reply-To: <01a101c7eb36$ad2d3190$0300a8c0@your029b8cecfe> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Hi Adrian I think that these drafts are ready to move forward. I am happy to hear any feedback from the ccamp community. Best regards, Kohei > Hi, > > These last calls completed while I was travelling. I have scanned the > mail list and I didn't see any comments. I also received no comments > privately. > > Maybe the drafts are in perfect shape. Maybe no-one had time to read them. > > Please can I get a feeling from the working group: > > Are these I-Ds ready to move forward as RFCs? > > "Framework for MPLS-TE to GMPLS migration" > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-03.txt > > > "Interworking Requirements to Support operation of MPLS-TE over GMPLS > Networks" > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-reqts-01.txt > > > Thanks, > Adrian > > ----- Original Message ----- From: "Adrian Farrel" > To: > Sent: Thursday, August 09, 2007 7:41 PM > Subject: Working Group last call on MPLS/GMPLS interworking and migration > > >> Hi, >> . >> Two working group drafts have reached the position where the authors >> consider them ready for last call (actually, a whole bunch have >> arrived there at the same time, but we want to dribble them through >> the last call process). >> >> These two documents concern the operation of MPLS over GMPLS, and the >> migration from MPLS to GMPLS. >> >> The "Framework for MPLS-TE to GMPLS migration" is (the rather poorly >> named) >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-03.txt >> >> >> The "Interworking Requirements to Support operation of MPLS-TE over >> GMPLS Networks" are in >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-reqts-01.txt >> >> >> The documents are both Informational. >> >> Please send your comments (preferably to the list) by the end of WG >> last call which will be 12 noon GMT 24th August 2007. >> >> Thanks, >> Adrian >> >> >> > > > > > -- Kohei Shiomoto NTT Network Service Systems Laboratories 3-9-11 Midori, Musashino, Tokyo 180-8585, Japan Phone +81 422 59 4402 Fax +81 422 59 3787 From Robertson.ramanoop@adsl-81-7-119-163.takas.lt Tue Sep 04 11:16:25 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISa8f-00034F-AF for ccamp-archive@megatron.ietf.org; Tue, 04 Sep 2007 11:16:25 -0400 Received: from adsl-ull-52-125.48-151.net24.it ([151.48.125.52] helo=adsl-ull-162-92.48-151.net24.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISa8e-0003vm-J0 for ccamp-archive@megatron.ietf.org; Tue, 04 Sep 2007 11:16:25 -0400 Received: by 10.94.84.51 with SMTP id TwAaJPaRInXnX; Tue, 4 Sep 2007 17:16:30 +0200 (GMT) Received: by 192.168.64.115 with SMTP id nkqRcZcZwNQjGY.4182819063023; Tue, 4 Sep 2007 17:16:28 +0200 (GMT) Message-ID: <000b01c7ef06$8f5e1b60$a25c3097@server> From: "Robertson ramanoop" To: Subject: streitpu Date: Tue, 4 Sep 2007 17:16:25 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C7EF17.52E6EB60" 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.6 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0008_01C7EF17.52E6EB60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.meblepl.com/ Wazzup Robertson ladies can sence a confident man, and they like it. Ashlee Nimac ------=_NextPart_000_0008_01C7EF17.52E6EB60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.meblepl.com/
Wazzup Robertson
ladies can sence a confident man, and they = like it.
Ashlee Nimac
------=_NextPart_000_0008_01C7EF17.52E6EB60-- From owner-ccamp@ops.ietf.org Tue Sep 04 12:56:49 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISbhp-0006jD-Ie for ccamp-archive@ietf.org; Tue, 04 Sep 2007 12:56:49 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISbhp-0006YB-3g for ccamp-archive@ietf.org; Tue, 04 Sep 2007 12:56:49 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ISbYZ-0000nF-8I for ccamp-data@psg.com; Tue, 04 Sep 2007 16:47:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [206.16.17.211] (helo=usaga01-in.huawei.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ISbYS-0000mc-R6 for ccamp@ops.ietf.org; Tue, 04 Sep 2007 16:47:13 +0000 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNU008L2RYJVW@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Tue, 04 Sep 2007 09:47:08 -0700 (PDT) Received: from Lee736821 ([10.124.12.111]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JNU009PWRYFY2@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Tue, 04 Sep 2007 09:47:07 -0700 (PDT) Date: Tue, 04 Sep 2007 11:47:00 -0500 From: Young Lee Subject: RE: Working Group last calls completed : MPLS/GMPLS interworking and migration In-reply-to: <01a101c7eb36$ad2d3190$0300a8c0@your029b8cecfe> To: 'Adrian Farrel' , ccamp@ops.ietf.org Message-id: <000c01c7ef13$3702dca0$6f0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcfrNydkCls/SZk6RZmO5y0w5nzorAD0ZdAA Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc I support both I-Ds to move forward as RFCs. Both I-D clearly state the scope of the document and comprehensively address respective architectural framework and requirement. Young -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Thursday, August 30, 2007 1:51 PM To: ccamp@ops.ietf.org Subject: Working Group last calls completed : MPLS/GMPLS interworking and migration Hi, These last calls completed while I was travelling. I have scanned the mail list and I didn't see any comments. I also received no comments privately. Maybe the drafts are in perfect shape. Maybe no-one had time to read them. Please can I get a feeling from the working group: Are these I-Ds ready to move forward as RFCs? "Framework for MPLS-TE to GMPLS migration" http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fm wk-03.txt "Interworking Requirements to Support operation of MPLS-TE over GMPLS Networks" http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-re qts-01.txt Thanks, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Thursday, August 09, 2007 7:41 PM Subject: Working Group last call on MPLS/GMPLS interworking and migration > Hi, > . > Two working group drafts have reached the position where the authors > consider them ready for last call (actually, a whole bunch have arrived > there at the same time, but we want to dribble them through the last call > process). > > These two documents concern the operation of MPLS over GMPLS, and the > migration from MPLS to GMPLS. > > The "Framework for MPLS-TE to GMPLS migration" is (the rather poorly > named) > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fm wk-03.txt > > The "Interworking Requirements to Support operation of MPLS-TE over GMPLS > Networks" are in > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-re qts-01.txt > > The documents are both Informational. > > Please send your comments (preferably to the list) by the end of WG last > call which will be 12 noon GMT 24th August 2007. > > Thanks, > Adrian > > > From rixie@brookeenglish.com Tue Sep 04 16:54:21 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISfPh-0000bU-Mx for ccamp-archive@ietf.org; Tue, 04 Sep 2007 16:54:21 -0400 Received: from host99-221-dynamic.181-80-r.retail.telecomitalia.it ([80.181.221.99]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISfPh-0004yD-2V for ccamp-archive@ietf.org; Tue, 04 Sep 2007 16:54:21 -0400 Received: by 10.199.198.162 with SMTP id WAKoTsIZepZYB; Tue, 4 Sep 2007 22:54:25 +0200 (GMT) Received: by 192.168.18.186 with SMTP id LWDcRzwESVjVTh.4689436226323; Tue, 4 Sep 2007 22:54:23 +0200 (GMT) Message-ID: <000c01c7ef35$c45ea2b0$63ddb550@primo3778cc2f7> From: "nasir rixie" To: Subject: razatlab Date: Tue, 4 Sep 2007 22:54:20 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7EF46.87E772B0" 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_0003_01C7EF46.87E772B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.devildj.com/ Good day rixie wow, i never knew my banger could grow so big Nagel walters ------=_NextPart_000_0003_01C7EF46.87E772B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.devildj.com/
Good day rixie
wow, i never knew my banger could grow so = big
Nagel walters
------=_NextPart_000_0003_01C7EF46.87E772B0-- From simar_Swafford@brookeenglish.com Tue Sep 04 16:56:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISfRm-0002Rm-UZ for ccamp-archive@megatron.ietf.org; Tue, 04 Sep 2007 16:56:30 -0400 Received: from host99-221-dynamic.181-80-r.retail.telecomitalia.it ([80.181.221.99]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISfRl-0004sd-6c for ccamp-archive@megatron.ietf.org; Tue, 04 Sep 2007 16:56:30 -0400 Received: from primo-3778cc2f7 ([130.149.64.34] helo=primo-3778cc2f7) by host99-221-dynamic.181-80-r.retail.telecomitalia.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1fhtcb-000XQI-qU for ccamp-archive@megatron.ietf.org; Tue, 4 Sep 2007 22:57:01 +0200 Message-ID: <000801c7ef36$10c18960$63ddb550@primo3778cc2f7> From: "simar Swafford" To: Subject: rauqgnol Date: Tue, 4 Sep 2007 22:56:29 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C7EF46.D44A5960" 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.2 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0006_01C7EF46.D44A5960 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.devildj.net/ How it is going ccamp-archive No girls laugh at me now, haha, i laugh at them mesut poep ------=_NextPart_000_0006_01C7EF46.D44A5960 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.devildj.net/
How it is going ccamp-archive
No girls laugh at me now, haha, i laugh at = them
mesut poep
------=_NextPart_000_0006_01C7EF46.D44A5960-- From kurlander@brookeenglish.com Tue Sep 04 17:04:12 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISfZE-0001Ps-Iq for ccamp-archive@ietf.org; Tue, 04 Sep 2007 17:04:12 -0400 Received: from host99-221-dynamic.181-80-r.retail.telecomitalia.it ([80.181.221.99]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISfZD-0005HT-Q0 for ccamp-archive@ietf.org; Tue, 04 Sep 2007 17:04:12 -0400 Received: from primo-3778cc2f7 ([180.104.17.64]:32451 "EHLO primo-3778cc2f7" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by host99-221-dynamic.181-80-r.retail.telecomitalia.it with ESMTP id S22ZAGKBZKHXVEMK (ORCPT ); Tue, 4 Sep 2007 23:04:24 +0200 Message-ID: <000c01c7ef37$24820910$63ddb550@primo3778cc2f7> From: "FRANK kurlander" To: Subject: rcbouter Date: Tue, 4 Sep 2007 23:04:11 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C7EF47.E80AD910" 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_0009_01C7EF47.E80AD910 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://desibany.com/ Wassup kurlander life is short, dont have a small cock all your life saffb Savoy ------=_NextPart_000_0009_01C7EF47.E80AD910 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://desibany.com/
Wassup kurlander
life is short, dont have a small cock all your = life
saffb Savoy
------=_NextPart_000_0009_01C7EF47.E80AD910-- From ftboa@yaphet.com Tue Sep 04 17:18:11 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISfml-0008MG-Eh; Tue, 04 Sep 2007 17:18:11 -0400 Received: from [125.129.179.46] (helo=[125.129.179.46]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISfml-0005go-0Q; Tue, 04 Sep 2007 17:18:11 -0400 Received: from [125.129.179.46] by mx5.biz.mail.yahoo.com; Tue, 35 Aug 2007 30:18:10 +0900 Message-ID: <0111ffa4$0111fe78$2eb3817d@ftboa> From: "Rod Gill" To: Subject: autocad 2008 Our price US $ 129.95 Date: Tue, 35 Aug 2007 30:18:10 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Spam-Score: 4.1 (++++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Save US $ 909.05 photoshop cs3 http://keiuuayr.cn From nancyscuilli@expectationministries.org Tue Sep 04 18:54:32 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IShI0-000800-AN for ccamp-archive@ietf.org; Tue, 04 Sep 2007 18:54:32 -0400 Received: from [85.103.98.24] (helo=[85.103.98.24]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IShHz-0007rk-NA for ccamp-archive@ietf.org; Tue, 04 Sep 2007 18:54:32 -0400 Received: from ozan-1e63802437 by expectationministries.org with ASMTP id BF3E2B51 for ; Wed, 5 Sep 2007 01:54:53 +0300 Received: from ozan-1e63802437 ([123.151.183.124]) by expectationministries.org with ESMTP id 8C71D44352A2 for ; Wed, 5 Sep 2007 01:54:53 +0300 Message-ID: Date: Wed, 5 Sep 2007 01:54:42 +0300 From: "nancy scuilli" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: ehsiraeb Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Wazzup scuilli With a larger manhood you penetrate more sensitive areas of the woman,, WOW fvgfxcg Schroyen http://www.digglog.com/ From Dericalloul@jecho.co.kr Tue Sep 04 22:59:12 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISl6m-0007zm-2V for ccamp-archive@megatron.ietf.org; Tue, 04 Sep 2007 22:59:12 -0400 Received: from [222.252.190.104] (helo=[222.252.190.104]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISl6j-00054X-0v for ccamp-archive@megatron.ietf.org; Tue, 04 Sep 2007 22:59:11 -0400 Received: by 10.10.66.19 with SMTP id TrGYtYAbutyUk; Wed, 5 Sep 2007 10:00:39 +0700 (GMT) Received: by 192.168.185.173 with SMTP id LhBdxIIzEkgxdG.3413171338805; Wed, 5 Sep 2007 10:00:37 +0700 (GMT) Message-ID: <000a01c7ef68$ed6f9aa0$68befcde@toaix0meflbpo4> From: "Deric alloul" To: Subject: 0pious Date: Wed, 5 Sep 2007 10:00:34 +0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7EFA3.99CE72A0" 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_0003_01C7EFA3.99CE72A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.dfwwh.com/ Wazzup Deric I fill her whole mouth now Kristina Collum ------=_NextPart_000_0003_01C7EFA3.99CE72A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.dfwwh.com/
Wazzup Deric
I fill her whole mouth now
Kristina Collum
------=_NextPart_000_0003_01C7EFA3.99CE72A0-- From bwenw87fpea@varig.com Tue Sep 04 23:23:48 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISlUZ-0007IC-WB; Tue, 04 Sep 2007 23:23:48 -0400 Received: from [83.221.171.223] (helo=ozzj) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ISlUX-0005aG-9x; Tue, 04 Sep 2007 23:23:47 -0400 To: From: "Thanh Tanisha" Subject: SAVE $ ~ Buy Prescription RX Medication Online DISCREETLY .... zchpi Message-ID: <6722m84204.1256o60008272@varig.com> Date: Wed, 05 Sep 2007 08:23:24 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--p9gggdme07dalyv6d41f9s8in3zd56" X-Spam-Score: 2.1 (++) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 ----p9gggdme07dalyv6d41f9s8in3zd56 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Save your $ Pharmacy : Pick the meds you want to order & checkout (2 steps to finish an order) : Fast delivery & discrete packaging to your doorstep : We sell both BRAND(100% original brand) & GENERIC(35% cheaper) : We give up to 70% discount (on retail shop price) for BOTH brand & generic meds : Meds we sell: Cia|lisViagra, UltramAtivan, CelebrexSoma, MeridiaClenbuterol, LuvoxPaxilZoloft & other 20 popular meds View all medications we have http://bmfbx.kgoazodiac.com http://bqpujx.kgoazodiac.com ----p9gggdme07dalyv6d41f9s8in3zd56 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Save your $ Pharmacy
: Pick the meds you want to order & checkout (2 steps to finish an order)
: Fast delivery & discrete packaging to your doorstep
: We sell both BRAND(100% original brand) & GENERIC(35% cheaper)
: We give up to 70% discount (on retail shop price) for BOTH brand & generic meds
: Meds we sell: Cia|lisViagra, UltramAtivan, CelebrexSoma, MeridiaClenbuterol, LuvoxPaxilZoloft & other 20 popular meds


View all medications we have (1st link)
If above link not load up, try this (2nd link)




place prettier teacher thank morning glass. worthy respect getting luck least everyone kept. ----p9gggdme07dalyv6d41f9s8in3zd56-- From ipezn26npx@backweb.com Wed Sep 05 01:08:34 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISn7y-0006R1-Gj; Wed, 05 Sep 2007 01:08:34 -0400 Received: from adsl-d238.84-47-58.t-com.sk ([84.47.58.238] helo=ndxqoco) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ISn7x-00082D-P8; Wed, 05 Sep 2007 01:08:34 -0400 To: From: "Majorie Jerilyn" Subject: 80% Save Codeine,Valiun, XanaK,AmbienK,PhenterminK,ViagraK,CialiK,SomaK zhz Message-ID: <6881q96346.69495f78900137@backweb.com> Date: Sat, 18 Aug 2007 07:10:16 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--jqqbuoyjvq3jvy4oqq19amrtzzu9rd" X-Spam-Score: 4.7 (++++) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b ----jqqbuoyjvq3jvy4oqq19amrtzzu9rd Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit PharmaShop 80% Discount - Discreet Packaging - Cheapest Medication - Worldwide shipping - Buy in Bulk and Save CodeineK XanaxK ValiumK PhenterminK ViagraK ViagraGelK CialiK CialiKSoftTabs ViagraSoftTabsK SomaK AdalatK AllegraK AmbienK AtaraxK AtivanK CiproK EffexorK GlucophageK LevitraK LipitorK MeridiaK NorvascK PaxilK PropeciaK ProzacK UltramK ZocorK ZoloftK ZybanK plus 30 meds more http://ktcerw.kgpatterned.com (Link 1) http://kwjku.kgpatterned.com (Link 2) ----jqqbuoyjvq3jvy4oqq19amrtzzu9rd Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
PharmaShop 80% Discount
Discreet Packaging
Cheapest Medication
Worldwide shipping
Buy in Bulk and Save
CodeineK
XanaxK
ValiumK
PhenterminK
ViagraK
ViagraGelK
CialiK
CialiKSoftTabs
ViagraSoftTabsK
SomaK
AdalatK
AllegraK
AmbienK
AtaraxK
AtivanK
CiproK
EffexorK
GlucophageK
LevitraK
LipitorK
MeridiaK
NorvascK
PaxilK
PropeciaK
ProzacK
UltramK
ZocorK
ZoloftK
ZybanK
plus 30 meds more
Buy Here - start from $72 (link A)
(link B)

choose added convenient interest. motor allowed really too place second either,



----jqqbuoyjvq3jvy4oqq19amrtzzu9rd-- From Irah.Milecki@g1sat.com Wed Sep 05 02:49:44 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISohs-0000ov-5l for ccamp-archive@ietf.org; Wed, 05 Sep 2007 02:49:44 -0400 Received: from 4-121.zicom.pl ([85.117.4.121]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISohr-00029p-G8 for ccamp-archive@ietf.org; Wed, 05 Sep 2007 02:49:43 -0400 Received: by 10.20.65.46 with SMTP id RUhZGGSwKhOgs; Wed, 5 Sep 2007 08:49:52 +0200 (GMT) Received: by 192.168.203.70 with SMTP id aiYZPNEfaNSRxc.0591954292886; Wed, 5 Sep 2007 08:49:50 +0200 (GMT) Message-ID: <1EF6C5E3.F3402B00@g1sat.com> Date: Wed, 5 Sep 2007 08:49:47 +0200 From: "Irah Milecki" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: jazzexpe Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.4 (+) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Good day Milecki its the size of ones penis that determines success Ouran Facendola http://www.divcerse.com/ From zlvtwelve@focustech.net Wed Sep 05 05:46:15 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISrSh-0002k7-K4 for ccamp-archive@ietf.org; Wed, 05 Sep 2007 05:46:15 -0400 Received: from host-89-229-64-197.szczecin.mm.pl ([89.229.64.197] helo=focustech.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ISrSg-0007bu-67 for ccamp-archive@ietf.org; Wed, 05 Sep 2007 05:46:15 -0400 Received: from monia ([155.176.253.166]:29294 "HELO monia" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by c540e559focustech.net with ESMTP id 431594910C407 (ORCPT ); Wed, 5 Sep 2007 11:46:12 +0200 Message-ID: <001601c7efb2$5b8ea280$0173acd4@monia> From: breast an To: ccamp-archive@ietf.org Subject: do previous Date: Wed, 5 Sep 2007 11:46:12 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C7EFB2.5B8EA280" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.1081 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C7EFB2.5B8EA280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Adventure's his bread, excitement's his butter and danger, why to being woven. As opposed to weaving on graph paper by hand, the communicati= on, we`re losing control over work everywhere from ------=_NextPart_000_0013_01C7EFB2.5B8EA280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Billy makes contact with Jim a DJ at Radio KAOS, a renegade rock

Are you wanting a bigger pe n _is?

As see -n on TV

Over 763,000 Men around the world are already satisfied
Gain 4+ Inches In Leng _th
Increase Your P _enis Wi _dth (Girth) By up _to 29%
100% Safe To Take, With NO Side Effects
No Pum _ps! No Sur _gery! No Exer _cises!
*3 FREE Bottles Of M -eg a Di -k

communications in a different way - an area of communications
------=_NextPart_000_0013_01C7EFB2.5B8EA280-- From owner-ccamp@ops.ietf.org Wed Sep 05 06:22:37 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISs1t-0007dC-Eh for ccamp-archive@ietf.org; Wed, 05 Sep 2007 06:22:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISs1s-0006ul-3Q for ccamp-archive@ietf.org; Wed, 05 Sep 2007 06:22:37 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ISrpZ-000MEB-4N for ccamp-data@psg.com; Wed, 05 Sep 2007 10:09:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE, STOX_REPLY_TYPE autolearn=no version=3.2.1 Received: from [212.23.8.67] (helo=fizeau.zen.co.uk) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ISrpW-000MDk-AU for ccamp@ops.ietf.org; Wed, 05 Sep 2007 10:09:51 +0000 Received: from [212.23.3.142] (helo=rutherford.zen.co.uk) by fizeau.zen.co.uk with esmtp (Exim 4.50) id 1ISrXu-000693-Lw for ccamp@ops.ietf.org; Wed, 05 Sep 2007 09:51:38 +0000 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1ISrXu-0003yC-GM for ccamp@ops.ietf.org; Wed, 05 Sep 2007 09:51:38 +0000 Received: from your029b8cecfe ([88.96.235.138] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Sep 2007 10:51:36 +0100 Message-ID: <010a01c7efa2$57cd20f0$0302a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Ross Callon" Subject: Plans for GELS work in CCAMP Date: Wed, 5 Sep 2007 10:51:19 +0100 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-OriginalArrivalTime: 05 Sep 2007 09:51:36.0685 (UTC) FILETIME=[596489D0:01C7EFA2] X-Originating-Rutherford-IP: [88.96.235.138] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Hi, We owe you a plan for starting the GELS work in CCAMP. As you may have seen, we have just sent a request to the ADs to push through our recharter as discussed on the mailing list. The ADs have already indicated their support, so hopefully this will be fairly smooth. We have also been talking with Don and Loa about starting work on the GELS drafts that we will accept into the working group as a starting point. (Other drafts can be added as needed.) 1. "GMPLS Extensions for PE to PE Ethernet Label Switched Paths(LSPs)" This document is the generic work: - Introduction - Rationale for GMPLS Control of Ethernet - Generic functional requirements (no data plane specifics!) - Applicability of existing protocol elements - New generic protocol elements (nothing specific to the data plane) 2. "GMPLS control of P2P TE for PBB-TE (802.1Qay)" Mainly references to the generic document. Some protocol specifics: - Code points (i.e. IANA section) - Label allocation and swapping rules Not a large document. Other drafts that we might also see: 3. "GMPLS control of P2P TE for IEEE802.1Q" Another data plane-specific draft, like 2, but for a different data plane 4. Applicability Statement A concise description of how and why to apply GMPLS to Ethernet. Probably not written until after the protocol work is done. We propose a relatively small design team to get this work started. Loa Andersson Lou Berger Don Fedyk George Swallow We are NOT trying to exclude anyone from the work, and we make a couple of observations: - A design team is just a group of people working on a draft. - Anyone and everyone is welcome to write a draft. - We feel that an initial design should be small to make rapid initial progress. - We welcome (and expect!) full and detailed contribution on the mailing list as this work progresses. - Everyone who contributes to a draft should be appropriately recognised in the draft. Last point: I propose to close the GELS mailing list now. Hope this is all satisfactory to you. Regards, Adrian and Deborah From owner-ccamp@ops.ietf.org Wed Sep 05 06:30:47 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISs9n-0004we-Mz for ccamp-archive@ietf.org; Wed, 05 Sep 2007 06:30:47 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISs9m-0000Qt-Lb for ccamp-archive@ietf.org; Wed, 05 Sep 2007 06:30:47 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ISrpf-000MFM-8q for ccamp-data@psg.com; Wed, 05 Sep 2007 10:09:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE, STOX_REPLY_TYPE autolearn=no version=3.2.1 Received: from [212.23.8.67] (helo=fizeau.zen.co.uk) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ISrpX-000MDk-V0 for ccamp@ops.ietf.org; Wed, 05 Sep 2007 10:09:57 +0000 Received: from [212.23.3.142] (helo=rutherford.zen.co.uk) by fizeau.zen.co.uk with esmtp (Exim 4.50) id 1ISqtK-00049y-P5 for ccamp@ops.ietf.org; Wed, 05 Sep 2007 09:09:42 +0000 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1ISqtJ-000709-PA for ccamp@ops.ietf.org; Wed, 05 Sep 2007 09:09:42 +0000 Received: from your029b8cecfe ([88.96.235.138] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Sep 2007 10:09:39 +0100 Message-ID: <00e301c7ef9c$7b64f8e0$0302a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Ross Callon" , Cc: Subject: CCAMP Proposed Recharter Date: Wed, 5 Sep 2007 10:09:27 +0100 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-OriginalArrivalTime: 05 Sep 2007 09:09:39.0884 (UTC) FILETIME=[7D432EC0:01C7EF9C] X-Originating-Rutherford-IP: [88.96.235.138] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Hi Ross and Dave, Please propose the attached recharter to the IESG for approval. Can you get it onto the agenda for this Thursday? Probably missed it :-( Thanks, Adrian and Deborah === First paragraph OLD The CCAMP working group coordinates the work within the IETF defining a common control plane and a separate common measurement plane for physical path and core tunneling technologies of Internet and telecom service providers (ISPs and SPs), e.g. O-O and O-E-O optical switches, ATM and Frame Relay switches, MPLS, GRE, in cooperation with the MPLS WG. NEW The CCAMP working group coordinates the work within the IETF defining a common control plane and a separate common measurement plane for physical path and core tunneling technologies of Internet and telecom service providers (ISPs and SPs), e.g. O-O and O-E-O optical switches, TDM switches, Ethernet switches, ATM and Frame Relay switches, IP encapsulation tunneling technologies, and MPLS in cooperation with the MPLS WG. === New paragraph in the list of Scope bullets. Suggest to place it after: "- Definition of MIB modules and other OAM techniques relevant to the protocols and extensions specified within the WG." and before: "CCAMP WG currently works on the following tasks:" - Work on traffic-engineering GMPLS mechanisms and protocol extensions to support source-controlled and explicitly-routed Ethernet data paths for Ethernet data planes that are already approved by an SDO with responsibility for the Ethernet data plane. It is expected that the primary SDO in this case is the IEEE. Note that the specification or modification of Ethernet data planes is out of scope. === Final paragraph OLD In doing this work, the WG will work closely with at least the following other WGs: MPLS, ISIS, OSPF, IDR, L1VPN and PCE. The WG will also cooperate with the ITU-T. NEW In doing this work, the WG will work closely with at least the following other WGs: MPLS, ISIS, OSPF, IDR, L1VPN, and PCE. The WG will also cooperate with the ITU-T and the IEEE 802.1. === Milestone revisions (see below for full revised milestone list) OLD Jan 2006 First version WG I-D for Protocol solutions for MLN/MRN NEW Sep 2007 First version WG I-D for Protocol solutions for MLN/MRN --- OLD Mar 2006 First version WG I-D GMPLS OAM Requirements NEW Sep 2007 First version WG I-D GMPLS OAM Requirements --- OLD Apr 2006 First version of WG I-D for additional MIB module to cover RSVP-TE signaling extensions NEW Nov 2007 First version of WG I-D for additional MIB module to cover RSVP-TE signaling extensions --- OLD Jun 2006 Submit Informational I-D for Analysis of inter-domain issues for disjoint and protected paths for IESG review NEW Oct 2007 Submit Informational I-D for Analysis of inter-domain issues for disjoint and protected paths for IESG review --- OLD Oct 2006 Submit MPLS to GMPLS migration strategies I-D for IESG review NEW Sep 2007 Submit MPLS-TE to GMPLS migration strategies I-D for IESG review --- OLD Nov 2006 Submit ASON Routing solutions I-D for IESG review NEW Jan 2008 Submit ASON Routing solutions I-D for IESG review --- OLD Dec 2006 Submit Requirements for Multi-Layer and Multi-Region Networks I-D for IESG review NEW Oct 2007 Submit Requirements for Multi-Layer and Multi-Region Networks I-D for IESG review --- OLD Jan 2007 Submit MPLS-GMPLS interworking requirements and solutions I-D for IESG review NEW Sep 2007 Submit MPLS-TE/GMPLS interworking requirements I-D for IESG review --- OLD Feb 2007 Submit Evaluation of existing protocols for MLN/MRN for IESG review NEW Oct 2007 Submit Evaluation of existing protocols for MLN/MRN for IESG review --- OLD Mar 2007 Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review NEW Dec 2007 Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review --- OLD Jun 2007 Submit GMPLS OAM Requirements I-D for IESG review NEW Feb 2008 Submit GMPLS OAM Requirements I-D for IESG review --- OLD Aug 2007 Submit Protocol solutions for MLN/MRN I-D for IESG review NEW Mar 2008 Submit Protocol solutions for MLN/MRN I-D for IESG review --- OLD Dec 2007 Submit MIB module for RSVP-TE signaling extensions for MIB doctor and IESG review NEW Apr 2008 Submit MIB module for RSVP-TE signaling extensions for MIB doctor and IESG review --- OLD Dec 2007 Recharter or close Working Group NEW Dec 2008 Recharter or close Working Group --- NEW Oct 2007 First version WG I-Ds for GMPLS source-controlled and explicitly-routed Ethernet networks --- NEW Sep 2008 Submit protocol extensions for GMPLS source-controlled and explicitly-routed Ethernet networks for IESG review ==== Goals and Milestones (full revised milestone list) Done Post strawman WG goals and charter Done Identify and document a limited set of candidate solutions for signalling and for measurement. Among candidate control solutions to be considered are the existing GMPLS drafts. Done Build appropriate design teams Done Submit WG document defining path setup portions of common control plane protocol Done Submit WG document defining common measurement plane protocol Done Submit LMP MIB to IESG Done Submit protection & restoration documents to IESG Done Submit ASON signaling requirements doc to IESG Done Submit GMPLS MIBs to IESG Done Produce CCAMP WG document for generic tunnel tracing protocol Done Produce CCAMP WG document for multi-area/AS signaling and routing Done Submit ASON routing requirements doc to IESG Done Submit revised charter and milestones to IESG for IESG consideration of more detailed deliverables and determination of usefulness of continuation of WG Done First version WG I-D for Advertising TE Node Capabilities in ISIS and OSPF Done First version WG I-D for Automatic discovery of MPLS-TE mesh membership Done Submit ASON Routing evaluation I-D for IESG review Done Cross-WG review of I-D for Advertising TE Node Capabilities in ISIS and OSPF Done First version WG I-D MPLS to GMPLS migration strategies Done First version WG I-D Requirements for Multi-Layer and Multi- Region Networks Done First version WG I-D for Evaluation of existing protocols for MLN/MRN Done First version of WG I-D for ASON Routing solutions Done Submit RSVP-TE extensions for inter-domain signaling I-D for IESG review Done Submit Per-domain path computation signaling I-D for IESG review Done First version of WG I-D for OSPF-TE/GMPLS MIB module Done Submit GMPLS signaling in support of Call Management I-D for IESG review Done First version WG Informational I-D for Analysis of inter- domain issues for disjoint and protected paths Done Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF for IESG review Done Submit GMPLS/ASON lexicography I-D for IESG review Done First version WG I-D MPLS-GMPLS interworking requirements and solutions Done Submit LSP Stitching I-D for IESG review Done Submit I-D for Automatic discovery of MPLS-TE mesh membership for IESG review Done Submit GMPLS routing and signaling interoperability advice I-D for IESG review Sep 2007 First version WG I-D for Protocol solutions for MLN/MRN Sep 2007 First version WG I-D GMPLS OAM Requirements Sep 2007 Submit MPLS-TE to GMPLS migration strategies I-D for IESG review Sep 2007 Submit MPLS-TE/GMPLS interworking requirements I-D for IESG review Oct 2007 First version WG I-Ds for GMPLS source-controlled and explicitly-routed Ethernet networks Oct 2007 Submit Informational I-D for Analysis of inter-domain issues for disjoint and protected paths for IESG review Oct 2007 Submit Requirements for Multi-Layer and Multi-Region Networks I-D for IESG review Oct 2007 Submit Evaluation of existing protocols for MLN/MRN for IESG review Nov 2007 First version of WG I-D for additional MIB module to cover RSVP-TE signaling extensions Dec 2007 Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review Jan 2008 Submit ASON Routing solutions I-D for IESG review Feb 2008 Submit GMPLS OAM Requirements I-D for IESG review Mar 2008 Submit Protocol solutions for MLN/MRN I-D for IESG review Apr 2008 Submit MIB module for RSVP-TE signaling extensions for MIB doctor and IESG review Sep 2008 Submit protocol extensions for GMPLS source-controlled and explicitly-routed Ethernet networks for IESG review Dec 2008 Recharter or close Working Group ==== From luyang147@level42dk.dk Wed Sep 05 06:53:58 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISsWE-0005kL-U1 for ccamp-archive@megatron.ietf.org; Wed, 05 Sep 2007 06:53:58 -0400 Received: from pool-71-106-220-248.lsanca.dsl-w.verizon.net ([71.106.220.248]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISsWE-00016j-GC for ccamp-archive@megatron.ietf.org; Wed, 05 Sep 2007 06:53:58 -0400 Received: by 10.103.83.104 with SMTP id kGClkVtAwiAyd; Wed, 5 Sep 2007 03:54:04 -0700 (GMT) Received: by 192.168.56.22 with SMTP id XOGTTSPVcZLLgX.2393425882025; Wed, 5 Sep 2007 03:54:02 -0700 (GMT) Message-ID: <000401c7efab$102c8e30$f8dc6a47@IRWorkstation> From: "luyang ledetsch" To: Subject: gniltril Date: Wed, 5 Sep 2007 03:53:59 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C7EF70.63CDB630" 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.6 (++++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0005_01C7EF70.63CDB630 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://dggslaw.com/ Hi bro ccamp-archive My wife complains about my small cock ALL THE TIME! Eddi Tal ------=_NextPart_000_0005_01C7EF70.63CDB630 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi bro ccamp-archive
My wife complains about my small cock ALL THE = TIME!
Eddi Tal
------=_NextPart_000_0005_01C7EF70.63CDB630-- From Mhyar-Cacarillo@dermatoscopes.de Wed Sep 05 07:34:51 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISt9n-000321-Mu for ccamp-archive@ietf.org; Wed, 05 Sep 2007 07:34:51 -0400 Received: from [88.226.96.106] (helo=dsl88-226-24682.ttnet.net.tr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISt9m-0002DQ-P6 for ccamp-archive@ietf.org; Wed, 05 Sep 2007 07:34:51 -0400 Received: by 10.130.38.17 with SMTP id IHChJBgOuggHS; Wed, 5 Sep 2007 14:34:56 +0300 (GMT) Received: by 192.168.24.89 with SMTP id XRNNBLYgsVWlfU.7857693818180; Wed, 5 Sep 2007 14:34:54 +0300 (GMT) Message-ID: <000a01c7efb0$c5d3c0a0$6a60e258@isa> From: "Mhyar Cacarillo" To: Subject: mmill{{p Date: Wed, 5 Sep 2007 14:34:51 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C7EFC9.EB20F8A0" 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.0 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0008_01C7EFC9.EB20F8A0 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable http://www.devildj.net/ Hi bro Cacarillo its the size of ones penis that determines success KWH Bunge ------=_NextPart_000_0008_01C7EFC9.EB20F8A0 Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable
http://www.devildj.net/
Hi bro Cacarillo
its the size of ones penis that determines = success
KWH Bunge
------=_NextPart_000_0008_01C7EFC9.EB20F8A0-- From owner-ccamp@ops.ietf.org Wed Sep 05 08:29:14 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISu0Q-0006mN-L2 for ccamp-archive@ietf.org; Wed, 05 Sep 2007 08:29:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISu0P-0001jm-Ce for ccamp-archive@ietf.org; Wed, 05 Sep 2007 08:29:14 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IStoL-0004Cg-5T for ccamp-data@psg.com; Wed, 05 Sep 2007 12:16:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IStoE-0004C6-He for ccamp@ops.ietf.org; Wed, 05 Sep 2007 12:16:40 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4F03D203CF; Wed, 5 Sep 2007 14:16:29 +0200 (CEST) X-AuditID: c1b4fb3e-b0835bb0000007e1-d8-46de9e1c80e5 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3A558200AA; Wed, 5 Sep 2007 14:16:28 +0200 (CEST) Received: from esealmw110.eemea.ericsson.se ([153.88.200.78]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Sep 2007 14:16:27 +0200 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: Plans for GELS work in CCAMP Date: Wed, 5 Sep 2007 14:16:52 +0200 Message-ID: <0428AC48A879ED46A94F39D5665DF684A57990@esealmw110.eemea.ericsson.se> In-Reply-To: <010a01c7efa2$57cd20f0$0302a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Plans for GELS work in CCAMP Thread-Index: AcfvpXVNtKK3xihBQqWj+KXVTZuTDAADztvQ From: "Diego Caviglia (GA/ERI)" To: "Adrian Farrel" , Cc: "Ross Callon" X-OriginalArrivalTime: 05 Sep 2007 12:16:27.0780 (UTC) FILETIME=[95B06440:01C7EFB6] X-Brightmail-Tracker: AAAAAA== Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Hi Adrian hi Deborah, I think that this is a very good way to proceed I = also think the people in the DT are the right ones. I'd like to contribute this work so DT guys please fill free to contact = me. Best Regards Diego > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf > Of Adrian Farrel > Sent: mercoled=EC 5 settembre 2007 11.51 > To: ccamp@ops.ietf.org > Cc: Ross Callon > Subject: Plans for GELS work in CCAMP >=20 > Hi, >=20 > We owe you a plan for starting the GELS work in CCAMP. >=20 > As you may have seen, we have just sent a request to the ADs to push > through > our recharter as discussed on the mailing list. The ADs have already > indicated their support, so hopefully this will be fairly smooth. >=20 > We have also been talking with Don and Loa about starting work on the = GELS > drafts that we will accept into the working group as a starting point. > (Other drafts can be added as needed.) >=20 > 1. "GMPLS Extensions for PE to PE Ethernet Label Switched Paths(LSPs)" > This document is the generic work: > - Introduction > - Rationale for GMPLS Control of Ethernet > - Generic functional requirements (no data plane specifics!) > - Applicability of existing protocol elements > - New generic protocol elements (nothing specific to the data plane) >=20 > 2. "GMPLS control of P2P TE for PBB-TE (802.1Qay)" > Mainly references to the generic document. > Some protocol specifics: > - Code points (i.e. IANA section) > - Label allocation and swapping rules > Not a large document. >=20 > Other drafts that we might also see: >=20 > 3. "GMPLS control of P2P TE for IEEE802.1Q" > Another data plane-specific draft, like 2, but for a different data = plane >=20 > 4. Applicability Statement > A concise description of how and why to apply GMPLS to Ethernet. > Probably not written until after the protocol work is done. >=20 > We propose a relatively small design team to get this work started. > Loa Andersson > Lou Berger > Don Fedyk > George Swallow >=20 > We are NOT trying to exclude anyone from the work, and we make a = couple of > observations: >=20 > - A design team is just a group of people working on a > draft. > - Anyone and everyone is welcome to write a draft. > - We feel that an initial design should be small to make > rapid initial progress. > - We welcome (and expect!) full and detailed contribution > on the mailing list as this work progresses. > - Everyone who contributes to a draft should be appropriately > recognised in the draft. >=20 > Last point: > I propose to close the GELS mailing list now. >=20 > Hope this is all satisfactory to you. >=20 > Regards, > Adrian and Deborah >=20 >=20 From alt@mailusb.com Wed Sep 05 09:06:22 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISuaL-0002MP-UL for ccamp-archive@ietf.org; Wed, 05 Sep 2007 09:06:21 -0400 Received: from [125.187.32.130] (helo=m00.mailyes.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISuaL-00055G-6U for ccamp-archive@ietf.org; Wed, 05 Sep 2007 09:06:21 -0400 Received: (qmail 31950 invoked by uid 0); 5 Sep 2007 21:39:01 +0900 Message-ID: <20070905123901.31949.qmail@m00.mailyes.net> To: ccamp-archive Subject: =?ISO-2022-JP?B?GyRCJDQ2YT1qJEcwKSQoJGsbKEI=?= =?ISO-2022-JP?B?GyRCISolZCRsJGshKhsoQg==?= From: message Reply-to: delivery_rt Date: 2007-09-05 21:30:08 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: GOOD Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20070904180439_cbvm Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 4.4 (++++) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 $B!!!!!!(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B!!!!!!!!!z!!$46a=j=P2q$$$+$i$N!!$*!!F@!!>p!!Js!!!z(B $B!!!!!!(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B!!!!!!!!!!!!"v(BVIP$B=w@-$N$4>R2p"v!AB(2q$$$X$NF;!A(B $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!(B $B!?!@!?!@!?!@!?!@!?!@!?!@!?!@!?!@!?!@!?!@!?!@!?!@!?!@!?!@!?!@!?!@!?(B $B!@!?:G=*9pCN(B!!$B!!%3%l$rF($7$?$i5.J}$NL$Mh$O!&!&!&L5$$(B!! $B(#!=!=($WD(B $B!C!@!?('!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=(B $B(&!=!=(%(B $B!!%2%j%i%$%Y%s%H=*N;$^$G$"$H$o$:$+!*(B $B!!4JC1EPO?!u7G<(HD=q$-9~$_$G4JC1$K!_!_$,!*#2=54VJg=8$7$F$*$j$^$9!#%.%j%.%jEPO?$G!!$b==J,;q3J$OF@$i$l$^$9(B? $B!!(Bhttp://black-6969.org.uk/pc/index2.php?u9psp4 $B!!(B $B!!LGB?$K$*L\$K$+$+$l$J$$(BVIP$B2q0wMM$H$N$*IU$-9g$$$H%P%C%/%"%C%W$r"v(B> $B!~(,(,(,(,"!(,!~(,"!(,!~(,"!(,!~(B -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- $B"#"""#(B http://black-6969.org.uk/pc/index2.php?u9psp4 $B"#"""#(B $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!($(B $B:G9bJv=P2q$$%5%$%H!*!X$46a=j=P2q$$!Y(B URL $B!'(B http://black-6969.org.uk/pc/index2.php?u9psp4 $B$3$N%a!<%k$K=q$+$l$?FbMF$NL5CG7G:\!"L5CGJ#@=$r6X$8$^$9!#(B Copyright (C) 2007 gokinjo All Rights Reserved. $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(%(B $B"(G[?.Dd;_$O$3$A$i$+$i(B notmail@gmail.com From owner-ccamp@ops.ietf.org Wed Sep 05 11:46:00 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISx4q-0007nm-OS for ccamp-archive@ietf.org; Wed, 05 Sep 2007 11:46:00 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISx4p-0006eO-HP for ccamp-archive@ietf.org; Wed, 05 Sep 2007 11:46:00 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ISwrg-000HJn-5F for ccamp-data@psg.com; Wed, 05 Sep 2007 15:32:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [192.26.91.6] (helo=mandala.kddilabs.jp) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ISwrd-000HJS-CL for ccamp@ops.ietf.org; Wed, 05 Sep 2007 15:32:22 +0000 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 28A8AEC99A; Thu, 6 Sep 2007 00:32:20 +0900 (JST) Received: from mail.cn.kddilabs.jp (yellow.lan.kddilabs.jp [2001:200:601:1a00::10]) by mandala.kddilabs.jp (Postfix) with ESMTP id E7AC5EC996; Thu, 6 Sep 2007 00:32:18 +0900 (JST) Received: from [127.0.0.1] (c013.vpn.kddilabs.jp [172.19.87.13]) by mail.cn.kddilabs.jp (Postfix) with ESMTP id CBF371E0002; Thu, 6 Sep 2007 00:32:18 +0900 (JST) Message-ID: <46DECC02.4070502@kddilabs.jp> Date: Thu, 06 Sep 2007 00:32:18 +0900 From: Kenji Kumaki User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Adrian Farrel Cc: ccamp@ops.ietf.org Subject: Re: Working Group last calls completed : MPLS/GMPLS interworking and migration References: <09a101c7dab4$f6cae910$5002010a@your029b8cecfe> <01a101c7eb36$ad2d3190$0300a8c0@your029b8cecfe> In-Reply-To: <01a101c7eb36$ad2d3190$0300a8c0@your029b8cecfe> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Hi Adrian, These I-Ds are ready to move forward as RFCs. Of course,we welcome WG feedback and comments. Regards, Kenji Adrian Farrel wrote: > Hi, > > These last calls completed while I was travelling. I have scanned the > mail list and I didn't see any comments. I also received no comments > privately. > > Maybe the drafts are in perfect shape. Maybe no-one had time to read them. > > Please can I get a feeling from the working group: > > Are these I-Ds ready to move forward as RFCs? > > "Framework for MPLS-TE to GMPLS migration" > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-03.txt > > > "Interworking Requirements to Support operation of MPLS-TE over GMPLS > Networks" > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-reqts-01.txt > > > Thanks, > Adrian > > ----- Original Message ----- From: "Adrian Farrel" > To: > Sent: Thursday, August 09, 2007 7:41 PM > Subject: Working Group last call on MPLS/GMPLS interworking and migration > > >> Hi, >> . >> Two working group drafts have reached the position where the authors >> consider them ready for last call (actually, a whole bunch have >> arrived there at the same time, but we want to dribble them through >> the last call process). >> >> These two documents concern the operation of MPLS over GMPLS, and the >> migration from MPLS to GMPLS. >> >> The "Framework for MPLS-TE to GMPLS migration" is (the rather poorly >> named) >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-03.txt >> >> >> The "Interworking Requirements to Support operation of MPLS-TE over >> GMPLS Networks" are in >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-reqts-01.txt >> >> >> The documents are both Informational. >> >> Please send your comments (preferably to the list) by the end of WG >> last call which will be 12 noon GMT 24th August 2007. >> >> Thanks, >> Adrian >> >> >> > > > > From falkner@tvldyn.com Wed Sep 05 12:57:26 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISyBy-0006wI-8I for ccamp-archive@ietf.org; Wed, 05 Sep 2007 12:57:26 -0400 Received: from [77.243.97.124] (helo=77.243.97.124) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISyBx-0002fE-K4 for ccamp-archive@ietf.org; Wed, 05 Sep 2007 12:57:26 -0400 Received: from [77.243.97.124] by PARK4.SECURESERVER.net; Wed, 05 Sep 2007 16:57:19 +0000 Message-ID: <000601c7efdd$050dbf96$300ed38e@uskvmldk> From: "fidelio garry" To: Subject: Low Interest Loan Date: Wed, 05 Sep 2007 15:09:57 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7EFDD.050B37AB" 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: 2.7 (++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C7EFDD.050B37AB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A LOW INTEREST LOAN - NO STRINGS ATTACHED! No hassle at all, completely unsecured. There are no hidden costs or = fees.=20 Just call the number below. You'll thank me later! Call Free 1-877-208-5642 24 hours a day, 7 days a week including Sundays and Holidays! ------=_NextPart_000_0003_01C7EFDD.050B37AB Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

A LOW INTEREST = LOAN - NO STRINGS ATTACHED!

No hassle at all, = completely unsecured. There are no hidden costs or fees. =

Just call the number = below. You'll thank me later!

Call = Free 1-877-208-5642

24 hours a day, 7 days = a week including Sundays and Holidays!

------=_NextPart_000_0003_01C7EFDD.050B37AB-- From tzivos-h@mogokrubyland.com Wed Sep 05 19:48:31 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT4bm-0006nz-Vc; Wed, 05 Sep 2007 19:48:31 -0400 Received: from [12.206.100.238] (helo=[12.206.100.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IT4bi-00068b-VS; Wed, 05 Sep 2007 19:48:30 -0400 Received: from [12.206.100.238] by hex11.freehostia.com; Wed, 36 Aug 2007 18:48:34 -0500 Message-ID: <00f0ffa4$00f0fe78$ee64ce0c@tzivos-h> From: "Devon Shafer" To: Subject: Adobe CS3 Extended Retail Price $999 save: $909.05 Date: Wed, 36 Aug 2007 18:48:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1830 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 adobe acrobat Professional $79.95 you save $369 http://atatayiu.cn From HattievoidHollingsworth@atlantic.com Wed Sep 05 22:23:54 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT72A-00074P-6I for ccamp-archive@ietf.org; Wed, 05 Sep 2007 22:23:54 -0400 Received: from c-68-60-61-206.hsd1.mi.comcast.net ([68.60.61.206] helo=yourd0f670b45a) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IT729-0001DS-Of for ccamp-archive@ietf.org; Wed, 05 Sep 2007 22:23:53 -0400 Message-ID: From: "Faye Billings" To: Subject: Re: Thanks, we accepted your company business loan request Date: Wed, 5 Sep 2007 22:21:34 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_F46F_01C7F02C.F62278B0" 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.4 (++++) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 ------=_NextPart_000_F46F_01C7F02C.F62278B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If you have your own business and want IMMEDIATE ready money to spend = ANY way you like or require Extra money to give the business a boost or = need A low interest loan - NO STRINGS ATTACHED, here is the deal we can = offer you THIS EVENING (hurry, this tender will expire NOW): $52,000+ loan Hurry, when our best deal is gone, it is gone. Simply Call Us Free on = 877-482-4954 ------=_NextPart_000_F46F_01C7F02C.F62278B0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If you have your own business and want = IMMEDIATE=20 ready money to spend ANY way you like or require Extra money to give the = business a boost or need A low interest loan - NO STRINGS ATTACHED, = here is=20 the deal we can offer you THIS EVENING (hurry, this tender will expire=20 NOW):
=20
 
$52,000+ loan
 
Hurry, when our best deal is gone, it = is gone.=20 Simply Call Us Free on 877-482-4954
------=_NextPart_000_F46F_01C7F02C.F62278B0-- From gnds50eaia@baxter.com Thu Sep 06 03:48:12 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITC60-0000Mh-FK; Thu, 06 Sep 2007 03:48:12 -0400 Received: from 89-109-18-36.dynamic.mts-nn.ru ([89.109.18.36] helo=pwrx) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ITC5z-0001Fz-MO; Thu, 06 Sep 2007 03:48:12 -0400 To: From: "Larissa Latosha" Subject: Make YourPenis 3-inches longer & thicker, girl will love you eimn Message-ID: <9042b35737.374o00458117@baxter.com> Date: Thu, 06 Sep 2007 11:48:10 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--sbpuxknjvvgj1k3tvopasn4qr9hb" X-Spam-Score: 2.0 (++) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 ----sbpuxknjvvgj1k3tvopasn4qr9hb Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Safe & Effective PenisEnlargement Over 1,500,000 bottles sold worldwide WeOffer Full MoneyBack Guarantee if you are not completely satisfied with the results of Man-XL, you have nothing to lose, just a lot to gain 1) Gain Up to 3+ Inches In Length 2) Increase YourPenis Width (Girth) By upto 20% 3) Help Stop PrematureEjaculation! 4) Produce Stronger, Rock HardErections 5) 100% Safe To Take, With NO Side Effects 6) Fast Shipping WorldWide 7) Doctor Approved And Recommended 8) No Pumps, No Surgery, No Exercises 9) Very discrete shipping and billing 10) Up to 3 FREE Bottles Of Man-XL 11) Highly secure 128bit order processing Buy This herbal EnlargementPills here http://dofox.khtable.com http://doruj.khtable.com ----sbpuxknjvvgj1k3tvopasn4qr9hb Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Safe & Effective PenisEnlargement
Over 1,500,000 bottles sold worldwide
WeOffer Full MoneyBack Guarantee if you are not completely satisfied with the results of Man-XL, you have nothing to lose, just a lot to gain
1) Gain Up to 3+ Inches In Length
2) Increase YourPenis Width (Girth) By upto 20%
3) Help Stop PrematureEjaculation!
4) Produce Stronger, Rock HardErections
5) 100% Safe To Take, With NO Side Effects
6) Fast Shipping WorldWide
7) Doctor Approved And Recommended
8) No Pumps, No Surgery, No Exercises
9) Very discrete shipping and billing
10) Up to 3 FREE Bottles Of Man-XL
11) Highly secure 128bit order processing
Did you know... Man-XL was featured in leading mens magazines such as FHM, MAXIM, plus many others, and rated No.1 choice forPenisEnlargement Also seen on TV
Buy This herbal EnlargementPills here (Link 1)
(Link 2)




ten twenty-one account telling choose mother. planning embarrass busy sale turn wish.
----sbpuxknjvvgj1k3tvopasn4qr9hb-- From owner-ccamp@ops.ietf.org Thu Sep 06 05:39:52 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITDq4-0001gd-Ik for ccamp-archive@ietf.org; Thu, 06 Sep 2007 05:39:52 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITDq2-0003pk-5h for ccamp-archive@ietf.org; Thu, 06 Sep 2007 05:39:50 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITDeK-000HiH-Lc for ccamp-data@psg.com; Thu, 06 Sep 2007 09:27:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [212.23.3.140] (helo=pythagoras.zen.co.uk) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITDeF-000Hhb-5Q for ccamp@ops.ietf.org; Thu, 06 Sep 2007 09:27:43 +0000 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1ITDeC-0002JT-AN for ccamp@ops.ietf.org; Thu, 06 Sep 2007 09:27:36 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Sep 2007 10:27:35 +0100 Message-ID: <020501c7f068$270d0c20$0302a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , "gels" Cc: "Ross Callon" References: <53CCFDD6E346CB43994852666C210E9101FB483B@esealmw116.eemea.ericsson.se> <014f01c7eb1f$3272db10$0300a8c0@your029b8cecfe> <46D7DDC6.8000205@pi.se> Subject: Closing the GELS Mailing List Date: Thu, 6 Sep 2007 10:27:26 +0100 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-OriginalArrivalTime: 06 Sep 2007 09:27:35.0861 (UTC) FILETIME=[2901FE50:01C7F068] X-Originating-Pythagoras-IP: [88.96.235.138] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a We propose to close the GELS mailing list. Loa wrote... > I tend to support this, but it begs two questions: > > - when will the charter update be ack'ed? I don't know, and I can't promise that it will be ack'ed. but the Routing ADs appear to support the change. > - in the (unlikely) case where we don't get an ack for > gels work the gels-list won't be needed anyhow, so; > isn't the effect of the of your statement below that > the gels-list is dead as of now? Especially since the > on thing we are discussing at the moment is the charter > update and this is on the ccamp list?? Absolutely. I'll give you all a last chance to scream. Thanks, Adrian From familyhewitt@btinternet.com Thu Sep 06 05:44:13 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITDuH-0005yJ-H7 for ccamp-archive@megatron.ietf.org; Thu, 06 Sep 2007 05:44:13 -0400 Received: from [195.16.73.101] (helo=[195.16.73.101]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITDuG-0003xN-T4 for ccamp-archive@megatron.ietf.org; Thu, 06 Sep 2007 05:44:13 -0400 Received: from [195.16.73.101] by ; Thu, 6 Sep 2007 14:36:36 +0500 Date: Thu, 6 Sep 2007 14:36:36 +0500 From: Riley X-Mailer: The Bat! (v3.51.10) Educational Reply-To: familyhewitt@btinternet.com X-Priority: 3 (Normal) Message-ID: <036664983.58269549060510@btinternet.com> To: ccamp-archive@megatron.ietf.org Subject: Special Offer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 New pharmacy shop http://eveningcommon.com From faks@earthlink.net Thu Sep 06 05:47:06 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITDx4-0000xn-LT; Thu, 06 Sep 2007 05:47:06 -0400 Received: from adsl-d25.84-47-12.t-com.sk ([84.47.12.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITDx4-000438-7H; Thu, 06 Sep 2007 05:47:06 -0400 Received: from [84.47.12.25] by mx3.earthlink.net; Thu, 6 Sep 2007 10:47:12 +0100 Message-ID: <01c7f06a$e631c710$190c2f54@faks> From: "Heriberto Terry" To: Subject: =?koi8-r?B?98HNIM7V1sXOINDB09DP0tQgyczJINfPxMnUxczY08vPxSDVxM/T1A==?= =?koi8-r?B?z9fF0sXOycUgPw==?= Date: Thu, 6 Sep 2007 10:47:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 2.3 (++) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 ÷ÁÍ ÎÕÖÅÎ ÐÁÓÐÏÒÔ ÉÌÉ ×ÏÄÉÔÅÌØÓËÏÅ ÕÄÏÓÔÏ×ÅÒÅÎÉÅ ? éÚÇÏÔÏ×ÌÅÎÉÅ ÐÁÓÐÏÒÔÏ× òæ , ×ÏÄÉÔÅÌØÓËÉÈ ÕÄÏÓÔÏ×ÅÒÅÎÉÊ Á ÔÁË ÖÅ ÐÁÓÐÏÒÔÏ× É ×ÏÄÉÔÅÌØÓËÉÈ ÕÄÏÓÔÏ×ÅÒÅÎÉÊ ÎÅÓËÏÌØËÉÈ ÓÔÒÁÎ å×ÒÏÓÏÀÚÁ. ÷ÓÑ ÉÎÆÏÒÍÁÃÉÑ ÅÓÔØ ÎÁ ÎÁÛÅÍ ÓÁÊÔÅ: WWW.NEW-PASSPORT.BIZ e-mail: pasport111@gmail.com ICQ: 456-436-029 From qvicoffee@suffix.com Thu Sep 06 08:52:45 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITGqj-0004l6-Co for ccamp-archive@ietf.org; Thu, 06 Sep 2007 08:52:45 -0400 Received: from ecr170.internetdsl.tpnet.pl ([83.14.173.170]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ITGqi-0000l8-AA for ccamp-archive@ietf.org; Thu, 06 Sep 2007 08:52:45 -0400 Received: from domo6zjw1czazn ([166.1.5.152]:26072 "HELO domo6zjw1czazn" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by aaad0e53suffix.com with ESMTP id p6GPNATJ186513 (ORCPT ); Thu, 6 Sep 2007 14:52:43 +0200 Message-ID: <001c01c7f095$94537800$0651369c@domo6zjw1czazn> From: familiar the To: ccamp-archive@ietf.org Subject: of mythology Date: Thu, 6 Sep 2007 14:52:43 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C7F095.94537800" 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: 2.0 (++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C7F095.94537800 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable medium, and did, but my friend, who is an Economics major, just software. It seems awfully limiting. Am I missing something? Is congregate= daily if they chose. It is just about as likely that ------=_NextPart_000_0019_01C7F095.94537800 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable

With respect to the affects of technology on society, we have

Are you wanting a bigger p e n _i s?

As se -e -n on TV

Over 784,000 Men around the world are already satisfied
Gain 2+ Inches In Leng _th
Increase Your P _en -is Wi _dth (Girth) By up _to 25%
100% Safe To Take, With NO Side Effects
No Pum _ps! No Surgery! No Exercises!
*3 FREE Bottles Of M -e _g a D _i -k

their threat to your health Luckily, there is an increased
------=_NextPart_000_0019_01C7F095.94537800-- From nljbowling@benports.com Thu Sep 06 08:56:00 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITGts-0007zU-6I for ccamp-archive@ietf.org; Thu, 06 Sep 2007 08:56:00 -0400 Received: from [89.222.216.130] (helo=benports.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ITGtr-0000oU-GR for ccamp-archive@ietf.org; Thu, 06 Sep 2007 08:56:00 -0400 Received: from antoshin ([214.155.120.119]:44379 "HELO antoshin" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 82d8de59benports.com with ESMTP id 290A230C2E62 (ORCPT ); Thu, 6 Sep 2007 16:57:18 +0400 Message-ID: <001b01c7f0a6$fbc81660$0064b364@antoshin> From: Diana To: ccamp-archive@ietf.org Subject: On government Date: Thu, 6 Sep 2007 16:57:18 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C7F0A6.FBC81660" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2969 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C7F0A6.FBC81660 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable home. Consequently, the environment we live in may benefit from into the states, around Canada or Mexico, but in the last few for downtown = office space will drive the rent/lease prices down, ------=_NextPart_000_0018_01C7F0A6.FBC81660 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

globally competitive". And we have already seen some examples of

Are you wanting a bigger p e n _i s?

As se -e -n on TV

Over 735,000 Men around the world are already satisfied
Gain 4+ Inches In Leng _th
Increase Your P _en -is Wi _dth (Girth) By up _to 27%
100% Safe To Take, With NO Side Effects
No Pum _ps! No Surgery! No Exercises!
*3 FREE Bottles Of M -e _g a D _i -k

information and communications technologies are spreading rapidly ------=_NextPart_000_0018_01C7F0A6.FBC81660-- From lloyd@galileo.com Thu Sep 06 09:58:11 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITHs3-0007Q3-Jb for ccamp-archive@ietf.org; Thu, 06 Sep 2007 09:58:11 -0400 Received: from m4698p014.adsl.highway.telekom.at ([212.183.103.46]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITHs2-0002wU-Kl for ccamp-archive@ietf.org; Thu, 06 Sep 2007 09:58:11 -0400 Received: from [212.183.103.46] by cmtu.mt.ns.els-gms.att.net; Thu, 06 Sep 2007 13:58:10 +0000 Message-ID: <000501c7f08d$03e6335f$c2069896@syhffb> From: "gav jui" To: Subject: IMMEDIATE cash to spend ANY way you like Date: Thu, 06 Sep 2007 12:10:47 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C7F08D.03E629C4" 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.9 (++++) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C7F08D.03E629C4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No Hassle Business Loans! If you have your own business and want: - IMMEDIATE cash to spend ANY way you like - Extra money to give the business a boost. Worried that your credit is less than perfect? Not an issue. Just call the number below. You'll thank me later! Call Free 1-877-208-5642 24 hours a day, 7 days a week including Sundays and Holidays! ------=_NextPart_000_0002_01C7F08D.03E629C4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

No Hassle Business Loans!

If you have your own business and = want:

- IMMEDIATE cash to spend ANY way you = like
- Extra money to give the business a boost.

Worried that your credit is less than = perfect? Not an issue.

Just call the number = below.

You'll thank me later!

Call Free = 1-877-208-5642

24 hours a day, 7 days a week = including Sundays and Holidays!

------=_NextPart_000_0002_01C7F08D.03E629C4-- From owner-ccamp@ops.ietf.org Thu Sep 06 10:13:28 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITI6q-0000FP-L0 for ccamp-archive@ietf.org; Thu, 06 Sep 2007 10:13:28 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITI6q-0003Q6-5S for ccamp-archive@ietf.org; Thu, 06 Sep 2007 10:13:28 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITHtt-000Geb-9A for ccamp-data@psg.com; Thu, 06 Sep 2007 14:00:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [64.208.49.27] (helo=smail5.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITHtq-000GcY-B3 for ccamp@ops.ietf.org; Thu, 06 Sep 2007 14:00:04 +0000 Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l86DwqCp026094; Thu, 6 Sep 2007 15:59:20 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS07.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 6 Sep 2007 15:59:50 +0200 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: Closing the GELS Mailing List Date: Thu, 6 Sep 2007 15:59:47 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E380012B228B@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <020501c7f068$270d0c20$0302a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing the GELS Mailing List thread-index: AcfwaJE8wbS3itLlS+ScmNci3tMldgAD569Q References: <53CCFDD6E346CB43994852666C210E9101FB483B@esealmw116.eemea.ericsson.se> <014f01c7eb1f$3272db10$0300a8c0@your029b8cecfe> <46D7DDC6.8000205@pi.se> <020501c7f068$270d0c20$0302a8c0@your029b8cecfe> From: "PAPADIMITRIOU Dimitri" To: "Adrian Farrel" , , "gels" Cc: "Ross Callon" X-OriginalArrivalTime: 06 Sep 2007 13:59:50.0771 (UTC) FILETIME=[315F7430:01C7F08E] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca adrian, you could leave the gels list for the list for the techno-specific discussions and the ccamp list for the non-techno specific discussions in any case, i believe the value of gels was so far to allow open discussion on a topic that was on charter=20 -> question: does proposed incorporation in charter (with milestones to be better shaped inline with progress of IEEE) elevate any other need ? complete decoupling of discussion has been shown to be difficult to be realized in the past thanks, -dimitri. =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Thursday, September 06, 2007 11:27 AM > To: ccamp@ops.ietf.org; gels > Cc: Ross Callon > Subject: Closing the GELS Mailing List >=20 > We propose to close the GELS mailing list. >=20 > Loa wrote... >=20 > > I tend to support this, but it begs two questions: > > > > - when will the charter update be ack'ed? >=20 > I don't know, and I can't promise that it will be ack'ed. but=20 > the Routing ADs appear to support the change. >=20 > > - in the (unlikely) case where we don't get an ack for > > gels work the gels-list won't be needed anyhow, so; > > isn't the effect of the of your statement below that > > the gels-list is dead as of now? Especially since the > > on thing we are discussing at the moment is the charter > > update and this is on the ccamp list?? >=20 > Absolutely. >=20 > I'll give you all a last chance to scream. >=20 > Thanks, > Adrian=20 From owner-ccamp@ops.ietf.org Thu Sep 06 10:35:02 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITIRi-0000ZS-0c for ccamp-archive@ietf.org; Thu, 06 Sep 2007 10:35:02 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITIRh-00045L-If for ccamp-archive@ietf.org; Thu, 06 Sep 2007 10:35:01 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITIJv-000JCI-4u for ccamp-data@psg.com; Thu, 06 Sep 2007 14:26:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [62.23.212.7] (helo=smail6.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITIJr-000JBr-PZ for ccamp@ops.ietf.org; Thu, 06 Sep 2007 14:26:57 +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 l86EQGdq004903; Thu, 6 Sep 2007 16:26:16 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 6 Sep 2007 16:26:45 +0200 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: Closing the GELS Mailing List Date: Thu, 6 Sep 2007 16:26:42 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E380012B22ED@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <53CCFDD6E346CB43994852666C210E9102067D40@esealmw116.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing the GELS Mailing List thread-index: AcfwaKdFjH0nMrF2Tw6ZFzl7WVA5awAJ0mGgAAB7qvA= References: <53CCFDD6E346CB43994852666C210E9101FB483B@esealmw116.eemea.ericsson.se> <014f01c7eb1f$3272db10$0300a8c0@your029b8cecfe> <46D7DDC6.8000205@pi.se> <020501c7f068$270d0c20$0302a8c0@your029b8cecfe> <53CCFDD6E346CB43994852666C210E9102067D40@esealmw116.eemea.ericsson.se> From: "PAPADIMITRIOU Dimitri" To: "Attila Takacs \(IJ/ETH\)" , "Adrian Farrel" , , "gels" Cc: "Ross Callon" X-OriginalArrivalTime: 06 Sep 2007 14:26:45.0462 (UTC) FILETIME=[F3CDBF60:01C7F091] 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: 41c17b4b16d1eedaa8395c26e9a251c4 attila - yes. but CCAMP is only about "Control" - -d. > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Attila Takacs (IJ/ETH) > Sent: Thursday, September 06, 2007 4:25 PM > To: Adrian Farrel; ccamp@ops.ietf.org; gels > Cc: Ross Callon > Subject: RE: Closing the GELS Mailing List >=20 > Hi all, >=20 > I support closing the gels list.=20 >=20 > Since decoupling the discussions into "techno-specific" and GMPLS > specific part is very difficult, if at all possible, I do not=20 > see how to > benefit from a separate forum for techno-specific aspects. IMHO, it > would be much clearer having a single forum for all related=20 > discussions > anyway. >=20 > Best regards, > Attila >=20 >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org=20 > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > > Sent: Thursday, September 06, 2007 11:27 AM > > To: ccamp@ops.ietf.org; gels > > Cc: Ross Callon > > Subject: Closing the GELS Mailing List > >=20 > > We propose to close the GELS mailing list. > >=20 > > Loa wrote... > >=20 > > > I tend to support this, but it begs two questions: > > > > > > - when will the charter update be ack'ed? > >=20 > > I don't know, and I can't promise that it will be ack'ed. but=20 > > the Routing ADs appear to support the change. > >=20 > > > - in the (unlikely) case where we don't get an ack for =20 > > gels work the=20 > > > gels-list won't be needed anyhow, so; isn't the effect of=20 > > the of your=20 > > > statement below that the gels-list is dead as of now? Especially=20 > > > since the on thing we are discussing at the moment is=20 > the charter =20 > > > update and this is on the ccamp list?? > >=20 > > Absolutely. > >=20 > > I'll give you all a last chance to scream. > >=20 > > Thanks, > > Adrian=20 > >=20 > >=20 > >=20 > >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Thu Sep 06 10:36:55 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITITX-0002Ga-DM for ccamp-archive@ietf.org; Thu, 06 Sep 2007 10:36:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITITV-0000bd-TR for ccamp-archive@ietf.org; Thu, 06 Sep 2007 10:36:55 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITIHs-000IxY-Po for ccamp-data@psg.com; Thu, 06 Sep 2007 14:24:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITIHp-000Iw2-Rr for ccamp@ops.ietf.org; Thu, 06 Sep 2007 14:24:51 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E24CA212D6; Thu, 6 Sep 2007 16:24:47 +0200 (CEST) X-AuditID: c1b4fb3e-b2038bb0000007e1-47-46e00dafaf0f Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B8B1B212AF; Thu, 6 Sep 2007 16:24:47 +0200 (CEST) Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Sep 2007 16:24:47 +0200 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: Closing the GELS Mailing List Date: Thu, 6 Sep 2007 16:24:45 +0200 Message-ID: <53CCFDD6E346CB43994852666C210E9102067D40@esealmw116.eemea.ericsson.se> In-Reply-To: <020501c7f068$270d0c20$0302a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing the GELS Mailing List Thread-Index: AcfwaKdFjH0nMrF2Tw6ZFzl7WVA5awAJ0mGg References: <53CCFDD6E346CB43994852666C210E9101FB483B@esealmw116.eemea.ericsson.se> <014f01c7eb1f$3272db10$0300a8c0@your029b8cecfe> <46D7DDC6.8000205@pi.se> <020501c7f068$270d0c20$0302a8c0@your029b8cecfe> From: "Attila Takacs (IJ/ETH)" To: "Adrian Farrel" , , "gels" Cc: "Ross Callon" X-OriginalArrivalTime: 06 Sep 2007 14:24:47.0394 (UTC) FILETIME=[AD6E0020:01C7F091] X-Brightmail-Tracker: AAAAAA== Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Hi all, I support closing the gels list.=20 Since decoupling the discussions into "techno-specific" and GMPLS specific part is very difficult, if at all possible, I do not see how to benefit from a separate forum for techno-specific aspects. IMHO, it would be much clearer having a single forum for all related discussions anyway. Best regards, Attila > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Thursday, September 06, 2007 11:27 AM > To: ccamp@ops.ietf.org; gels > Cc: Ross Callon > Subject: Closing the GELS Mailing List >=20 > We propose to close the GELS mailing list. >=20 > Loa wrote... >=20 > > I tend to support this, but it begs two questions: > > > > - when will the charter update be ack'ed? >=20 > I don't know, and I can't promise that it will be ack'ed. but=20 > the Routing ADs appear to support the change. >=20 > > - in the (unlikely) case where we don't get an ack for =20 > gels work the=20 > > gels-list won't be needed anyhow, so; isn't the effect of=20 > the of your=20 > > statement below that the gels-list is dead as of now? Especially=20 > > since the on thing we are discussing at the moment is the charter =20 > > update and this is on the ccamp list?? >=20 > Absolutely. >=20 > I'll give you all a last chance to scream. >=20 > Thanks, > Adrian=20 >=20 >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Thu Sep 06 10:53:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITIjx-0000lc-Fl for ccamp-archive@ietf.org; Thu, 06 Sep 2007 10:53:53 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITIjw-00014R-8G for ccamp-archive@ietf.org; Thu, 06 Sep 2007 10:53:53 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITIYD-000Koj-KR for ccamp-data@psg.com; Thu, 06 Sep 2007 14:41:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITIYA-000KoK-R0 for ccamp@ops.ietf.org; Thu, 06 Sep 2007 14:41:44 +0000 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l86EfMR10214; Thu, 6 Sep 2007 14:41:22 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: Closing the GELS Mailing List Date: Thu, 6 Sep 2007 10:41:12 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA411396BAF@zrtphxm2.corp.nortel.com> In-Reply-To: <8144761F31F48D43AD53D09F5350E380012B228B@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing the GELS Mailing List thread-index: AcfwaJE8wbS3itLlS+ScmNci3tMldgAD569QAAZHkjA= References: <53CCFDD6E346CB43994852666C210E9101FB483B@esealmw116.eemea.ericsson.se> <014f01c7eb1f$3272db10$0300a8c0@your029b8cecfe> <46D7DDC6.8000205@pi.se> <020501c7f068$270d0c20$0302a8c0@your029b8cecfe> <8144761F31F48D43AD53D09F5350E380012B228B@FRVELSMBS22.ad2.ad.alcatel.com> From: "Don Fedyk" To: "PAPADIMITRIOU Dimitri" , "Adrian Farrel" , , "gels" Cc: "Ross Callon" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Hi Adrian Dmitri does have a point that if there is a topic that heads into the "weeds" we could direct it to the GELS list explicitly. =20 Is there a cost of keeping it open? Regards, Don =20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of PAPADIMITRIOU Dimitri Sent: Thursday, September 06, 2007 10:00 AM To: Adrian Farrel; ccamp@ops.ietf.org; gels Cc: Ross Callon Subject: RE: Closing the GELS Mailing List adrian, you could leave the gels list for the list for the techno-specific discussions and the ccamp list for the non-techno specific discussions in any case, i believe the value of gels was so far to allow open discussion on a topic that was on charter=20 -> question: does proposed incorporation in charter (with milestones to be better shaped inline with progress of IEEE) elevate any other need ? complete decoupling of discussion has been shown to be difficult to be realized in the past thanks, -dimitri. =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Thursday, September 06, 2007 11:27 AM > To: ccamp@ops.ietf.org; gels > Cc: Ross Callon > Subject: Closing the GELS Mailing List >=20 > We propose to close the GELS mailing list. >=20 > Loa wrote... >=20 > > I tend to support this, but it begs two questions: > > > > - when will the charter update be ack'ed? >=20 > I don't know, and I can't promise that it will be ack'ed. but=20 > the Routing ADs appear to support the change. >=20 > > - in the (unlikely) case where we don't get an ack for > > gels work the gels-list won't be needed anyhow, so; > > isn't the effect of the of your statement below that > > the gels-list is dead as of now? Especially since the > > on thing we are discussing at the moment is the charter > > update and this is on the ccamp list?? >=20 > Absolutely. >=20 > I'll give you all a last chance to scream. >=20 > Thanks, > Adrian=20 From owner-ccamp@ops.ietf.org Thu Sep 06 11:17:35 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITJ6t-0007ny-0h for ccamp-archive@ietf.org; Thu, 06 Sep 2007 11:17:35 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITJ6s-0005uJ-DR for ccamp-archive@ietf.org; Thu, 06 Sep 2007 11:17:34 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITIre-000MjB-Mv for ccamp-data@psg.com; Thu, 06 Sep 2007 15:01:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITIrb-000MiR-IO for ccamp@ops.ietf.org; Thu, 06 Sep 2007 15:01:49 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B2C0021484; Thu, 6 Sep 2007 17:01:45 +0200 (CEST) X-AuditID: c1b4fb3e-ae831bb0000007e1-9b-46e016593498 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7009C21164; Thu, 6 Sep 2007 17:01:45 +0200 (CEST) Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Sep 2007 17:01:45 +0200 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: Closing the GELS Mailing List Date: Thu, 6 Sep 2007 17:01:43 +0200 Message-ID: <53CCFDD6E346CB43994852666C210E9102067D9E@esealmw116.eemea.ericsson.se> In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA411396BAF@zrtphxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing the GELS Mailing List Thread-Index: AcfwaJE8wbS3itLlS+ScmNci3tMldgAD569QAAZHkjAAANAA4A== References: <53CCFDD6E346CB43994852666C210E9101FB483B@esealmw116.eemea.ericsson.se> <014f01c7eb1f$3272db10$0300a8c0@your029b8cecfe> <46D7DDC6.8000205@pi.se> <020501c7f068$270d0c20$0302a8c0@your029b8cecfe> <8144761F31F48D43AD53D09F5350E380012B228B@FRVELSMBS22.ad2.ad.alcatel.com> <34B3EAA5B3066A42914D28C5ECF5FEA411396BAF@zrtphxm2.corp.nortel.com> From: "Attila Takacs (IJ/ETH)" To: "Don Fedyk" , "PAPADIMITRIOU Dimitri" , "Adrian Farrel" , , "gels" Cc: "Ross Callon" X-OriginalArrivalTime: 06 Sep 2007 15:01:45.0073 (UTC) FILETIME=[D744F610:01C7F096] X-Brightmail-Tracker: AAAAAA== Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Hi Don, This sounds good, however I doubt that it can be smoothly enforced. How to determine when a discussion is to be moved to the gels list, and, maybe, when is it eligible to be moved back to ccamp? It will be difficult to follow up mixed threads. On the other hand, I suspect that most of the ccamp list members are also subscribed to the gels list so I do not really see the benefit of having two lists; expect setting different filtering rules in your mailer (well, this might be an argument enough in itself :-)) Best regards, Attila > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Don Fedyk > Sent: Thursday, September 06, 2007 4:41 PM > To: PAPADIMITRIOU Dimitri; Adrian Farrel; ccamp@ops.ietf.org; gels > Cc: Ross Callon > Subject: RE: Closing the GELS Mailing List >=20 > Hi Adrian >=20 > Dmitri does have a point that if there is a topic that heads=20 > into the "weeds" we could direct it to the GELS list explicitly. =20 >=20 > Is there a cost of keeping it open? >=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: Thursday, September 06, 2007 10:00 AM > To: Adrian Farrel; ccamp@ops.ietf.org; gels > Cc: Ross Callon > Subject: RE: Closing the GELS Mailing List >=20 > adrian, >=20 > you could leave the gels list for the list for the=20 > techno-specific discussions and the ccamp list for the=20 > non-techno specific discussions >=20 > in any case, i believe the value of gels was so far to allow=20 > open discussion on a topic that was on charter=20 >=20 > -> question: does proposed incorporation in charter (with=20 > milestones to > be better shaped inline with progress of IEEE) elevate any=20 > other need ? > complete decoupling of discussion has been shown to be=20 > difficult to be realized in the past >=20 > thanks, > -dimitri. >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > > Sent: Thursday, September 06, 2007 11:27 AM > > To: ccamp@ops.ietf.org; gels > > Cc: Ross Callon > > Subject: Closing the GELS Mailing List > >=20 > > We propose to close the GELS mailing list. > >=20 > > Loa wrote... > >=20 > > > I tend to support this, but it begs two questions: > > > > > > - when will the charter update be ack'ed? > >=20 > > I don't know, and I can't promise that it will be ack'ed. but the=20 > > Routing ADs appear to support the change. > >=20 > > > - in the (unlikely) case where we don't get an ack for gels work=20 > > > the gels-list won't be needed anyhow, so; isn't the=20 > effect of the=20 > > > of your statement below that the gels-list is dead as of now?=20 > > > Especially since the on thing we are discussing at the moment is=20 > > > the charter update and this is on the ccamp list?? > >=20 > > Absolutely. > >=20 > > I'll give you all a last chance to scream. > >=20 > > Thanks, > > Adrian >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Thu Sep 06 12:05:15 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITJr1-0004T3-9B for ccamp-archive@ietf.org; Thu, 06 Sep 2007 12:05:15 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITJr0-0007VF-Mp for ccamp-archive@ietf.org; Thu, 06 Sep 2007 12:05:15 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITJfZ-0001Kh-2E for ccamp-data@psg.com; Thu, 06 Sep 2007 15:53:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITJfW-0001KK-Ff for ccamp@ops.ietf.org; Thu, 06 Sep 2007 15:53:23 +0000 X-IronPort-AV: E=Sophos;i="4.20,216,1186372800"; d="scan'208";a="70279232" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 06 Sep 2007 11:53:16 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l86FrHON000959; Thu, 6 Sep 2007 11:53:17 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l86FqnZc011062; Thu, 6 Sep 2007 15:53:16 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Sep 2007 11:53:09 -0400 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: Closing the GELS Mailing List Date: Thu, 6 Sep 2007 11:53:14 -0400 Message-ID: In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA411396BAF@zrtphxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing the GELS Mailing List Thread-Index: AcfwaJE8wbS3itLlS+ScmNci3tMldgAD569QAAZHkjAAAOoLAA== References: <53CCFDD6E346CB43994852666C210E9101FB483B@esealmw116.eemea.ericsson.se> <014f01c7eb1f$3272db10$0300a8c0@your029b8cecfe> <46D7DDC6.8000205@pi.se> <020501c7f068$270d0c20$0302a8c0@your029b8cecfe> <8144761F31F48D43AD53D09F5350E380012B228B@FRVELSMBS22.ad2.ad.alcatel.com> <34B3EAA5B3066A42914D28C5ECF5FEA411396BAF@zrtphxm2.corp.nortel.com> From: "Zafar Ali \(zali\)" To: "Don Fedyk" , "PAPADIMITRIOU Dimitri" , "Adrian Farrel" , , "gels" Cc: "Ross Callon" X-OriginalArrivalTime: 06 Sep 2007 15:53:09.0073 (UTC) FILETIME=[057A0410:01C7F09E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2723; t=1189093997; x=1189957997; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zali@cisco.com; z=From:=20=22Zafar=20Ali=20\(zali\)=22=20 |Subject:=20RE=3A=20Closing=20the=20GELS=20Mailing=20List |Sender:=20 |To:=20=22Don=20Fedyk=22=20,=0A=20=20=20=20=20=20=20= 20=22PAPADIMITRIOU=20Dimitri=22=20,=0A=20=20=20=20=20=20=20=20=22Adrian=20Farrel=22=20 ,=20,=0A=20=20=20=20=20=20=20=20=22gels=22=20; bh=LvLBrTv8gJ1vZiC45tC79sLy4VLmBeTSHTW/uGSGvj0=; b=plRMoj3k2q8e8IAPYjS/3Ws5hzCTaXofwY5q/Mo+xhrkE+ub0Sgo0xo+1O+KLvpcOi+Rvozv AAbhrmJkr73bqsx+mWqTvWWy5tWLMMM4KvGzApd/ZbE8sYOBtFQhuIvF; Authentication-Results: rtp-dkim-2; header.From=zali@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Don Fedyk > Sent: Thursday, September 06, 2007 10:41 AM > To: PAPADIMITRIOU Dimitri; Adrian Farrel; ccamp@ops.ietf.org; gels > Cc: Ross Callon > Subject: RE: Closing the GELS Mailing List >=20 > Hi Adrian >=20 > Dmitri does have a point that if there is a topic that heads=20 > into the "weeds" we could direct it to the GELS list explicitly. =20 >=20 > Is there a cost of keeping it open? Is there a cost for discussing them at CCAMP? I prefer a central place for all discussions. =20 Thanks Regards... Zafar=20 >=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: Thursday, September 06, 2007 10:00 AM > To: Adrian Farrel; ccamp@ops.ietf.org; gels > Cc: Ross Callon > Subject: RE: Closing the GELS Mailing List >=20 > adrian, >=20 > you could leave the gels list for the list for the=20 > techno-specific discussions and the ccamp list for the=20 > non-techno specific discussions >=20 > in any case, i believe the value of gels was so far to allow=20 > open discussion on a topic that was on charter=20 >=20 > -> question: does proposed incorporation in charter (with=20 > milestones to > be better shaped inline with progress of IEEE) elevate any=20 > other need ? > complete decoupling of discussion has been shown to be=20 > difficult to be realized in the past >=20 > thanks, > -dimitri. >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > > Sent: Thursday, September 06, 2007 11:27 AM > > To: ccamp@ops.ietf.org; gels > > Cc: Ross Callon > > Subject: Closing the GELS Mailing List > >=20 > > We propose to close the GELS mailing list. > >=20 > > Loa wrote... > >=20 > > > I tend to support this, but it begs two questions: > > > > > > - when will the charter update be ack'ed? > >=20 > > I don't know, and I can't promise that it will be ack'ed. but the=20 > > Routing ADs appear to support the change. > >=20 > > > - in the (unlikely) case where we don't get an ack for gels work=20 > > > the gels-list won't be needed anyhow, so; isn't the=20 > effect of the=20 > > > of your statement below that the gels-list is dead as of now?=20 > > > Especially since the on thing we are discussing at the moment is=20 > > > the charter update and this is on the ccamp list?? > >=20 > > Absolutely. > >=20 > > I'll give you all a last chance to scream. > >=20 > > Thanks, > > Adrian >=20 From owner-ccamp@ops.ietf.org Thu Sep 06 12:09:19 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITJuw-0006j7-So for ccamp-archive@ietf.org; Thu, 06 Sep 2007 12:09:19 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITJuw-0007c1-9W for ccamp-archive@ietf.org; Thu, 06 Sep 2007 12:09:18 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITJgX-0001PB-3q for ccamp-data@psg.com; Thu, 06 Sep 2007 15:54:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITJgU-0001On-D6 for ccamp@ops.ietf.org; Thu, 06 Sep 2007 15:54:23 +0000 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 06 Sep 2007 11:54:22 -0400 X-IronPort-AV: i="4.20,216,1186372800"; d="scan'208"; a="131155226:sNHT65269400" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l86FsLrV001814; Thu, 6 Sep 2007 11:54:21 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l86FsHBo002772; Thu, 6 Sep 2007 15:54:21 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Sep 2007 11:54:18 -0400 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: Closing the GELS Mailing List Date: Thu, 6 Sep 2007 11:54:24 -0400 Message-ID: In-Reply-To: <8144761F31F48D43AD53D09F5350E380012B22ED@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing the GELS Mailing List Thread-Index: AcfwaKdFjH0nMrF2Tw6ZFzl7WVA5awAJ0mGgAAB7qvAAAvuP4A== References: <53CCFDD6E346CB43994852666C210E9101FB483B@esealmw116.eemea.ericsson.se> <014f01c7eb1f$3272db10$0300a8c0@your029b8cecfe> <46D7DDC6.8000205@pi.se> <020501c7f068$270d0c20$0302a8c0@your029b8cecfe> <53CCFDD6E346CB43994852666C210E9102067D40@esealmw116.eemea.ericsson.se> <8144761F31F48D43AD53D09F5350E380012B22ED@FRVELSMBS22.ad2.ad.alcatel.com> From: "Zafar Ali \(zali\)" To: "PAPADIMITRIOU Dimitri" , "Attila Takacs \(IJ/ETH\)" , "Adrian Farrel" , , "gels" Cc: "Ross Callon" X-OriginalArrivalTime: 06 Sep 2007 15:54:18.0090 (UTC) FILETIME=[2E9D2CA0:01C7F09E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2577; t=1189094061; x=1189958061; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zali@cisco.com; z=From:=20=22Zafar=20Ali=20\(zali\)=22=20 |Subject:=20RE=3A=20Closing=20the=20GELS=20Mailing=20List |Sender:=20 |To:=20=22PAPADIMITRIOU=20Dimitri=22=20,=0A=20=20=20=20=20=20=20=20=22Attila=20Takacs=20\(IJ/ETH\)=22=20,=0A=20=20=20=20=20=20=20=20=22Adrian=20Farrel=2 2=20,=20,=0A=20=20=20=20=20=20=20 =20=22gels=22=20; bh=aQvA3qMA5u0WsaYccM8NI0rmuEJCYrb4Zn18vu6rcyc=; b=Jp9LRtdsDEm+E6Cgu/5GXrN0mom6H06YsjkOHzfI4KRdY8Pc1PVHp3+Mp7i+5CuLXSybu3iv IITzmnkd2H2sasGaYqZVecKPsiDJUZVgBdHwfe/vaRfL1SYnCPmuDAQ+; Authentication-Results: rtp-dkim-1; header.From=zali@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of PAPADIMITRIOU Dimitri > Sent: Thursday, September 06, 2007 10:27 AM > To: Attila Takacs (IJ/ETH); Adrian Farrel; ccamp@ops.ietf.org; gels > Cc: Ross Callon > Subject: RE: Closing the GELS Mailing List >=20 > attila - yes. but CCAMP is only about "Control" - >=20 And for interface with Standards Body owning forwarding. Not to mention we are all "technical". What else is left?=20 Thanks Regards... Zafar=20 > -d. >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Attila=20 > Takacs (IJ/ETH) > > Sent: Thursday, September 06, 2007 4:25 PM > > To: Adrian Farrel; ccamp@ops.ietf.org; gels > > Cc: Ross Callon > > Subject: RE: Closing the GELS Mailing List > >=20 > > Hi all, > >=20 > > I support closing the gels list.=20 > >=20 > > Since decoupling the discussions into "techno-specific" and GMPLS=20 > > specific part is very difficult, if at all possible, I do=20 > not see how=20 > > to benefit from a separate forum for techno-specific=20 > aspects. IMHO, it=20 > > would be much clearer having a single forum for all related=20 > > discussions anyway. > >=20 > > Best regards, > > Attila > >=20 > >=20 > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > > > Sent: Thursday, September 06, 2007 11:27 AM > > > To: ccamp@ops.ietf.org; gels > > > Cc: Ross Callon > > > Subject: Closing the GELS Mailing List > > >=20 > > > We propose to close the GELS mailing list. > > >=20 > > > Loa wrote... > > >=20 > > > > I tend to support this, but it begs two questions: > > > > > > > > - when will the charter update be ack'ed? > > >=20 > > > I don't know, and I can't promise that it will be ack'ed. but the=20 > > > Routing ADs appear to support the change. > > >=20 > > > > - in the (unlikely) case where we don't get an ack for > > > gels work the > > > > gels-list won't be needed anyhow, so; isn't the effect of > > > the of your > > > > statement below that the gels-list is dead as of now?=20 > Especially=20 > > > > since the on thing we are discussing at the moment is > > the charter > > > > update and this is on the ccamp list?? > > >=20 > > > Absolutely. > > >=20 > > > I'll give you all a last chance to scream. > > >=20 > > > Thanks, > > > Adrian > > >=20 > > >=20 > > >=20 > > >=20 > >=20 > >=20 >=20 From owner-ccamp@ops.ietf.org Thu Sep 06 12:09:19 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITJux-0006jJ-UL for ccamp-archive@ietf.org; Thu, 06 Sep 2007 12:09:19 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITJux-0007c6-Eb for ccamp-archive@ietf.org; Thu, 06 Sep 2007 12:09:19 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITJju-0001jk-12 for ccamp-data@psg.com; Thu, 06 Sep 2007 15:57:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.1 Received: from [128.9.168.207] (helo=bosco.isi.edu) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITJjr-0001jL-Ct for ccamp@ops.ietf.org; Thu, 06 Sep 2007 15:57:52 +0000 Received: by bosco.isi.edu (Postfix, from userid 70) id C944BE0FBA; Thu, 6 Sep 2007 08:55:27 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 4990 on Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org Message-Id: <20070906155527.C944BE0FBA@bosco.isi.edu> Date: Thu, 6 Sep 2007 08:55:27 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 A new Request for Comments is now available in online RFC libraries. RFC 4990 Title: Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks Author: K. Shiomoto, R. Papneja, R. Rabbat Status: Informational Date: September 2007 Mailbox: shiomoto.kohei@lab.ntt.co.jp, rabbat@alum.mit.edu, rpapneja@isocore.com Pages: 23 Characters: 50908 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-gmpls-addressing-08.txt URL: http://www.rfc-editor.org/rfc/rfc4990.txt This document clarifies the use of addresses in Generalized Multiprotocol Label Switching (GMPLS) networks. The aim is to facilitate interworking of GMPLS-capable Label Switching Routers (LSRs). The document is based on experience gained in implementation, interoperability testing, and deployment. The document describes how to interpret address and identifier fields within GMPLS protocols, and how to choose which addresses to set in those fields for specific control plane usage models. It also discusses how to handle IPv6 sources and destinations in the MPLS and GMPLS Traffic Engineering (TE) Management Information Base (MIB) modules. This document does not define new procedures or processes. Whenever this document makes requirements statements or recommendations, these are taken from normative text in the referenced RFCs. This memo provides information for the Internet community. This document is a product of the Common Control and Measurement Plane Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From Ronald@hdj.de Thu Sep 06 14:06:55 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITLkl-0001qL-Ut for ccamp-archive@ietf.org; Thu, 06 Sep 2007 14:06:55 -0400 Received: from [72.252.110.150] (helo=[72.252.110.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITLkl-00023R-Gx for ccamp-archive@ietf.org; Thu, 06 Sep 2007 14:06:55 -0400 Received: from kris001 ([114.152.71.84] helo=kris001) by [72.252.110.150] ( sendmail 8.13.3/8.13.1) with esmtpa id 1IWRRU-000SOY-Nu for ccamp-archive@ietf.org; Thu, 6 Sep 2007 13:16:32 -0500 Message-ID: <000c01c7f0b2$0535df10$966efc48@kris001> From: "Ronald carcellar" To: Subject: srezzif Date: Thu, 6 Sep 2007 13:16:18 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C7F088.1C5FD710" 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.9 (++++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0008_01C7F088.1C5FD710 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.scrathes.com/ Wassup carcellar I've gained an inch and a half so far, somvisa Hildesheim ------=_NextPart_000_0008_01C7F088.1C5FD710 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.scrathes.com/
Wassup carcellar
I've gained an inch and a half so = far,
somvisa Hildesheim
------=_NextPart_000_0008_01C7F088.1C5FD710-- From owner-ccamp@ops.ietf.org Thu Sep 06 15:09:26 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITMjG-00081g-4r for ccamp-archive@ietf.org; Thu, 06 Sep 2007 15:09:26 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITMjF-0003Lf-HR for ccamp-archive@ietf.org; Thu, 06 Sep 2007 15:09:26 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITMXp-000IWR-2S for ccamp-data@psg.com; Thu, 06 Sep 2007 18:57:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [64.208.49.5] (helo=smail6.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITMXm-000IW1-3h for ccamp@ops.ietf.org; Thu, 06 Sep 2007 18:57:35 +0000 Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l86IuuZ8028275; Thu, 6 Sep 2007 20:56:56 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 6 Sep 2007 20:57:25 +0200 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: Closing the GELS Mailing List Date: Thu, 6 Sep 2007 20:57:22 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E380012B24AF@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing the GELS Mailing List thread-index: AcfwaKdFjH0nMrF2Tw6ZFzl7WVA5awAJ0mGgAAB7qvAAAvuP4AAFZYUw References: <53CCFDD6E346CB43994852666C210E9101FB483B@esealmw116.eemea.ericsson.se> <014f01c7eb1f$3272db10$0300a8c0@your029b8cecfe> <46D7DDC6.8000205@pi.se> <020501c7f068$270d0c20$0302a8c0@your029b8cecfe> <53CCFDD6E346CB43994852666C210E9102067D40@esealmw116.eemea.ericsson.se> <8144761F31F48D43AD53D09F5350E380012B22ED@FRVELSMBS22.ad2.ad.alcatel.com> From: "PAPADIMITRIOU Dimitri" To: "Zafar Ali \(zali\)" , "Attila Takacs \(IJ/ETH\)" , "Adrian Farrel" , , "gels" Cc: "Ross Callon" X-OriginalArrivalTime: 06 Sep 2007 18:57:25.0931 (UTC) FILETIME=[C3E0A7B0:01C7F0B7] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 zafar the main problem remains - to take a base example in its work plan Adrian mentions 2. "GMPLS control of P2P TE for PBB-TE (802.1Qay)" [...] - Label allocation and swapping rules=20 [...] is that not a forwarding component discussion ? beside the fact that there is an assumption on what label means and how it is represented in data plane thanks, -d. =20 > -----Original Message----- > From: Zafar Ali (zali) [mailto:zali@cisco.com]=20 > Sent: Thursday, September 06, 2007 5:54 PM > To: PAPADIMITRIOU Dimitri; Attila Takacs (IJ/ETH); Adrian=20 > Farrel; ccamp@ops.ietf.org; gels > Cc: Ross Callon > Subject: RE: Closing the GELS Mailing List >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org=20 > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of PAPADIMITRIOU Dimitri > > Sent: Thursday, September 06, 2007 10:27 AM > > To: Attila Takacs (IJ/ETH); Adrian Farrel; ccamp@ops.ietf.org; gels > > Cc: Ross Callon > > Subject: RE: Closing the GELS Mailing List > >=20 > > attila - yes. but CCAMP is only about "Control" - >=20 > And for interface with Standards Body owning forwarding. Not=20 > to mention > we are all "technical". What else is left?=20 >=20 > Thanks >=20 > Regards... Zafar=20 >=20 > > -d. > >=20 > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Attila=20 > > Takacs (IJ/ETH) > > > Sent: Thursday, September 06, 2007 4:25 PM > > > To: Adrian Farrel; ccamp@ops.ietf.org; gels > > > Cc: Ross Callon > > > Subject: RE: Closing the GELS Mailing List > > >=20 > > > Hi all, > > >=20 > > > I support closing the gels list.=20 > > >=20 > > > Since decoupling the discussions into "techno-specific" and GMPLS=20 > > > specific part is very difficult, if at all possible, I do=20 > > not see how=20 > > > to benefit from a separate forum for techno-specific=20 > > aspects. IMHO, it=20 > > > would be much clearer having a single forum for all related=20 > > > discussions anyway. > > >=20 > > > Best regards, > > > Attila > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: owner-ccamp@ops.ietf.org > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > > > > Sent: Thursday, September 06, 2007 11:27 AM > > > > To: ccamp@ops.ietf.org; gels > > > > Cc: Ross Callon > > > > Subject: Closing the GELS Mailing List > > > >=20 > > > > We propose to close the GELS mailing list. > > > >=20 > > > > Loa wrote... > > > >=20 > > > > > I tend to support this, but it begs two questions: > > > > > > > > > > - when will the charter update be ack'ed? > > > >=20 > > > > I don't know, and I can't promise that it will be=20 > ack'ed. but the=20 > > > > Routing ADs appear to support the change. > > > >=20 > > > > > - in the (unlikely) case where we don't get an ack for > > > > gels work the > > > > > gels-list won't be needed anyhow, so; isn't the effect of > > > > the of your > > > > > statement below that the gels-list is dead as of now?=20 > > Especially=20 > > > > > since the on thing we are discussing at the moment is > > > the charter > > > > > update and this is on the ccamp list?? > > > >=20 > > > > Absolutely. > > > >=20 > > > > I'll give you all a last chance to scream. > > > >=20 > > > > Thanks, > > > > Adrian > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > >=20 > > >=20 > >=20 >=20 From owner-ccamp@ops.ietf.org Thu Sep 06 16:23:27 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITNst-0002k7-FB for ccamp-archive@ietf.org; Thu, 06 Sep 2007 16:23:27 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITNss-000624-Td for ccamp-archive@ietf.org; Thu, 06 Sep 2007 16:23:27 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITNkq-0000Q7-7l for ccamp-data@psg.com; Thu, 06 Sep 2007 20:15:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-201.9 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO,USER_IN_WHITELIST autolearn=no version=3.2.1 Received: from [156.154.24.138] (helo=ns3.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITNkl-0000Ol-R8 for ccamp@ops.ietf.org; Thu, 06 Sep 2007 20:15:05 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 994F3175A7; Thu, 6 Sep 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ITNkj-0007qC-W0; Thu, 06 Sep 2007 16:15:01 -0400 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-ospf-interas-te-extension-01.txt Message-Id: Date: Thu, 06 Sep 2007 16:15:01 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 --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 : OSPF Traffic Engineering (OSPF-TE) Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Author(s) : M. Chen, R. Zhang Filename : draft-ietf-ccamp-ospf-interas-te-extension-01.txt Pages : 13 Date : 2007-9-6 This document describes extensions to the OSPF v2 and v3 Traffic Engineering (OSPF-TE) mechanisms to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering(TE) for multiple Autonomous Systems (ASes). It defines OSPF-TE extensions for the flooding of TE information about inter-AS links which can be used to perform inter-AS TE path computation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas-te-extension-01.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-ospf-interas-te-extension-01.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-ospf-interas-te-extension-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-9-6150019.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-ospf-interas-te-extension-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-ospf-interas-te-extension-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-9-6150019.I-D@ietf.org> --OtherAccess-- --NextPart-- From schneide@newvaluepcbuddy.com Thu Sep 06 22:24:56 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITTWi-0005a8-8h; Thu, 06 Sep 2007 22:24:56 -0400 Received: from [125.127.121.75] (helo=[125.127.121.75]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITTWh-0007WL-78; Thu, 06 Sep 2007 22:24:55 -0400 Received: from [125.127.121.75] by smtp.secureserver.net; Fri, 7 Sep 2007 10:24:54 +0800 Message-ID: <01c7f0f6$46ba1610$4b797f7d@schneide> From: "Iris Bradshaw" To: Subject: Viagra 50mg x 10 pills $6.00 per pill buy now Date: Fri, 7 Sep 2007 10:24:54 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-2" Content-Transfer-Encoding: 7bit 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.2869 X-Spam-Score: 3.8 (+++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Price for Viagra (Sildenafil) 50mg x 10 pills US $ 6.00 Per Pill http://listenyoung.com From Atsushi-hiler@halla.net Fri Sep 07 03:37:30 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITYPC-0006tM-Oq for ccamp-archive@megatron.ietf.org; Fri, 07 Sep 2007 03:37:30 -0400 Received: from host145-100-static.59-217-b.business.telecomitalia.it ([217.59.100.145]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITYPB-0005Ug-Cc for ccamp-archive@megatron.ietf.org; Fri, 07 Sep 2007 03:37:30 -0400 Received: by 10.221.230.89 with SMTP id ihBLKSqbJUylM; Fri, 7 Sep 2007 09:49:28 +0200 (GMT) Received: by 192.168.195.48 with SMTP id llwRLRxxzYtufI.3085394149892; Fri, 7 Sep 2007 09:49:26 +0200 (GMT) Message-ID: <000e01c7f123$9b243820$91643bd9@ROBERTOCOTZA> From: "Atsushi hiler" To: Subject: ivutneho Date: Fri, 7 Sep 2007 09:49:23 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7F134.5EAD0820" 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.0 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0003_01C7F134.5EAD0820 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://tasteine.com/ Hi bro ccamp-archive Ejaculate further - Fire off like a cannon! Math seifikar ------=_NextPart_000_0003_01C7F134.5EAD0820 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://tasteine.com/
Hi bro ccamp-archive
Ejaculate further - Fire off like a = cannon!
Math seifikar
------=_NextPart_000_0003_01C7F134.5EAD0820-- From Neha984@halla.net Fri Sep 07 03:38:01 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITYPh-00006j-D9 for ccamp-archive@ietf.org; Fri, 07 Sep 2007 03:38:01 -0400 Received: from host145-100-static.59-217-b.business.telecomitalia.it ([217.59.100.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITYPb-0001ZX-Jm for ccamp-archive@ietf.org; Fri, 07 Sep 2007 03:38:01 -0400 Received: from ROBERTO_COTZA ([174.194.32.29]:1777 "EHLO ROBERTO_COTZA" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by host145-100-static.59-217-b.business.telecomitalia.it with ESMTP id S22JZYLIKKXZUIUM (ORCPT ); Fri, 7 Sep 2007 09:50:26 +0200 Message-ID: Date: Fri, 7 Sep 2007 09:49:50 +0200 From: "Neha Jefford" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: {iveneml Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Good day ccamp-archive I've gained an inch and a half so far, Jasroop Saller http://www.sshopbop.com/ From owner-ccamp@ops.ietf.org Fri Sep 07 05:10:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITZr7-0001VY-QL for ccamp-archive@ietf.org; Fri, 07 Sep 2007 05:10:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITZr6-0003NT-JL for ccamp-archive@ietf.org; Fri, 07 Sep 2007 05:10:25 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITZgm-000H3J-Kl for ccamp-data@psg.com; Fri, 07 Sep 2007 08:59:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [212.23.3.141] (helo=heisenberg.zen.co.uk) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITZgj-000H30-Na for ccamp@ops.ietf.org; Fri, 07 Sep 2007 08:59:43 +0000 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1ITZgi-00012p-Eg for ccamp@ops.ietf.org; Fri, 07 Sep 2007 08:59:40 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Sep 2007 09:59:40 +0100 Message-ID: <039601c7f12d$69406a40$0302a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "PAPADIMITRIOU Dimitri" , "Zafar Ali \(zali\)" , "Attila Takacs \(IJ/ETH\)" , , "gels" Cc: "Ross Callon" References: <53CCFDD6E346CB43994852666C210E9101FB483B@esealmw116.eemea.ericsson.se> <014f01c7eb1f$3272db10$0300a8c0@your029b8cecfe> <46D7DDC6.8000205@pi.se> <020501c7f068$270d0c20$0302a8c0@your029b8cecfe> <53CCFDD6E346CB43994852666C210E9102067D40@esealmw116.eemea.ericsson.se> <8144761F31F48D43AD53D09F5350E380012B22ED@FRVELSMBS22.ad2.ad.alcatel.com> <8144761F31F48D43AD53D09F5350E380012B24AF@FRVELSMBS22.ad2.ad.alcatel.com> Subject: Re: Closing the GELS Mailing List Date: Fri, 7 Sep 2007 09:59:28 +0100 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-OriginalArrivalTime: 07 Sep 2007 08:59:40.0118 (UTC) FILETIME=[6C99A760:01C7F12D] X-Originating-Heisenberg-IP: [88.96.235.138] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 I think this thread is a representation in miniature of the issues involved... - All the emails in this thread have been copied to both mailing lists - All the participants in the thread are subscribed to both mailing lists No, it doesn't cost to have both lists active. No, it doesn't cost to have all of the threads on CCAMP. Please note that we should not discuss the data plane. If you don't understand (or don't like, or don't want to use) the data plane you should have your discussions in private or at the IEEE. Dimitri said... >> - Label allocation and swapping rules > is that not a forwarding component discussion ? It is certainly informed by the forwarding component (i.e. the definition of the data plane), but the rules we need to define are the rules for the control plane. I.e. (and for example, only) if the forwarding plane defines that the label allocated on the upstream interface must be numerically one greater than the label allocated on the downstream interface, this rule must be referenced in the control plane specification. This is important since it is a constraint placed on the normal per-interface operation of GMPLS. That makes it CCAMP work. > beside the fact that there is an assumption on what > label means and how it is represented in data plane This is also something we would expect to describe within CCAMP although "what is a label" would come to us from the data plane specification. Thanks, Adrian From owner-ccamp@ops.ietf.org Fri Sep 07 05:31:21 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITaBL-0004Dh-PJ for ccamp-archive@ietf.org; Fri, 07 Sep 2007 05:31:20 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITaBL-0007z7-EM for ccamp-archive@ietf.org; Fri, 07 Sep 2007 05:31:19 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITa3V-000JUt-5n for ccamp-data@psg.com; Fri, 07 Sep 2007 09:23:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [61.144.161.7] (helo=szxga04-in.huawei.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITa3P-000JUS-FT for ccamp@ops.ietf.org; Fri, 07 Sep 2007 09:23:08 +0000 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNZ004C1RCQTZ@szxga04-in.huawei.com> for ccamp@ops.ietf.org; Fri, 07 Sep 2007 17:22:02 +0800 (CST) Received: from M55527 ([10.111.12.79]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JNZ00BB4RCMZV@szxga04-in.huawei.com> for ccamp@ops.ietf.org; Fri, 07 Sep 2007 17:22:02 +0800 (CST) Date: Fri, 07 Sep 2007 17:21:53 +0800 From: Mach Chen Subject: Update for the "IGP extention in support of Inter-AS TE" drafts To: ccamp@ops.ietf.org Message-id: <00de01c7f130$87e737f0$4f0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcfwwuDZhXH7tKtURuC2IIrBrm8HUgAP/ARw Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Hi forks, We have updated these two I-Ds since IETF 69th in Chicago, where we received a lot of useful comments and suggestion. You could reach them by the following links: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas-te-extensi on-01.txt http://www.ietf.org/internet-drafts/draft-ietf-chen-isis-interas-te-extensio n-01.txt Compare to rev.00, the main changes in rev.01 are listed below: 1. Wording changes in several places; 2. According to Kireeti's comments, make a clear statement "There is no OSPF adjacency running on the inter-AS link"; 3. Enhance the PCE-based scenario to explain that the AS number property of an inter-AS TE link is needed, and clearly state that the AS number sub-TLV is mandatory; 4. Add the missing part about that the local ASBR SHOULD do a "proxy" advertisement for the backward of an inter-AS TE link; 5. Enhance the Security section. Any feedback and comments are welcome! Best regards, Mach From owner-ccamp@ops.ietf.org Fri Sep 07 05:55:11 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITaYR-0001D2-Ec for ccamp-archive@ietf.org; Fri, 07 Sep 2007 05:55:11 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITaYQ-0008W9-8b for ccamp-archive@ietf.org; Fri, 07 Sep 2007 05:55:11 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITaQ9-000M2I-Hl for ccamp-data@psg.com; Fri, 07 Sep 2007 09:46:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.1 Received: from [61.144.161.55] (helo=szxga03-in.huawei.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITaPw-000M1N-UI for ccamp@ops.ietf.org; Fri, 07 Sep 2007 09:46:36 +0000 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNZ00I8RSGYV0@szxga03-in.huawei.com> for ccamp@ops.ietf.org; Fri, 07 Sep 2007 17:46:10 +0800 (CST) Received: from M55527 ([10.111.12.79]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JNZ0015MSGTZN@szxga03-in.huawei.com> for ccamp@ops.ietf.org; Fri, 07 Sep 2007 17:46:10 +0800 (CST) Date: Fri, 07 Sep 2007 17:46:00 +0800 From: Mach Chen Subject: Update for the "IGP extention in support of Inter-AS TE" drafts(resend for some nits in the previous email:-)) To: ccamp@ops.ietf.org Message-id: <00ea01c7f133$e6248e50$4f0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_haGQROjryIU2to16pF2lnw)" Thread-index: AcfxM+WyX7x8pKOhT1SoKbic5h3v0g== Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ad5310d4a40550521c18cacd3b6e7111 This is a multi-part message in MIME format. --Boundary_(ID_haGQROjryIU2to16pF2lnw) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Hi forks, We have updated these two I-Ds since IETF 69th in Chicago, where we received a lot of useful comments and suggestion. You could reach them by the following links: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas-te-extensi on-01.txt http://www.ietf.org/internet-drafts/draft-chen-ccamp-isis-interas-te-extensi on-01.txt Compare to rev.00, the main changes in rev.01 are listed below: 1. Wording changes in several places; 2. According to Kireeti's comments, make a clear statement "There is no OSPF adjacency running on the inter-AS link"; 3. Enhance the PCE-based scenario to explain that the AS number property of an inter-AS TE link is needed, and clearly state that the AS number sub-TLV is mandatory; 4. Add the missing part about that the local ASBR SHOULD do a "proxy" advertisement for the backward of an inter-AS TE link; 5. Enhance the Security section. Any feedback and comments are welcome! Best regards, Mach --Boundary_(ID_haGQROjryIU2to16pF2lnw) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT

Hi forks,

 

We have updated these two I-Ds since IETF 69th in Chicago, where we received a lot of useful comments and suggestion. You could reach them by the following links:

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas-te-extension-01.txt

 

http://www.ietf.org/internet-drafts/draft-chen-ccamp-isis-interas-te-extension-01.txt

 

Compare to rev.00, the main changes in rev.01 are listed below:

 

1. Wording changes in several places;

2. According to Kireeti's comments, make a clear statement "There is no OSPF adjacency running on the inter-AS link";

3. Enhance the PCE-based scenario to explain that the AS number property of an inter-AS TE link is needed, and clearly state that the AS number sub-TLV is mandatory;

4. Add the missing part about that the local ASBR SHOULD do a "proxy" advertisement for the backward of an inter-AS TE link; 5. Enhance the Security section.

 

Any feedback and comments are welcome!

Best regards,

Mach

 

--Boundary_(ID_haGQROjryIU2to16pF2lnw)-- From Wdeboe@irana.com Fri Sep 07 07:56:53 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITcSD-0004mR-Cs for ccamp-archive@ietf.org; Fri, 07 Sep 2007 07:56:53 -0400 Received: from [88.227.202.179] (helo=[88.227.202.179]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITcSC-0002u3-1H for ccamp-archive@ietf.org; Fri, 07 Sep 2007 07:56:52 -0400 Received: by 10.37.98.179 with SMTP id nTzoqLymGqkqs; Fri, 7 Sep 2007 14:57:37 +0300 (GMT) Received: by 192.168.69.210 with SMTP id iQaQnGLqFVobbD.0369595486219; Fri, 7 Sep 2007 14:57:35 +0300 (GMT) Message-ID: <000c01c7f146$45b6c880$b3cae358@clientxp> From: "W deboe" To: Subject: 0eppets Date: Fri, 7 Sep 2007 14:57:32 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C7F15F.6B040080" 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.2 (++++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0008_01C7F15F.6B040080 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable http://hcjslm.com/ How it is going W Which are the Best Penis Enlargement pills.... These ones are.. Praz Mallett ------=_NextPart_000_0008_01C7F15F.6B040080 Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable
http://hcjslm.com/
How it is going W
Which are the Best Penis Enlargement pills.... = These=20 ones are..
Praz Mallett
------=_NextPart_000_0008_01C7F15F.6B040080-- From ydpublish@screaminsam.com Fri Sep 07 09:28:12 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITdsa-0004Yy-CW for ccamp-archive@ietf.org; Fri, 07 Sep 2007 09:28:12 -0400 Received: from auv89.neoplus.adsl.tpnet.pl ([83.27.29.89]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ITdsZ-0004xL-Ie for ccamp-archive@ietf.org; Fri, 07 Sep 2007 09:28:12 -0400 Received: from Kasia ([136.194.19.97]:1156 "HELO Kasia" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 591d1b53screaminsam.com with ESMTP id 5742127611B1 (ORCPT ); Fri, 7 Sep 2007 15:29:09 +0200 Message-ID: <001a01c7f163$d5a69930$06df220c@Kasia> From: games do To: ccamp-archive@ietf.org Subject: He is earn Date: Fri, 7 Sep 2007 15:29:09 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01C7F163.D5A69930" 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.0000 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_0017_01C7F163.D5A69930 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable cellular phone, and a mug of fresh, automatic-machine-made pass by children will lose touch of reality. Communicating Part Two - The = Role of Technology in the Lives of Special Needs ------=_NextPart_000_0017_01C7F163.D5A69930 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable

justify a situation like that. Greed will more likely than not

Are you wanting a bigger p e n _i s?

As se -e -n on TV

Over 733,000 Men around the world are already satisfied
Gain 3+ Inches In Leng _th
Increase Your P _en -is Wi _dth (Girth) By up _to 24%
100% Safe To Take, With NO Side Effects
No Pum _ps! No Surgery! No Exercises!
*3 FREE Bottles Of M -e _g a D _i -k

are not able to explore a locale with your five senses. It is
------=_NextPart_000_0017_01C7F163.D5A69930-- From sminus@twilyte.com Fri Sep 07 09:37:08 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITe1E-0005UX-5F for ccamp-archive@ietf.org; Fri, 07 Sep 2007 09:37:08 -0400 Received: from 217.217.178.228.dyn.user.ono.com ([217.217.178.228] helo=twilyte.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ITe1D-0005AK-F1 for ccamp-archive@ietf.org; Fri, 07 Sep 2007 09:37:07 -0400 Received: from emiliokpfi2rzh ([168.241.60.66]:1517 "HELO emiliokpfi2rzh" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by e4b2d9d9twilyte.com with ESMTP id o6SHSWDT808265 (ORCPT ); Fri, 7 Sep 2007 15:36:55 +0200 Message-ID: <001701c7f164$ebdfba00$002fa6ec@emiliokpfi2rzh> From: Milford Z. Hooper To: ccamp-archive@ietf.org Subject: or area Date: Fri, 7 Sep 2007 15:36:55 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C7F164.EBDFBA00" 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.4682 X-Spam-Score: 1.7 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C7F164.EBDFBA00 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable association. The dream to achieve machine intelligence that is substantial market. This would most definitely be a competitive sterility = of the MOO keeps you from feeling this. It is pretty ------=_NextPart_000_0014_01C7F164.EBDFBA00 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable

and applications which enable artists to create a variety of
<= /P>

Are you wanting a bigger p e n _i s?

As se -e -n on TV

Over 749,000 Men around the world are already satisfied
Gain 2+ Inches In Leng _th
Increase Your P _en -is Wi _dth (Girth) By up _to 21%
100% Safe To Take, With NO Side Effects
No Pum _ps! No Surgery! No Exercises!
*3 FREE Bottles Of M -e _g a D _i -k

strong understanding of technology. In fact, artists will be
------=_NextPart_000_0014_01C7F164.EBDFBA00-- From fhtmerge@debenhams.com Fri Sep 07 09:44:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITe8i-0005IY-BB for ccamp-archive@ietf.org; Fri, 07 Sep 2007 09:44:52 -0400 Received: from gax242.internetdsl.tpnet.pl ([83.12.23.242] helo=acfr113.neoplus.adsl.tpnet.pl) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ITe84-0000sa-Vq for ccamp-archive@ietf.org; Fri, 07 Sep 2007 09:44:52 -0400 Received: from edek ([133.175.45.40]:35846 "HELO edek" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 71db0953debenhams.com with ESMTP id u8ZZSUFQ994116 (ORCPT ); Fri, 7 Sep 2007 15:44:31 +0200 Message-ID: <001c01c7f165$fe582950$06eca8b4@edek> From: Ellis To: ccamp-archive@ietf.org Subject: in do band Date: Fri, 7 Sep 2007 15:44:31 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C7F165.FE582950" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.4682 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.2969 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C7F165.FE582950 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable assienment in part given to our computer class was to connect of many approaches to looking at things. Go see the movie Slacker expressio= ns. For instance, if we were to look at a painting on a ------=_NextPart_000_0019_01C7F165.FE582950 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable

The visual style of cyberart often follows the myriad of choices

Are you wanting a bigger p e n _i s?

As se -e -n on TV

Over 721,000 Men around the world are already satisfied
Gain 4+ Inches In Leng _th
Increase Your P _en -is Wi _dth (Girth) By up _to 27%
100% Safe To Take, With NO Side Effects
No Pum _ps! No Surgery! No Exercises!
*3 FREE Bottles Of M -e _g a D _i -k

deployed to indoctrinate children into the ways of the linear.
------=_NextPart_000_0019_01C7F165.FE582950-- From owner-ccamp@ops.ietf.org Fri Sep 07 10:05:38 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITeSo-0000Ig-Kr for ccamp-archive@ietf.org; Fri, 07 Sep 2007 10:05:38 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITeSo-0005us-8G for ccamp-archive@ietf.org; Fri, 07 Sep 2007 10:05:38 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITeIw-000LWF-Ue for ccamp-data@psg.com; Fri, 07 Sep 2007 13:55:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [212.23.3.142] (helo=rutherford.zen.co.uk) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITeIu-000LVr-EY for ccamp@ops.ietf.org; Fri, 07 Sep 2007 13:55:25 +0000 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1ITeIr-0002he-Bz for ccamp@ops.ietf.org; Fri, 07 Sep 2007 13:55:21 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Sep 2007 14:55:20 +0100 Message-ID: <046401c7f156$b7925310$0302a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Lam, Hing-Kam \(Kam\)" Subject: Working Group Last Call on MLN Requirements and Evaluation Date: Fri, 7 Sep 2007 14:55:01 +0100 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-OriginalArrivalTime: 07 Sep 2007 13:55:20.0706 (UTC) FILETIME=[BAD08E20:01C7F156] X-Originating-Rutherford-IP: [88.96.235.138] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Hi, This email starts the working group last call on http://www.olddog.co.uk/pentredwr.htm and http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-eval-03.txt This last call will include scope for review of the documents by ITU-T SG15 Q14 during their interim meeting in Stuttgart. The last call will end at 12 noon GMT on 21st September 2007. Please send your comments by email to the CCAMP list or to the CCAMP chairs (or by formal liaison ;-). Thanks, Adrian From owner-ccamp@ops.ietf.org Fri Sep 07 10:19:48 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITegW-0005k0-Eu for ccamp-archive@ietf.org; Fri, 07 Sep 2007 10:19:48 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITegW-0006G5-3B for ccamp-archive@ietf.org; Fri, 07 Sep 2007 10:19:48 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITeYU-000NKj-48 for ccamp-data@psg.com; Fri, 07 Sep 2007 14:11:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [212.23.3.142] (helo=rutherford.zen.co.uk) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITeYO-000NKL-J1 for ccamp@ops.ietf.org; Fri, 07 Sep 2007 14:11:28 +0000 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1ITeYN-0002aB-Mz for ccamp@ops.ietf.org; Fri, 07 Sep 2007 14:11:23 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Sep 2007 15:11:22 +0100 Message-ID: <047601c7f158$f5121ed0$0302a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Lam, Hing-Kam \(Kam\)" References: <046401c7f156$b7925310$0302a8c0@your029b8cecfe> Subject: Re: Working Group Last Call on MLN Requirements and Evaluation Date: Fri, 7 Sep 2007 15:10:59 +0100 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.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 07 Sep 2007 14:11:23.0478 (UTC) FILETIME=[F8ABE760:01C7F158] X-Originating-Rutherford-IP: [88.96.235.138] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Remarkable! Don't trust your mailer if it comes from Microsoft! That URL showed as http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-reqs-05.txt right up until it arrive in my inbox! But you are also very welcome to book our village hall :-) Adrian ----- Original Message ----- From: "Adrian Farrel" To: Cc: "Lam, Hing-Kam (Kam)" Sent: Friday, September 07, 2007 2:55 PM Subject: Working Group Last Call on MLN Requirements and Evaluation > Hi, > > This email starts the working group last call on > > http://www.olddog.co.uk/pentredwr.htm > and > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-eval-03.txt > > This last call will include scope for review of the documents by ITU-T > SG15 Q14 during their interim meeting in Stuttgart. > > The last call will end at 12 noon GMT on 21st September 2007. > > Please send your comments by email to the CCAMP list or to the CCAMP > chairs (or by formal liaison ;-). > > Thanks, > Adrian > > > From owner-ccamp@ops.ietf.org Fri Sep 07 11:24:39 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITfhH-0007EW-FM for ccamp-archive@ietf.org; Fri, 07 Sep 2007 11:24:39 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITfhG-0003Gx-4o for ccamp-archive@ietf.org; Fri, 07 Sep 2007 11:24:39 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITfYC-0003ui-O7 for ccamp-data@psg.com; Fri, 07 Sep 2007 15:15:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,RDNS_NONE autolearn=no version=3.2.1 Received: from [62.241.163.6] (helo=astro.systems.pipex.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITfY9-0003uM-W5 for ccamp@ops.ietf.org; Fri, 07 Sep 2007 15:15:15 +0000 Received: from pc6 (1Cust140.tnt30.lnd3.gbr.da.uu.net [62.188.122.140]) by astro.systems.pipex.net (Postfix) with SMTP id CA608E00049F; Fri, 7 Sep 2007 16:15:07 +0100 (BST) Message-ID: <029b01c7f158$a43c9bc0$0601a8c0@pc6> Reply-To: "tom.petch" From: "tom.petch" To: "Adrian Farrel" , , "gels" Cc: "Ross Callon" References: <53CCFDD6E346CB43994852666C210E9101FB483B@esealmw116.eemea.ericsson.se> <014f01c7eb1f$3272db10$0300a8c0@your029b8cecfe> <46D7DDC6.8000205@pi.se> <020501c7f068$270d0c20$0302a8c0@your029b8cecfe> <53CCFDD6E346CB43994852666C210E9102067D40@esealmw116.eemea.ericsson.se> <8144761F31F48D43AD53D09F5350E380012B22ED@FRVELSMBS22.ad2.ad.alcatel.com> <8144761F31F48D43AD53D09F5350E380012B24AF@FRVELSMBS22.ad2.ad.alcatel.com> <039601c7f12d$69406a40$0302a8c0@your029b8cecfe> Subject: Re: Closing the GELS Mailing List Date: Fri, 7 Sep 2007 12:25:46 +0200 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.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -102.6 (---------------------------------------------------) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Adrian Just to break the pattern, I am not on the GELS list - never got round to it - and would be very happy to see them merged. A list should reflect a community of interest and I think that there is only one here. The work of CCAMP has a wider impact on other SDOs and liaisons form a significant part of CCAMP's work. Where GELS is different is the SDO to liaise with, but I do not see that as justification for a separate list. Tom Petch ----- Original Message ----- From: "Adrian Farrel" To: "PAPADIMITRIOU Dimitri" ; "Zafar Ali (zali)" ; "Attila Takacs (IJ/ETH)" ; ; "gels" Cc: "Ross Callon" Sent: Friday, September 07, 2007 10:59 AM Subject: Re: Closing the GELS Mailing List > I think this thread is a representation in miniature of the issues > involved... > > - All the emails in this thread have been copied to both mailing lists > - All the participants in the thread are subscribed to both mailing lists > > No, it doesn't cost to have both lists active. > No, it doesn't cost to have all of the threads on CCAMP. > > Please note that we should not discuss the data plane. If you don't > understand (or don't like, or don't want to use) the data plane you should > have your discussions in private or at the IEEE. > > Dimitri said... > > >> - Label allocation and swapping rules > > is that not a forwarding component discussion ? > > It is certainly informed by the forwarding component (i.e. the definition of > the data plane), but the rules we need to define are the rules for the > control plane. I.e. (and for example, only) if the forwarding plane defines > that the label allocated on the upstream interface must be numerically one > greater than the label allocated on the downstream interface, this rule must > be referenced in the control plane specification. This is important since it > is a constraint placed on the normal per-interface operation of GMPLS. That > makes it CCAMP work. > > > beside the fact that there is an assumption on what > > label means and how it is represented in data plane > > This is also something we would expect to describe within CCAMP although > "what is a label" would come to us from the data plane specification. > > Thanks, > Adrian From owner-ccamp@ops.ietf.org Fri Sep 07 11:52:20 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITg84-0003tZ-65 for ccamp-archive@ietf.org; Fri, 07 Sep 2007 11:52:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITg82-0003un-Sk for ccamp-archive@ietf.org; Fri, 07 Sep 2007 11:52:20 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITfvf-0006Tx-AV for ccamp-data@psg.com; Fri, 07 Sep 2007 15:39:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [64.208.49.27] (helo=smail5.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITfvc-0006TQ-Iu for ccamp@ops.ietf.org; Fri, 07 Sep 2007 15:39:30 +0000 Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l87Fci4p015892; Fri, 7 Sep 2007 17:38:46 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 7 Sep 2007 17:39:17 +0200 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: Closing the GELS Mailing List Date: Fri, 7 Sep 2007 17:35:41 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E380013213D5@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <039601c7f12d$69406a40$0302a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing the GELS Mailing List thread-index: AcfxLW80ieuPuOItQ0mTVyeeZdSmJAANdDTw References: <53CCFDD6E346CB43994852666C210E9101FB483B@esealmw116.eemea.ericsson.se> <014f01c7eb1f$3272db10$0300a8c0@your029b8cecfe> <46D7DDC6.8000205@pi.se> <020501c7f068$270d0c20$0302a8c0@your029b8cecfe> <53CCFDD6E346CB43994852666C210E9102067D40@esealmw116.eemea.ericsson.se> <8144761F31F48D43AD53D09F5350E380012B22ED@FRVELSMBS22.ad2.ad.alcatel.com> <8144761F31F48D43AD53D09F5350E380012B24AF@FRVELSMBS22.ad2.ad.alcatel.com> <039601c7f12d$69406a40$0302a8c0@your029b8cecfe> From: "PAPADIMITRIOU Dimitri" To: "Adrian Farrel" , "Zafar Ali \(zali\)" , "Attila Takacs \(IJ/ETH\)" , , "gels" Cc: "Ross Callon" X-OriginalArrivalTime: 07 Sep 2007 15:39:17.0631 (UTC) FILETIME=[404FC8F0:01C7F165] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 25620135586de10c627e3628c432b04a =20 adrian > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Sent: Friday, September 07, 2007 10:59 AM > To: PAPADIMITRIOU Dimitri; Zafar Ali (zali); Attila Takacs=20 > (IJ/ETH); ccamp@ops.ietf.org; gels > Cc: Ross Callon > Subject: Re: Closing the GELS Mailing List >=20 > I think this thread is a representation in miniature of the issues=20 > involved... >=20 > - All the emails in this thread have been copied to both mailing lists > - All the participants in the thread are subscribed to both=20 > mailing lists >=20 > No, it doesn't cost to have both lists active. > No, it doesn't cost to have all of the threads on CCAMP. >=20 > Please note that we should not discuss the data plane. If you don't=20 > understand (or don't like, or don't want to use) the data=20 > plane you should=20 > have your discussions in private or at the IEEE. >=20 > Dimitri said... >=20 > >> - Label allocation and swapping rules > > is that not a forwarding component discussion ? >=20 > It is certainly informed by the forwarding component (i.e.=20 > the definition of=20 > the data plane), but the rules we need to define are the=20 > rules for the=20 > control plane. I.e. (and for example, only) if the forwarding=20 > plane defines=20 > that the label allocated on the upstream interface must be=20 > numerically one=20 > greater than the label allocated on the downstream interface,=20 > this rule must=20 > be referenced in the control plane specification. This is=20 > important since it=20 > is a constraint placed on the normal per-interface operation=20 > of GMPLS. That=20 > makes it CCAMP work. >=20 > > beside the fact that there is an assumption on what > > label means and how it is represented in data plane >=20 > This is also something we would expect to describe within=20 > CCAMP although=20 > "what is a label" would come to us from the data plane specification. do i interpreet correctly your statement that if the specification that CCAMP is going to receive from IEEE does not speak about "label" and its encoding there will be no place to discuss any "label processing" and "label distribution" protocol in IETF - being domain-wide or link-local - in that case, isn't the .1Q specification outside scope of this effort since not referring - as of today at least - to any "label" semantic as part of the Ethernet frame header information field ? thanks, -d. > Thanks, > Adrian=20 >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Fri Sep 07 14:18:13 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITiPF-0003Ot-4W for ccamp-archive@ietf.org; Fri, 07 Sep 2007 14:18:13 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITiPE-0004Ps-Is for ccamp-archive@ietf.org; Fri, 07 Sep 2007 14:18:12 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITiFP-000LXX-FI for ccamp-data@psg.com; Fri, 07 Sep 2007 18:08:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [217.32.164.138] (helo=smtp3.smtp.bt.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITiFM-000LX9-T0 for ccamp@ops.ietf.org; Fri, 07 Sep 2007 18:08:02 +0000 Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 19:07:58 +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: Closing the GELS Mailing List Date: Fri, 7 Sep 2007 19:07:28 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C0106EDCA@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <8144761F31F48D43AD53D09F5350E380013213D5@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing the GELS Mailing List Thread-Index: AcfxLW80ieuPuOItQ0mTVyeeZdSmJAANdDTwAASP4EA= From: To: , , , , , Cc: X-OriginalArrivalTime: 07 Sep 2007 18:07:58.0386 (UTC) FILETIME=[057EF920:01C7F17A] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Dimitri wrote 07 September 2007 16:36 in response to Adrian > >=20 > > This is also something we would expect to describe within > > CCAMP although=20 > > "what is a label" would come to us from the data plane=20 > specification. >=20 > do i interpreet correctly your statement that if the=20 > specification that CCAMP is going to receive from IEEE does=20 > not speak about "label" and its encoding there will be no=20 > place to discuss any "label processing" and "label=20 > distribution" protocol in IETF - being domain-wide or link-local > - >=20 > in that case, isn't the .1Q specification outside scope of=20 > this effort since not referring - as of today at least - to=20 > any "label" semantic as part of the Ethernet frame header=20 > information field ? >=20 > thanks, > -d. What do you think a MAC DA, MAC SA and VID are? These are all 'labels'. You also have to remember that the nature of the labels required in a traffic unit are determined by the type of the network mode one is dealing with. In the co-cs and co-ps modes we have a construction known as a 'connection'. This implies specific architectural requirements....but the most significant, for this discussion at least, is that a connection must have a single source. What this means is that one does not have to incorporate a SA label in a co mode traffic unit....under defect-free conditions it is redundant information as the connection itself provides the source information. {Compare this to the cl-ps mode which does not have connections...here having a SA in the traffic unit is essential} Ergo why co-cs and co-ps mode technologies to date that respect the requirements of a connection have only focussed on incorporating a DA (forwarding) label. Further, these forwarding labels only need to be distinct in resolving some number (N say) of different client layer (link-connection) instances within a server layer (network connection) resource partition. However, there are advantages from having both a SA and DA label in a co-ps traffic unit that are network unique and not just link-connection unique (ie not swapped)....the inherent robustness under misconnectivity defects (without any adjunct OAM flow) is one of these. And of course, these are the nature of the native labels one already gets in Ethernet due to its cl-ps mode origins. So why would one even contemplate not using these since they are already there? The VID label is slightly different in that one can consider it as a 'route discriminator label' and a local extension to the SA or DA, ie it provides the ability to identify disjoint paths between nodal end points. The mere fact IEEE may not refer to the above quantities as 'labels' does not change the fact that this is what they are. So I'm not clear what your real point is here. regards, Neil From owner-ccamp@ops.ietf.org Fri Sep 07 14:32:29 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITid3-0008Ny-SP for ccamp-archive@ietf.org; Fri, 07 Sep 2007 14:32:29 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITid2-00007s-F9 for ccamp-archive@ietf.org; Fri, 07 Sep 2007 14:32:29 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITiTz-000ND5-Ni for ccamp-data@psg.com; Fri, 07 Sep 2007 18:23:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [62.23.212.7] (helo=smail6.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITiTt-000NCH-Rl for ccamp@ops.ietf.org; Fri, 07 Sep 2007 18:23:06 +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 l87IMOwP004487; Fri, 7 Sep 2007 20:22:24 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 7 Sep 2007 20:22:54 +0200 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: Closing the GELS Mailing List Date: Fri, 7 Sep 2007 20:22:49 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E38001321453@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C0106EDCA@E03MVB2-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing the GELS Mailing List thread-index: AcfxLW80ieuPuOItQ0mTVyeeZdSmJAANdDTwAASP4EAAATdYkA== References: <8144761F31F48D43AD53D09F5350E380013213D5@FRVELSMBS22.ad2.ad.alcatel.com> <2ECAA42C79676B42AEBAC11229CA7D0C0106EDCA@E03MVB2-UKBR.domain1.systemhost.net> From: "PAPADIMITRIOU Dimitri" To: , , , , , Cc: X-OriginalArrivalTime: 07 Sep 2007 18:22:54.0056 (UTC) FILETIME=[1B5B5E80:01C7F17C] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 point is:=20 whether the ethernet frame header fields can be interpreted as "labels" that follows label switching rules applicable to an LSR and what are the implications on forwarding component behaviour when considering such "label encoding" note: per 3031 a label is: a short fixed length physically contiguous identifier which is used to identify a FEC, usually of local significance.=20 =20 -d. > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 > Sent: Friday, September 07, 2007 8:07 PM > To: PAPADIMITRIOU Dimitri; adrian@olddog.co.uk;=20 > zali@cisco.com; Attila.Takacs@ericsson.com;=20 > ccamp@ops.ietf.org; gels@rtg.ietf.org > Cc: rcallon@juniper.net > Subject: RE: Closing the GELS Mailing List >=20 > Dimitri wrote 07 September 2007 16:36 in response to Adrian >=20 > > >=20 > > > This is also something we would expect to describe within > > > CCAMP although=20 > > > "what is a label" would come to us from the data plane=20 > > specification. > >=20 > > do i interpreet correctly your statement that if the=20 > > specification that CCAMP is going to receive from IEEE does=20 > > not speak about "label" and its encoding there will be no=20 > > place to discuss any "label processing" and "label=20 > > distribution" protocol in IETF - being domain-wide or link-local > > - > >=20 > > in that case, isn't the .1Q specification outside scope of=20 > > this effort since not referring - as of today at least - to=20 > > any "label" semantic as part of the Ethernet frame header=20 > > information field ? > >=20 > > thanks, > > -d. >=20 > What do you think a MAC DA, MAC SA and VID are? These are=20 > all 'labels'. >=20 > You also have to remember that the nature of the labels required in a > traffic unit are determined by the type of the network mode one is > dealing with. >=20 > In the co-cs and co-ps modes we have a construction known as a > 'connection'. This implies specific architectural requirements....but > the most significant, for this discussion at least, is that a=20 > connection > must have a single source. What this means is that one does=20 > not have to > incorporate a SA label in a co mode traffic unit....under defect-free > conditions it is redundant information as the connection=20 > itself provides > the source information. {Compare this to the cl-ps mode=20 > which does not > have connections...here having a SA in the traffic unit is essential} >=20 > Ergo why co-cs and co-ps mode technologies to date that respect the > requirements of a connection have only focussed on incorporating a DA > (forwarding) label. Further, these forwarding labels only need to be > distinct in resolving some number (N say) of different client layer > (link-connection) instances within a server layer (network connection) > resource partition. However, there are advantages from=20 > having both a SA > and DA label in a co-ps traffic unit that are network unique and not > just link-connection unique (ie not swapped)....the inherent=20 > robustness > under misconnectivity defects (without any adjunct OAM flow) is one of > these. And of course, these are the nature of the native labels one > already gets in Ethernet due to its cl-ps mode origins. So why would > one even contemplate not using these since they are already there? >=20 > The VID label is slightly different in that one can consider it as a > 'route discriminator label' and a local extension to the SA=20 > or DA, ie it > provides the ability to identify disjoint paths between nodal end > points. >=20 > The mere fact IEEE may not refer to the above quantities as 'labels' > does not change the fact that this is what they are. So I'm not clear > what your real point is here. >=20 > regards, Neil >=20 From owner-ccamp@ops.ietf.org Fri Sep 07 14:54:33 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITiyP-0007tn-0w for ccamp-archive@ietf.org; Fri, 07 Sep 2007 14:54:33 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITiyN-0005Jj-VP for ccamp-archive@ietf.org; Fri, 07 Sep 2007 14:54:32 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITirR-000Psg-Uk for ccamp-data@psg.com; Fri, 07 Sep 2007 18:47:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITirP-000PsF-6F for ccamp@ops.ietf.org; Fri, 07 Sep 2007 18:47:20 +0000 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l87Iku303743; Fri, 7 Sep 2007 18:46:56 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: Closing the GELS Mailing List Date: Fri, 7 Sep 2007 14:46:53 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4113DA7B3@zrtphxm2.corp.nortel.com> In-Reply-To: <8144761F31F48D43AD53D09F5350E38001321453@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing the GELS Mailing List thread-index: AcfxLW80ieuPuOItQ0mTVyeeZdSmJAANdDTwAASP4EAAATdYkAABD4IQ References: <8144761F31F48D43AD53D09F5350E380013213D5@FRVELSMBS22.ad2.ad.alcatel.com> <2ECAA42C79676B42AEBAC11229CA7D0C0106EDCA@E03MVB2-UKBR.domain1.systemhost.net> <8144761F31F48D43AD53D09F5350E38001321453@FRVELSMBS22.ad2.ad.alcatel.com> From: "Don Fedyk" To: "PAPADIMITRIOU Dimitri" , , , , , , Cc: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Dmitri=20 Quoting from GMPLS RFC 3945 seems far more applicable given we are talking a Generalized label switch router (LSR). "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. " Don=20 -----Original Message----- point is:=20 whether the ethernet frame header fields can be interpreted as "labels" that follows label switching rules applicable to an LSR and what are the implications on forwarding component behaviour when considering such "label encoding" note: per 3031 a label is: a short fixed length physically contiguous identifier which is used to identify a FEC, usually of local significance.=20 =20 -d. > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 > Sent: Friday, September 07, 2007 8:07 PM > To: PAPADIMITRIOU Dimitri; adrian@olddog.co.uk;=20 > zali@cisco.com; Attila.Takacs@ericsson.com;=20 > ccamp@ops.ietf.org; gels@rtg.ietf.org > Cc: rcallon@juniper.net > Subject: RE: Closing the GELS Mailing List >=20 > Dimitri wrote 07 September 2007 16:36 in response to Adrian >=20 > > >=20 > > > This is also something we would expect to describe within > > > CCAMP although=20 > > > "what is a label" would come to us from the data plane=20 > > specification. > >=20 > > do i interpreet correctly your statement that if the=20 > > specification that CCAMP is going to receive from IEEE does=20 > > not speak about "label" and its encoding there will be no=20 > > place to discuss any "label processing" and "label=20 > > distribution" protocol in IETF - being domain-wide or link-local > > - > >=20 > > in that case, isn't the .1Q specification outside scope of=20 > > this effort since not referring - as of today at least - to=20 > > any "label" semantic as part of the Ethernet frame header=20 > > information field ? > >=20 > > thanks, > > -d. >=20 > What do you think a MAC DA, MAC SA and VID are? These are=20 > all 'labels'. >=20 > You also have to remember that the nature of the labels required in a > traffic unit are determined by the type of the network mode one is > dealing with. >=20 > In the co-cs and co-ps modes we have a construction known as a > 'connection'. This implies specific architectural requirements....but > the most significant, for this discussion at least, is that a=20 > connection > must have a single source. What this means is that one does=20 > not have to > incorporate a SA label in a co mode traffic unit....under defect-free > conditions it is redundant information as the connection=20 > itself provides > the source information. {Compare this to the cl-ps mode=20 > which does not > have connections...here having a SA in the traffic unit is essential} >=20 > Ergo why co-cs and co-ps mode technologies to date that respect the > requirements of a connection have only focussed on incorporating a DA > (forwarding) label. Further, these forwarding labels only need to be > distinct in resolving some number (N say) of different client layer > (link-connection) instances within a server layer (network connection) > resource partition. However, there are advantages from=20 > having both a SA > and DA label in a co-ps traffic unit that are network unique and not > just link-connection unique (ie not swapped)....the inherent=20 > robustness > under misconnectivity defects (without any adjunct OAM flow) is one of > these. And of course, these are the nature of the native labels one > already gets in Ethernet due to its cl-ps mode origins. So why would > one even contemplate not using these since they are already there? >=20 > The VID label is slightly different in that one can consider it as a > 'route discriminator label' and a local extension to the SA=20 > or DA, ie it > provides the ability to identify disjoint paths between nodal end > points. >=20 > The mere fact IEEE may not refer to the above quantities as 'labels' > does not change the fact that this is what they are. So I'm not clear > what your real point is here. >=20 > regards, Neil >=20 From owner-ccamp@ops.ietf.org Fri Sep 07 15:27:28 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITjUG-0005GK-Fm for ccamp-archive@ietf.org; Fri, 07 Sep 2007 15:27:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITjUE-0001cO-Kp for ccamp-archive@ietf.org; Fri, 07 Sep 2007 15:27:28 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITjOW-0003TY-Kt for ccamp-data@psg.com; Fri, 07 Sep 2007 19:21:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.1 Received: from [209.191.85.62] (helo=web36811.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITjOT-0003TC-GB for ccamp@ops.ietf.org; Fri, 07 Sep 2007 19:21:31 +0000 Received: (qmail 60505 invoked by uid 60001); 7 Sep 2007 19:21:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=OD1D2jvPCKagDP8ATAdRy+JU4Et6XhFmz+SZQF9ImvwzUe0Jvs0vXbIXS6QbU9ARNIgKAQ7clagYsrrJNoCGcDrKmyV+TkMkIzgpE66+65ytozj8rQegwpaDIH/z+skHQu8MfQExCMhZRw/s4uvNzdjDDprCebB9tWZB4pTk5/c=; X-YMail-OSG: hYsZKpIVM1kI2J8gTo11DTnQqMI32KTqICMVOlCml3Mp_OvKQEon_U1S7V2jDoUB.M5ds4tFJRwmYENSZTSQ_WuukTMEpATB1rypvKg_fPfcmDP5aJZY51fWag-- Received: from [67.102.145.11] by web36811.mail.mud.yahoo.com via HTTP; Fri, 07 Sep 2007 12:21:21 PDT Date: Fri, 7 Sep 2007 12:21:21 -0700 (PDT) From: Igor Bryskin Subject: RE: Closing the GELS Mailing List To: neil.2.harrison@bt.com, Dimitri.Papadimitriou@alcatel-lucent.be, adrian@olddog.co.uk, zali@cisco.com, Attila.Takacs@ericsson.com, ccamp@ops.ietf.org, gels@rtg.ietf.org Cc: rcallon@juniper.net In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C0106EDCA@E03MVB2-UKBR.domain1.systemhost.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1020572678-1189192881=:59428" Content-Transfer-Encoding: 8bit Message-ID: <150025.59428.qm@web36811.mail.mud.yahoo.com> Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --0-1020572678-1189192881=:59428 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Neil, I think there is a difference between a "data plane label" which is a Layer Information (LI) used by a given server layer and a "control plane label", which is a piece of information signaled between adjacent controllers for the purpose of connection provisioning. IMO the former is always a superset of the latter. Let's take, for instance, connection oriented Ethernet. MAC SA is a very important part of the data plane label because it identifies the source of the connection. However, the connection frames are forwarded according to MAC DA/VID, and hence connection ingress node, for example, needs only be signaled with this tuple by the downstream neighbor, hence the control plane label is MAC DA/VID (or just VID, for those who like the idea of the VID cross-connects architecture). So, IMO IEEE should be responsible for the definition of data plane labels, while CCAMP for control plane labels. Cheers, Igor neil.2.harrison@bt.com wrote: Dimitri wrote 07 September 2007 16:36 in response to Adrian > > > > This is also something we would expect to describe within > > CCAMP although > > "what is a label" would come to us from the data plane > specification. > > do i interpreet correctly your statement that if the > specification that CCAMP is going to receive from IEEE does > not speak about "label" and its encoding there will be no > place to discuss any "label processing" and "label > distribution" protocol in IETF - being domain-wide or link-local > - > > in that case, isn't the .1Q specification outside scope of > this effort since not referring - as of today at least - to > any "label" semantic as part of the Ethernet frame header > information field ? > > thanks, > -d. What do you think a MAC DA, MAC SA and VID are? These are all 'labels'. You also have to remember that the nature of the labels required in a traffic unit are determined by the type of the network mode one is dealing with. In the co-cs and co-ps modes we have a construction known as a 'connection'. This implies specific architectural requirements....but the most significant, for this discussion at least, is that a connection must have a single source. What this means is that one does not have to incorporate a SA label in a co mode traffic unit....under defect-free conditions it is redundant information as the connection itself provides the source information. {Compare this to the cl-ps mode which does not have connections...here having a SA in the traffic unit is essential} Ergo why co-cs and co-ps mode technologies to date that respect the requirements of a connection have only focussed on incorporating a DA (forwarding) label. Further, these forwarding labels only need to be distinct in resolving some number (N say) of different client layer (link-connection) instances within a server layer (network connection) resource partition. However, there are advantages from having both a SA and DA label in a co-ps traffic unit that are network unique and not just link-connection unique (ie not swapped)....the inherent robustness under misconnectivity defects (without any adjunct OAM flow) is one of these. And of course, these are the nature of the native labels one already gets in Ethernet due to its cl-ps mode origins. So why would one even contemplate not using these since they are already there? The VID label is slightly different in that one can consider it as a 'route discriminator label' and a local extension to the SA or DA, ie it provides the ability to identify disjoint paths between nodal end points. The mere fact IEEE may not refer to the above quantities as 'labels' does not change the fact that this is what they are. So I'm not clear what your real point is here. regards, Neil --------------------------------- Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when. --0-1020572678-1189192881=:59428 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi Neil,
 
I think there is a difference between a "data plane label" which is a Layer Information (LI) used by a given server layer and a "control plane label", which is a piece of information signaled between adjacent controllers for the purpose of connection provisioning. IMO the former is always a superset of the latter. Let's take, for instance, connection oriented Ethernet. MAC SA is a very important part of the data plane label because it identifies the source of the connection. However, the connection frames are forwarded according to MAC DA/VID, and hence connection ingress node, for example, needs only be signaled with this tuple by the downstream neighbor, hence the control plane label is MAC DA/VID (or just VID, for those who like the idea of the VID cross-connects architecture).
 
So, IMO IEEE should be responsible for the definition of data plane labels, while CCAMP for control plane labels.
 
Cheers,
Igor


neil.2.harrison@bt.com wrote:
Dimitri wrote 07 September 2007 16:36 in response to Adrian

> >
> > This is also something we would expect to describe within
> > CCAMP although
> > "what is a label" would come to us from the data plane
> specification.
>
> do i interpreet correctly your statement that if the
> specification that CCAMP is going to receive from IEEE does
> not speak about "label" and its encoding there will be no
> place to discuss any "label processing" and "label
> distribution" protocol in IETF - being domain-wide or link-local
> -
>
> in that case, isn't the .1Q specification outside scope of
> this effort since not referring - as of today at least - to
> any "label" semantic as part of the Ethernet frame header
> information field ?
>
> thanks,
> -d.

What do you think a MAC DA, MAC SA and VID are? These are all 'labels'.

You also have to remember that the nature of the labels required in a
traffic unit are determined by the type of the network mode one is
dealing with.

In the co-cs and co-ps modes we have a construction known as a
'connection'. This implies specific architectural requirements....but
the most significant, for this discussion at least, is that a connection
must have a single source. What this means is that one does not have to
incorporate a SA label in a co mode traffic unit....under defect-free
conditions it is redundant information as the connection itself provides
the source information. {Compare this to the cl-ps mode which does not
have connections...here having a SA in the traffic unit is essential}

Ergo why co-cs and co-ps mode technologies to date that respect the
requirements of a connection have only focussed on incorporating a DA
(forwarding) label. Further, these forwarding labels only need to be
distinct in resolving some number (N say) of different client layer
(link-connection) instances within a server layer (network connection)
resource partition. However, there are advantages from having both a SA
and DA label in a co-ps traffic unit that are network unique and not
just link-connection unique (ie not swapped)....the inherent robustness
under misconnectivity defects (without any adjunct OAM flow) is one of
these. And of course, these are the nature of the native labels one
already gets in Ethernet due to its cl-ps mode origins. So why would
one even contemplate not using these since they are already there?

The VID label is slightly different in that one can consider it as a
'route discriminator label' and a local extension to the SA or DA, ie it
provides the ability to identify disjoint paths between nodal end
points.

The mere fact IEEE may not refer to the above quantities as 'labels'
does not change the fact that this is what they are. So I'm not clear
what your real point is here.

regards, Neil



Sick sense of humor? Visit Yahoo! TV's
Comedy with an Edge to see what's on, when. --0-1020572678-1189192881=:59428-- From owner-ccamp@ops.ietf.org Fri Sep 07 15:41:35 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITjhv-0004h9-MG for ccamp-archive@ietf.org; Fri, 07 Sep 2007 15:41:35 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITjhv-0006Mj-2k for ccamp-archive@ietf.org; Fri, 07 Sep 2007 15:41:35 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITjYX-0004XT-6p for ccamp-data@psg.com; Fri, 07 Sep 2007 19:31:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [62.23.212.27] (helo=smail5.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITjYU-0004X9-Ak for ccamp@ops.ietf.org; Fri, 07 Sep 2007 19:31:51 +0000 Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.ad2.ad.alcatel.com [155.132.6.74]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l87JVEfK016164; Fri, 7 Sep 2007 21:31:14 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 7 Sep 2007 21:31:47 +0200 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: Closing the GELS Mailing List Date: Fri, 7 Sep 2007 21:28:32 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E3800132145A@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <054301c7f17e$88545530$0302a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing the GELS Mailing List thread-index: Acfxfo1FWPWaKkHtTI6n07oaVlXTmgAA7BrA References: <53CCFDD6E346CB43994852666C210E9101FB483B@esealmw116.eemea.ericsson.se> <014f01c7eb1f$3272db10$0300a8c0@your029b8cecfe> <46D7DDC6.8000205@pi.se> <020501c7f068$270d0c20$0302a8c0@your029b8cecfe> <53CCFDD6E346CB43994852666C210E9102067D40@esealmw116.eemea.ericsson.se> <8144761F31F48D43AD53D09F5350E380012B22ED@FRVELSMBS22.ad2.ad.alcatel.com> <8144761F31F48D43AD53D09F5350E380012B24AF@FRVELSMBS22.ad2.ad.alcatel.com> <039601c7f12d$69406a40$0302a8c0@your029b8cecfe> <8144761F31F48D43AD53D09F5350E380013213D5@FRVELSMBS22.ad2.ad.alcatel.com> <054301c7f17e$88545530$0302a8c0@your029b8cecfe> From: "PAPADIMITRIOU Dimitri" To: "Adrian Farrel" , , X-OriginalArrivalTime: 07 Sep 2007 19:31:47.0499 (UTC) FILETIME=[BB14B7B0:01C7F185] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 hi adrian, > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Sent: Friday, September 07, 2007 8:40 PM > To: PAPADIMITRIOU Dimitri; ccamp@ops.ietf.org > Subject: Re: Closing the GELS Mailing List >=20 > Hi Dimitri, >=20 > >>> beside the fact that there is an assumption on what > >>> label means and how it is represented in data plane > >> > >> This is also something we would expect to describe within > >> CCAMP although "what is a label" would come to us from > >> the data plane specification. > > > > do i interpreet correctly your statement that if the specification > > that CCAMP is going to receive from IEEE does not speak > > about "label" and its encoding there will be no place to discuss > > any "label processing" and "label distribution" protocol in IETF > > - being domain-wide or link-local >=20 > I expect the IEEE specification to define the forwarding paradigm. >=20 > For example: Frames in 802.1Qay are forwarded based on the=20 > checksum value > carried in the frame. >=20 > I expect us to build a GMPLS solution that can be used to=20 > configure/install > that forwarding paradigm. >=20 > If (for example) the destination MAC is the forwarding=20 > trigger, and the > destination MAC is also intended to have genuine network-wide=20 > scope and > identify the recipient of the frame to the whole network,=20 > then the label is > (by definition) network-scoped. >=20 > > in that case, isn't the .1Q specification outside scope of=20 > this effort > > since not referring - as of today at least - to any "label"=20 > semantic as > > part of the Ethernet frame header information field ? >=20 > No. That is like saying that TDM and lambda were out of scope=20 > for GMPLS because their definitions didn't refer to labels. we were confronted to that problem a couple of years ago. the difference with techno's that do not encode label in the "data plane" is that in the present case, the forwarding itself was label value dependent > The point is that a label is the identifier by which traffic=20 > on an interface > may be identified for forwarding. The data plane spec should=20 > indicate what > that identifier is, and we call that a label and have to pass=20 > it around in > signaling. this is already an extended version of a classical label def. now, speaking about "label" switching router induces a behaviour that was not felt "respectful" to the operations of an Ethernet switch. it was felt that the control plane was constraining the fwd'ing plane - in brief, the point was incorporating a source-initiated explicitly routed data path establishment (with or without the associated resource reservation) was inducing behaviour not currently supported by the Ethernet forwarding component - the reason for maintaining the GELS list at that time was explicitly to maintain a place where such discussion could happen > I have no idea whether that means that the .1Q spec is in=20 > scope or not. independently of this i think we're entering the discussion that was the key reason why efforts did not succeed... .1Q spec did not change since then in order to accommodate this. there is a simple hope that another ongoing effort would allow for such kind of behaviour. > A >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Fri Sep 07 16:07:16 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITk6m-0004jX-9T for ccamp-archive@ietf.org; Fri, 07 Sep 2007 16:07:16 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITk6l-00071q-Ch for ccamp-archive@ietf.org; Fri, 07 Sep 2007 16:07:16 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITjzT-0007Ua-1A for ccamp-data@psg.com; Fri, 07 Sep 2007 19:59:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [64.208.49.5] (helo=smail6.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITjzP-0007T9-Kl for ccamp@ops.ietf.org; Fri, 07 Sep 2007 19:59:41 +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 l87Jwtmu012713; Fri, 7 Sep 2007 21:58:55 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 7 Sep 2007 21:59:25 +0200 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: Closing the GELS Mailing List Date: Fri, 7 Sep 2007 21:59:20 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E38001321463@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA4113DA7B3@zrtphxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing the GELS Mailing List thread-index: AcfxLW80ieuPuOItQ0mTVyeeZdSmJAANdDTwAASP4EAAATdYkAABD4IQAAF0v+A= References: <8144761F31F48D43AD53D09F5350E380013213D5@FRVELSMBS22.ad2.ad.alcatel.com> <2ECAA42C79676B42AEBAC11229CA7D0C0106EDCA@E03MVB2-UKBR.domain1.systemhost.net> <8144761F31F48D43AD53D09F5350E38001321453@FRVELSMBS22.ad2.ad.alcatel.com> <34B3EAA5B3066A42914D28C5ECF5FEA4113DA7B3@zrtphxm2.corp.nortel.com> From: "PAPADIMITRIOU Dimitri" To: "Don Fedyk" , , , , , , Cc: X-OriginalArrivalTime: 07 Sep 2007 19:59:25.0896 (UTC) FILETIME=[97900480:01C7F189] 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: 48472a944c87678fcfe8db15ffecdfff don,=20 interesting 3 years ago you blaim me on the same list when i quoted this definition when discussing applicability of GMPLS to Ethernet ;-) the evolution of Ethernet forwarding components themselves leads to an open issue today compared to the situation we observed a couple of years ago. if this would not be true one would have not seen since this definition has been written end 2000 in rfc3945 that there has been lot's efforts in various bodies involved in Ethernet to incorporate as part of that technology properties that would facilitate Ethernet network operations -- and this due to its expected applicability in environments for which that technology has not been initially designed for -- and this is whole point actually (*) back to the point: when that definition was written down it was understood that adding GMPLS control plane to an Ethernet fowarding plane would lead to address such expectations. nevertheless, we ack'ed since the GELS BoF (held by Loa and myself) in 2005 that the "combination" would be possible if one of the following conditions hold - IEEE provides a data plane spec. that allows accommodating the fwd'ing behaviour determined by GMPLS (and all related routing paradigms) - IEEE ack's that some if its header's field can be processed equivalently to a per-platform/link-local switching "label" with all its resulting implications (if fact the answer was never totally clear at the end) - GMPLS evolves to sustain all control modes connectionless fwd'ing would allow (this option was not even discussed) =20 =3D> hence, the question remains open. i would love to see progress on that matter (at least that IEEE tells us yes or no) but for the time being we're left with unilateral interpretations that are blocking real progress from the std perspective (the problem is mainly not technical ... it is the problem that CCAMP faces each time its prefered control plane protocol suite tries to cover a technology) =20 (*) it was felt 2 or 3 years ago that operators could help and provide us with their expectation in that respect but no real outcome came out of various tentatives to obtain such type of operational feedback > -----Original Message----- > From: Don Fedyk [mailto:dwfedyk@nortel.com]=20 > Sent: Friday, September 07, 2007 8:47 PM > To: PAPADIMITRIOU Dimitri; neil.2.harrison@bt.com;=20 > adrian@olddog.co.uk; zali@cisco.com;=20 > Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org > Cc: rcallon@juniper.net > Subject: RE: Closing the GELS Mailing List >=20 > Dmitri=20 >=20 > Quoting from GMPLS RFC 3945 seems far more applicable given we are > talking a Generalized label switch router (LSR). >=20 > "2. Layer-2 Switch Capable (L2SC) interfaces: >=20 > 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 > Don=20 >=20 > -----Original Message----- >=20 > point is:=20 >=20 > whether the ethernet frame header fields can be interpreted=20 > as "labels" > that follows label switching rules applicable to an LSR and=20 > what are the > implications on forwarding component behaviour when considering such > "label encoding" >=20 >=20 > note: per 3031 a label is: a short fixed length physically contiguous > identifier which is used to identify a FEC, usually of local > significance.=20 > =20 > -d. > > -----Original Message----- > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 > > Sent: Friday, September 07, 2007 8:07 PM > > To: PAPADIMITRIOU Dimitri; adrian@olddog.co.uk;=20 > > zali@cisco.com; Attila.Takacs@ericsson.com;=20 > > ccamp@ops.ietf.org; gels@rtg.ietf.org > > Cc: rcallon@juniper.net > > Subject: RE: Closing the GELS Mailing List > >=20 > > Dimitri wrote 07 September 2007 16:36 in response to Adrian=20 > > >=20 > > > >=20 > > > > This is also something we would expect to describe within > > > > CCAMP although=20 > > > > "what is a label" would come to us from the data plane=20 > > > specification. > > >=20 > > > do i interpreet correctly your statement that if the=20 > > > specification that CCAMP is going to receive from IEEE does=20 > > > not speak about "label" and its encoding there will be no=20 > > > place to discuss any "label processing" and "label=20 > > > distribution" protocol in IETF - being domain-wide or link-local > > > - > > >=20 > > > in that case, isn't the .1Q specification outside scope of=20 > > > this effort since not referring - as of today at least - to=20 > > > any "label" semantic as part of the Ethernet frame header=20 > > > information field ? > > >=20 > > > thanks, > > > -d. > >=20 > > What do you think a MAC DA, MAC SA and VID are? These are=20 > > all 'labels'. > >=20 > > You also have to remember that the nature of the labels=20 > required in a > > traffic unit are determined by the type of the network mode one is > > dealing with. > >=20 > > In the co-cs and co-ps modes we have a construction known as a > > 'connection'. This implies specific architectural=20 > requirements....but > > the most significant, for this discussion at least, is that a=20 > > connection > > must have a single source. What this means is that one does=20 > > not have to > > incorporate a SA label in a co mode traffic unit....under=20 > defect-free > > conditions it is redundant information as the connection=20 > > itself provides > > the source information. {Compare this to the cl-ps mode=20 > > which does not > > have connections...here having a SA in the traffic unit is=20 > essential} > >=20 > > Ergo why co-cs and co-ps mode technologies to date that respect the > > requirements of a connection have only focussed on=20 > incorporating a DA > > (forwarding) label. Further, these forwarding labels only=20 > need to be > > distinct in resolving some number (N say) of different client layer > > (link-connection) instances within a server layer (network=20 > connection) > > resource partition. However, there are advantages from=20 > > having both a SA > > and DA label in a co-ps traffic unit that are network unique and not > > just link-connection unique (ie not swapped)....the inherent=20 > > robustness > > under misconnectivity defects (without any adjunct OAM=20 > flow) is one of > > these. And of course, these are the nature of the native labels one > > already gets in Ethernet due to its cl-ps mode origins. So=20 > why would > > one even contemplate not using these since they are already there? > >=20 > > The VID label is slightly different in that one can consider it as a > > 'route discriminator label' and a local extension to the SA=20 > > or DA, ie it > > provides the ability to identify disjoint paths between nodal end > > points. > >=20 > > The mere fact IEEE may not refer to the above quantities as 'labels' > > does not change the fact that this is what they are. So=20 > I'm not clear > > what your real point is here. > >=20 > > regards, Neil > >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Fri Sep 07 17:01:09 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITkwv-00015J-C7 for ccamp-archive@ietf.org; Fri, 07 Sep 2007 17:01:09 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITkwu-0008Nn-Lc for ccamp-archive@ietf.org; Fri, 07 Sep 2007 17:01:09 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITkrN-000Dc1-M1 for ccamp-data@psg.com; Fri, 07 Sep 2007 20:55:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [217.32.164.138] (helo=smtp3.smtp.bt.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITkrK-000DbZ-Ni for ccamp@ops.ietf.org; Fri, 07 Sep 2007 20:55:24 +0000 Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 21:55:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Closing the GELS Mailing List Date: Fri, 7 Sep 2007 21:55:07 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C0106EDD6@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <8144761F31F48D43AD53D09F5350E38001321453@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing the GELS Mailing List Thread-Index: AcfxLW80ieuPuOItQ0mTVyeeZdSmJAANdDTwAASP4EAAATdYkAAA1EUA From: To: , , , , , Cc: X-OriginalArrivalTime: 07 Sep 2007 20:55:21.0362 (UTC) FILETIME=[67937F20:01C7F191] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 OK, thanks. I tend to take my cues from the unified modelling work where I can see (and challenge if need be) the logical derivation of how labelling and resource partitioning work in each network mode....I don't see that degree of rigour in the shorter statement below. Is there something technically incorrect in what I stated previously? regards, Neil > -----Original Message----- > From: PAPADIMITRIOU Dimitri > [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20 > Sent: 07 September 2007 19:23 > To: Harrison,N,Neil,JCGA1 R; adrian@olddog.co.uk;=20 > zali@cisco.com; Attila.Takacs@ericsson.com;=20 > ccamp@ops.ietf.org; gels@rtg.ietf.org > Cc: rcallon@juniper.net > Subject: RE: Closing the GELS Mailing List >=20 >=20 > point is: >=20 > whether the ethernet frame header fields can be interpreted > as "labels" that follows label switching rules applicable to=20 > an LSR and what are the implications on forwarding component=20 > behaviour when considering such "label encoding" >=20 >=20 > note: per 3031 a label is: a short fixed length physically > contiguous identifier which is used to identify a FEC,=20 > usually of local significance.=20 > =20 > -d. > > -----Original Message----- > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > Sent: Friday, September 07, 2007 8:07 PM > > To: PAPADIMITRIOU Dimitri; adrian@olddog.co.uk; > > zali@cisco.com; Attila.Takacs@ericsson.com;=20 > > ccamp@ops.ietf.org; gels@rtg.ietf.org > > Cc: rcallon@juniper.net > > Subject: RE: Closing the GELS Mailing List > >=20 > > Dimitri wrote 07 September 2007 16:36 in response to Adrian > > >=20 > > > >=20 > > > > This is also something we would expect to describe within CCAMP > > > > although "what is a label" would come to us from the data plane > > > specification. > > >=20 > > > do i interpreet correctly your statement that if the specification > > > that CCAMP is going to receive from IEEE does not speak about=20 > > > "label" and its encoding there will be no place to discuss any=20 > > > "label processing" and "label distribution" protocol in IETF -=20 > > > being domain-wide or link-local > > > - > > >=20 > > > in that case, isn't the .1Q specification outside scope of this=20 > > > effort since not referring - as of today at least - to any "label" > > > semantic as part of the Ethernet frame header information field ? > > >=20 > > > thanks, > > > -d. > >=20 > > What do you think a MAC DA, MAC SA and VID are? These are all=20 > > 'labels'. > >=20 > > You also have to remember that the nature of the labels > required in a > > traffic unit are determined by the type of the network mode one is > > dealing with. > >=20 > > In the co-cs and co-ps modes we have a construction known as a > > 'connection'. This implies specific architectural=20 > requirements....but > > the most significant, for this discussion at least, is that a > > connection must have a single source. What this means is that one=20 > > does not have to > > incorporate a SA label in a co mode traffic unit....under=20 > defect-free > > conditions it is redundant information as the connection > > itself provides > > the source information. {Compare this to the cl-ps mode=20 > > which does not > > have connections...here having a SA in the traffic unit is=20 > essential} > >=20 > > Ergo why co-cs and co-ps mode technologies to date that respect the > > requirements of a connection have only focussed on=20 > incorporating a DA > > (forwarding) label. Further, these forwarding labels only > need to be > > distinct in resolving some number (N say) of different client layer > > (link-connection) instances within a server layer (network > connection) > > resource partition. However, there are advantages from > having both a > > SA and DA label in a co-ps traffic unit that are network unique and > > not just link-connection unique (ie not swapped)....the inherent > > robustness > > under misconnectivity defects (without any adjunct OAM=20 > flow) is one of > > these. And of course, these are the nature of the native labels one > > already gets in Ethernet due to its cl-ps mode origins. So > why would > > one even contemplate not using these since they are already there? > >=20 > > The VID label is slightly different in that one can > consider it as a > > 'route discriminator label' and a local extension to the SA > or DA, ie > > it provides the ability to identify disjoint paths between nodal end > > points. > >=20 > > The mere fact IEEE may not refer to the above quantities as > 'labels' > > does not change the fact that this is what they are. So > I'm not clear > > what your real point is here. > >=20 > > regards, Neil > >=20 >=20 From owner-ccamp@ops.ietf.org Fri Sep 07 17:03:36 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITkzI-00040P-IQ for ccamp-archive@ietf.org; Fri, 07 Sep 2007 17:03:36 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITkzH-0008Rt-8c for ccamp-archive@ietf.org; Fri, 07 Sep 2007 17:03:36 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITkrW-000DcY-A2 for ccamp-data@psg.com; Fri, 07 Sep 2007 20:55:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [217.32.164.150] (helo=smtp2.smtp.bt.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITkrK-000DbN-Ng for ccamp@ops.ietf.org; Fri, 07 Sep 2007 20:55:24 +0000 Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 21:55: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_01C7F191.665EE1C3" Subject: RE: Closing the GELS Mailing List Date: Fri, 7 Sep 2007 21:54:51 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C0106EDD5@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <150025.59428.qm@web36811.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing the GELS Mailing List Thread-Index: AcfxhEuTFFhWytl+TVC9R5M3ZflIdwAB08YQ From: To: , , , , , , Cc: X-OriginalArrivalTime: 07 Sep 2007 20:55:20.0192 (UTC) FILETIME=[66E0F800:01C7F191] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78 This is a multi-part message in MIME format. ------_=_NextPart_001_01C7F191.665EE1C3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Igor...I understand what you mean...and yes for *forwarding* purposes (on the assumption the requirements of a connection are met) you are right. It is, however, also important for the CP to tell the sink(s) of the connection what SA it expects to appear in the CV OAM pkts and this esp important if the co-ps mode layer network is based on the less optimal label-swapping paradigm. Of course, if we don't use label-swapping as in the case of PBB-TE then the CV function (of correct connectivity verification) appears 'for free' in each/every traffic unit....not just the OAM pkts, which are really only now required to distinguish a quiescent traffic case from a simple broken connection. =20 regards, Neil -----Original Message----- From: Igor Bryskin [mailto:i_bryskin@yahoo.com]=20 Sent: 07 September 2007 20:21 To: Harrison,N,Neil,JCGA1 R; Dimitri.Papadimitriou@alcatel-lucent.be; adrian@olddog.co.uk; zali@cisco.com; Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org Cc: rcallon@juniper.net Subject: RE: Closing the GELS Mailing List Hi Neil, I think there is a difference between a "data plane label" which is a Layer Information (LI) used by a given server layer and a "control plane label", which is a piece of information signaled between adjacent controllers for the purpose of connection provisioning. IMO the former is always a superset of the latter. Let's take, for instance, connection oriented Ethernet. MAC SA is a very important part of the data plane label because it identifies the source of the connection. However, the connection frames are forwarded according to MAC DA/VID, and hence connection ingress node, for example, needs only be signaled with this tuple by the downstream neighbor, hence the control plane label is MAC DA/VID (or just VID, for those who like the idea of the VID cross-connects architecture). So, IMO IEEE should be responsible for the definition of data plane labels, while CCAMP for control plane labels. Cheers, Igor=20 neil.2.harrison@bt.com wrote:=20 Dimitri wrote 07 September 2007 16:36 in response to Adrian=20 > >=20 > > This is also something we would expect to describe within > > CCAMP although=20 > > "what is a label" would come to us from the data plane=20 > specification. >=20 > do i interpreet correctly your statement that if the=20 > specification that CCAMP is going to receive from IEEE does=20 > not speak about "label" and its encoding there will be no=20 > place to discuss any "label processing" and "label=20 > distribution" protocol in IETF - being domain-wide or link-local > - >=20 > in that case, isn't the .1Q specification outside scope of=20 > this effort since not referring - as of today at least - to=20 > any "label" semantic as part of the Ethernet frame header=20 > information field ? >=20 > thanks, > -d. What do you think a MAC DA, MAC SA and VID are? These are all 'labels'. You also have to remember that the nature of the labels required in a traffic unit are determined by the type of the network mode one is dealing with. In the co-cs and co-ps modes we have a construction known as a 'connection'. This implies specific architectural requirements....but the most significant, for this discussion at least, is that a connection must have a single source. What this means is that one does not have to incorporate a SA label in a co mode traffic unit....under defect-free conditions it is redundant information as the connection itself provides the source information. {Compare this to the cl-ps mode which does not have connections...here having a SA in the traffic unit is essential} Ergo why co-cs and co-ps mode technologies to date that respect the requirements of a connection have only focussed on incorporating a DA (forwarding) label. Further, these forwarding labels only need to be distinct in resolving some number (N say) of different client layer (link-connection) instances within a server layer (network connection) resource partition. However, there are advantages from having both a SA and DA label in a co-ps traffic unit that are network unique and not just link-connection unique (ie not swapped)....the inherent robustness under misconnectivity defects (without any adjunct OAM flow) is one of these. And of course, these are the nature of the native labels one already gets in Ethernet due to its cl-ps mode origins. So why would one even contemplate not using these since they are already there? The VID label is slightly different in that one can consider it as a 'route discriminator label' and a local extension to the SA or DA, ie it provides the ability to identify disjoint paths between nodal end points. The mere fact IEEE may not refer to the above quantities as 'labels' does not change the fact that this is what they are. So I'm not clear what your real point is here. regards, Neil _____ =20 Sick sense of humor? Visit Yahoo! TV's Comedy = with an Edge to see what's on, when.=20 ------_=_NextPart_001_01C7F191.665EE1C3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi Igor...I understand what you mean...and yes for *forwarding* = purposes=20 (on the assumption the requirements of a connection are met) you are=20 right.  It is, however, also important for the CP to tell the = sink(s) of=20 the connection what SA it expects to appear in the CV OAM pkts and this = esp=20 important if the co-ps mode layer network is based on the less optimal=20 label-swapping paradigm.  Of course, if we don't use label-swapping = as in=20 the case of PBB-TE then the CV function (of correct connectivity = verification)=20 appears 'for free' in each/every traffic unit....not just the OAM pkts, = which=20 are really only now required to distinguish a quiescent traffic case = from a=20 simple broken connection.
 
regards, Neil
-----Original Message-----
From: Igor = Bryskin=20 [mailto:i_bryskin@yahoo.com]
Sent: 07 September 2007=20 20:21
To: Harrison,N,Neil,JCGA1 R;=20 Dimitri.Papadimitriou@alcatel-lucent.be; adrian@olddog.co.uk; = zali@cisco.com;=20 Attila.Takacs@ericsson.com; ccamp@ops.ietf.org;=20 gels@rtg.ietf.org
Cc: rcallon@juniper.net
Subject: = RE:=20 Closing the GELS Mailing List

Hi Neil,
I think there is a difference between a = "data plane=20 label" which is a Layer Information (LI) used by a given server layer = and a=20 "control plane label", which is a piece of information signaled = between=20 adjacent controllers for the purpose of connection provisioning. IMO = the=20 former is always a superset of the latter. Let's take, for instance,=20 connection oriented Ethernet. MAC SA is a very important part of the = data=20 plane label because it identifies the source of the connection. = However, the=20 connection frames are forwarded according to MAC DA/VID, and hence = connection=20 ingress node, for example, needs only be signaled with this tuple by = the=20 downstream neighbor, hence the control plane label is MAC DA/VID (or = just VID,=20 for those who like the idea of the VID cross-connects=20 architecture).
So, IMO IEEE should be responsible for the = definition=20 of data plane labels, while CCAMP for control plane = labels.
Cheers,
Igor=20


neil.2.harrison@bt.com wrote:=20
Dimitri=20 wrote 07 September 2007 16:36 in response to Adrian =

>=20 >
> > This is also something we would expect to = describe=20 within
> > CCAMP although
> > "what is a label" = would=20 come to us from the data plane
> specification.
> =
> do i=20 interpreet correctly your statement that if the
> = specification that=20 CCAMP is going to receive from IEEE does
> not speak about = "label"=20 and its encoding there will be no
> place to discuss any = "label=20 processing" and "label
> distribution" protocol in IETF - = being=20 domain-wide or link-local
> -
>
> in that case, = isn't the=20 .1Q specification outside scope of
> this effort since not = referring=20 - as of today at least - to
> any "label" semantic as part of = the=20 Ethernet frame header
> information field ?
>
>=20 thanks,
> -d.

What do you think a MAC DA, MAC SA and = VID are?=20 These are all 'labels'.

You also have to remember that the = nature of=20 the labels required in a
traffic unit are determined by the type = of the=20 network mode one is
dealing with.

In the co-cs and co-ps = modes we=20 have a construction known as a
'connection'. This implies = specific=20 architectural requirements....but
the most significant, for this=20 discussion at least, is that a connection
must have a single = source. What=20 this means is that one does not have to
incorporate a SA label in = a co=20 mode traffic unit....under defect-free
conditions it is redundant = information as the connection itself provides
the source = information.=20 {Compare this to the cl-ps mode which does not
have = connections...here=20 having a SA in the traffic unit is essential}

Ergo why co-cs = and=20 co-ps mode technologies to date that respect the
requirements of = a=20 connection have only focussed on incorporating a DA
(forwarding) = label.=20 Further, these forwarding labels only need to be
distinct in = resolving=20 some number (N say) of different client layer
(link-connection) = instances=20 within a server layer (network connection)
resource partition. = However,=20 there are advantages from having both a SA
and DA label in a = co-ps=20 traffic unit that are network unique and not
just link-connection = unique=20 (ie not swapped)....the inherent robustness
under misconnectivity = defects=20 (without any adjunct OAM flow) is one of
these. And of course, = these are=20 the nature of the native labels one
already gets in Ethernet due = to its=20 cl-ps mode origins. So why would
one even contemplate not using = these=20 since they are already there?

The VID label is slightly = different in=20 that one can consider it as a
'route discriminator label' and a = local=20 extension to the SA or DA, ie it
provides the ability to identify = disjoint paths between nodal end
points.

The mere fact = IEEE may=20 not refer to the above quantities as 'labels'
does not change the = fact=20 that this is what they are. So I'm not clear
what your real point = is=20 here.

regards, Neil



Sick sense of humor? Visit Yahoo! TV's Comedy=20 with an Edge to see what's on, when. ------_=_NextPart_001_01C7F191.665EE1C3-- From owner-ccamp@ops.ietf.org Fri Sep 07 17:22:52 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITlHw-00072H-NC for ccamp-archive@ietf.org; Fri, 07 Sep 2007 17:22:52 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITlHw-0000YM-9u for ccamp-archive@ietf.org; Fri, 07 Sep 2007 17:22:52 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITlAZ-000FpF-SE for ccamp-data@psg.com; Fri, 07 Sep 2007 21:15:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [212.23.8.67] (helo=fizeau.zen.co.uk) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITlAX-000Foo-8q for ccamp@ops.ietf.org; Fri, 07 Sep 2007 21:15:14 +0000 Received: from [212.23.3.141] (helo=heisenberg.zen.co.uk) by fizeau.zen.co.uk with esmtp (Exim 4.50) id 1ITikg-0003jO-JI for ccamp@ops.ietf.org; Fri, 07 Sep 2007 18:40:22 +0000 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1ITikf-000669-8R for ccamp@ops.ietf.org; Fri, 07 Sep 2007 18:40:21 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Sep 2007 19:40:20 +0100 Message-ID: <054301c7f17e$88545530$0302a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "PAPADIMITRIOU Dimitri" , References: <53CCFDD6E346CB43994852666C210E9101FB483B@esealmw116.eemea.ericsson.se> <014f01c7eb1f$3272db10$0300a8c0@your029b8cecfe> <46D7DDC6.8000205@pi.se> <020501c7f068$270d0c20$0302a8c0@your029b8cecfe> <53CCFDD6E346CB43994852666C210E9102067D40@esealmw116.eemea.ericsson.se> <8144761F31F48D43AD53D09F5350E380012B22ED@FRVELSMBS22.ad2.ad.alcatel.com> <8144761F31F48D43AD53D09F5350E380012B24AF@FRVELSMBS22.ad2.ad.alcatel.com> <039601c7f12d$69406a40$0302a8c0@your029b8cecfe> <8144761F31F48D43AD53D09F5350E380013213D5@FRVELSMBS22.ad2.ad.alcatel.com> Subject: Re: Closing the GELS Mailing List Date: Fri, 7 Sep 2007 19:40:07 +0100 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-OriginalArrivalTime: 07 Sep 2007 18:40:20.0822 (UTC) FILETIME=[8B472F60:01C7F17E] X-Originating-Heisenberg-IP: [88.96.235.138] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Hi Dimitri, >>> beside the fact that there is an assumption on what >>> label means and how it is represented in data plane >> >> This is also something we would expect to describe within >> CCAMP although "what is a label" would come to us from >> the data plane specification. > > do i interpreet correctly your statement that if the specification > that CCAMP is going to receive from IEEE does not speak > about "label" and its encoding there will be no place to discuss > any "label processing" and "label distribution" protocol in IETF > - being domain-wide or link-local I expect the IEEE specification to define the forwarding paradigm. For example: Frames in 802.1Qay are forwarded based on the checksum value carried in the frame. I expect us to build a GMPLS solution that can be used to configure/install that forwarding paradigm. If (for example) the destination MAC is the forwarding trigger, and the destination MAC is also intended to have genuine network-wide scope and identify the recipient of the frame to the whole network, then the label is (by definition) network-scoped. > in that case, isn't the .1Q specification outside scope of this effort > since not referring - as of today at least - to any "label" semantic as > part of the Ethernet frame header information field ? No. That is like saying that TDM and lambda were out of scope for GMPLS because their definitions didn't refer to labels. The point is that a label is the identifier by which traffic on an interface may be identified for forwarding. The data plane spec should indicate what that identifier is, and we call that a label and have to pass it around in signaling. I have no idea whether that means that the .1Q spec is in scope or not. A From owner-ccamp@ops.ietf.org Fri Sep 07 17:39:30 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITlY2-0005NN-QH for ccamp-archive@ietf.org; Fri, 07 Sep 2007 17:39:30 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITlY1-000128-DL for ccamp-archive@ietf.org; Fri, 07 Sep 2007 17:39:30 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITlRk-000Hsh-1c for ccamp-data@psg.com; Fri, 07 Sep 2007 21:33:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.1 Received: from [209.191.85.57] (helo=web36806.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITlRg-000HsO-EQ for ccamp@ops.ietf.org; Fri, 07 Sep 2007 21:32:58 +0000 Received: (qmail 97843 invoked by uid 60001); 7 Sep 2007 21:32:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=bNAjNAxqf7FUYelP/dimqfK8HXLNo05an8IO6UtEJeEaXfZSMl8sS1nCZcg7cdMzpqMuSOw6EZ3Z4WKeYWVLJa17OrTW6FMG18/LH7hmM5BCQjrU7LPdAAq/bZ5DhwaEUgKGBRxZt13BkHlO0fz5tlsBijnhEmS44p1As1Mpixc=; X-YMail-OSG: WUqzARsVM1kwSVO8yG1dREtChMZBXja31zsqeSmZ7JKMeTzI0ROWJSg9yOmA2Qu2xQ6JJZBCc2QPQg8YfweQqh3EFZdghOH4Wtu7ux8HZZXPcilw8srNTwXdVQ-- Received: from [67.102.145.11] by web36806.mail.mud.yahoo.com via HTTP; Fri, 07 Sep 2007 14:32:55 PDT Date: Fri, 7 Sep 2007 14:32:55 -0700 (PDT) From: Igor Bryskin Subject: RE: Closing the GELS Mailing List To: neil.2.harrison@bt.com, Dimitri.Papadimitriou@alcatel-lucent.be, adrian@olddog.co.uk, zali@cisco.com, Attila.Takacs@ericsson.com, ccamp@ops.ietf.org, gels@rtg.ietf.org Cc: rcallon@juniper.net In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C0106EDD5@E03MVB2-UKBR.domain1.systemhost.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2106601530-1189200775=:97472" Content-Transfer-Encoding: 8bit Message-ID: <629295.97472.qm@web36806.mail.mud.yahoo.com> Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 --0-2106601530-1189200775=:97472 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit True, however one can argue that SA is not a label, rather a connection property that the connection ingress knows about and signales downstream (just like bandwidth, for example), while the label is something it does not know yet and needs to get it from downstream so that the downstream node could recognize frames labeled with the label and forward them accordingly. Have a great weekend. Igor neil.2.harrison@bt.com wrote: Message Hi Igor...I understand what you mean...and yes for *forwarding* purposes (on the assumption the requirements of a connection are met) you are right. It is, however, also important for the CP to tell the sink(s) of the connection what SA it expects to appear in the CV OAM pkts and this esp important if the co-ps mode layer network is based on the less optimal label-swapping paradigm. Of course, if we don't use label-swapping as in the case of PBB-TE then the CV function (of correct connectivity verification) appears 'for free' in each/every traffic unit....not just the OAM pkts, which are really only now required to distinguish a quiescent traffic case from a simple broken connection. regards, Neil -----Original Message----- From: Igor Bryskin [mailto:i_bryskin@yahoo.com] Sent: 07 September 2007 20:21 To: Harrison,N,Neil,JCGA1 R; Dimitri.Papadimitriou@alcatel-lucent.be; adrian@olddog.co.uk; zali@cisco.com; Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org Cc: rcallon@juniper.net Subject: RE: Closing the GELS Mailing List Hi Neil, I think there is a difference between a "data plane label" which is a Layer Information (LI) used by a given server layer and a "control plane label", which is a piece of information signaled between adjacent controllers for the purpose of connection provisioning. IMO the former is always a superset of the latter. Let's take, for instance, connection oriented Ethernet. MAC SA is a very important part of the data plane label because it identifies the source of the connection. However, the connection frames are forwarded according to MAC DA/VID, and hence connection ingress node, for example, needs only be signaled with this tuple by the downstream neighbor, hence the control plane label is MAC DA/VID (or just VID, for those who like the idea of the VID cross-connects architecture). So, IMO IEEE should be responsible for the definition of data plane labels, while CCAMP for control plane labels. Cheers, Igor neil.2.harrison@bt.com wrote: Dimitri wrote 07 September 2007 16:36 in response to Adrian > > > > This is also something we would expect to describe within > > CCAMP although > > "what is a label" would come to us from the data plane > specification. > > do i interpreet correctly your statement that if the > specification that CCAMP is going to receive from IEEE does > not speak about "label" and its encoding there will be no > place to discuss any "label processing" and "label > distribution" protocol in IETF - being domain-wide or link-local > - > > in that case, isn't the .1Q specification outside scope of > this effort since not referring - as of today at least - to > any "label" semantic as part of the Ethernet frame header > information field ? > > thanks, > -d. What do you think a MAC DA, MAC SA and VID are? These are all 'labels'. You also have to remember that the nature of the labels required in a traffic unit are determined by the type of the network mode one is dealing with. In the co-cs and co-ps modes we have a construction known as a 'connection'. This implies specific architectural requirements....but the most significant, for this discussion at least, is that a connection must have a single source. What this means is that one does not have to incorporate a SA label in a co mode traffic unit....under defect-free conditions it is redundant information as the connection itself provides the source information. {Compare this to the cl-ps mode which does not have connections...here having a SA in the traffic unit is essential} Ergo why co-cs and co-ps mode technologies to date that respect the requirements of a connection have only focussed on incorporating a DA (forwarding) label. Further, these forwarding labels only need to be distinct in resolving some number (N say) of different client layer (link-connection) instances within a server layer (network connection) resource partition. However, there are advantages from having both a SA and DA label in a co-ps traffic unit that are network unique and not just link-connection unique (ie not swapped)....the inherent robustness under misconnectivity defects (without any adjunct OAM flow) is one of these. And of course, these are the nature of the native labels one already gets in Ethernet due to its cl-ps mode origins. So why would one even contemplate not using these since they are already there? The VID label is slightly different in that one can consider it as a 'route discriminator label' and a local extension to the SA or DA, ie it provides the ability to identify disjoint paths between nodal end points. The mere fact IEEE may not refer to the above quantities as 'labels' does not change the fact that this is what they are. So I'm not clear what your real point is here. regards, Neil --------------------------------- Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when. --------------------------------- Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. --0-2106601530-1189200775=:97472 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit True, however one can argue that SA is not a label, rather a connection property that the connection ingress knows about and signales downstream (just like bandwidth, for example), while the label is something it does not know yet and needs to get it from downstream so that the downstream node could recognize frames labeled with the label and forward them accordingly.

Have a great weekend.
Igor

neil.2.harrison@bt.com wrote:
Message
Hi Igor...I understand what you mean...and yes for *forwarding* purposes (on the assumption the requirements of a connection are met) you are right.  It is, however, also important for the CP to tell the sink(s) of the connection what SA it expects to appear in the CV OAM pkts and this esp important if the co-ps mode layer network is based on the less optimal label-swapping paradigm.  Of course, if we don't use label-swapping as in the case of PBB-TE then the CV function (of correct connectivity verification) appears 'for free' in each/every traffic unit....not just the OAM pkts, which are really only now required to distinguish a quiescent traffic case from a simple broken connection.
 
regards, Neil
-----Original Message-----
From: Igor Bryskin [mailto:i_bryskin@yahoo.com]
Sent: 07 September 2007 20:21
To: Harrison,N,Neil,JCGA1 R; Dimitri.Papadimitriou@alcatel-lucent.be; adrian@olddog.co.uk; zali@cisco.com; Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org
Cc: rcallon@juniper.net
Subject: RE: Closing the GELS Mailing List

Hi Neil,
I think there is a difference between a "data plane label" which is a Layer Information (LI) used by a given server layer and a "control plane label", which is a piece of information signaled between adjacent controllers for the purpose of connection provisioning. IMO the former is always a superset of the latter. Let's take, for instance, connection oriented Ethernet. MAC SA is a very important part of the data plane label because it identifies the source of the connection. However, the connection frames are forwarded according to MAC DA/VID, and hence connection ingress node, for example, needs only be signaled with this tuple by the downstream neighbor, hence the control plane label is MAC DA/VID (or just VID, for those who like the idea of the VID cross-connects architecture).
So, IMO IEEE should be responsible for the definition of data plane labels, while CCAMP for control plane labels.
Cheers,
Igor


neil.2.harrison@bt.com wrote:
Dimitri wrote 07 September 2007 16:36 in response to Adrian

> >
> > This is also something we would expect to describe within
> > CCAMP although
> > "what is a label" would come to us from the data plane
> specification.
>
> do i interpreet correctly your statement that if the
> specification that CCAMP is going to receive from IEEE does
> not speak about "label" and its encoding there will be no
> place to discuss any "label processing" and "label
> distribution" protocol in IETF - being domain-wide or link-local
> -
>
> in that case, isn't the .1Q specification outside scope of
> this effort since not referring - as of today at least - to
> any "label" semantic as part of the Ethernet frame header
> information field ?
>
> thanks,
> -d.

What do you think a MAC DA, MAC SA and VID are? These are all 'labels'.

You also have to remember that the nature of the labels required in a
traffic unit are determined by the type of the network mode one is
dealing with.

In the co-cs and co-ps modes we have a construction known as a
'connection'. This implies specific architectural requirements....but
the most significant, for this discussion at least, is that a connection
must have a single source. What this means is that one does not have to
incorporate a SA label in a co mode traffic unit....under defect-free
conditions it is redundant information as the connection itself provides
the source information. {Compare this to the cl-ps mode which does not
have connections...here having a SA in the traffic unit is essential}

Ergo why co-cs and co-ps mode technologies to date that respect the
requirements of a connection have only focussed on incorporating a DA
(forwarding) label. Further, these forwarding labels only need to be
distinct in resolving some number (N say) of different client layer
(link-connection) instances within a server layer (network connection)
resource partition. However, there are advantages from having both a SA
and DA label in a co-ps traffic unit that are network unique and not
just link-connection unique (ie not swapped)....the inherent robustness
under misconnectivity defects (without any adjunct OAM flow) is one of
these. And of course, these are the nature of the native labels one
already gets in Ethernet due to its cl-ps mode origins. So why would
one even contemplate not using these since they are already there?

The VID label is slightly different in that one can consider it as a
'route discriminator label' and a local extension to the SA or DA, ie it
provides the ability to identify disjoint paths between nodal end
points.

The mere fact IEEE may not refer to the above quantities as 'labels'
does not change the fact that this is what they are. So I'm not clear
what your real point is here.

regards, Neil



Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when.


Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. --0-2106601530-1189200775=:97472-- From owner-ccamp@ops.ietf.org Fri Sep 07 17:48:30 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITlgk-0005xE-KC for ccamp-archive@ietf.org; Fri, 07 Sep 2007 17:48:30 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITlgi-0001LZ-Vr for ccamp-archive@ietf.org; Fri, 07 Sep 2007 17:48:30 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITlbA-000Ix4-HP for ccamp-data@psg.com; Fri, 07 Sep 2007 21:42:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [217.32.164.138] (helo=smtp3.smtp.bt.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITlb6-000Ito-C3 for ccamp@ops.ietf.org; Fri, 07 Sep 2007 21:42:42 +0000 Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 22:42:39 +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_01C7F198.02B4D2B3" Subject: RE: Closing the GELS Mailing List Date: Fri, 7 Sep 2007 22:42:27 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C0106EDE0@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <629295.97472.qm@web36806.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing the GELS Mailing List Thread-Index: AcfxlqknD8rstOxnQgqub0LmpWd5LgAAFLWw From: To: , , , , , , Cc: X-OriginalArrivalTime: 07 Sep 2007 21:42:39.0203 (UTC) FILETIME=[030FAB30:01C7F198] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4ec3642ae9025e273a4a263d640f3300 This is a multi-part message in MIME format. ------_=_NextPart_001_01C7F198.02B4D2B3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Igor, I'd disagree with you for the reasons I attempted to explain to Dimitri, ie depends on the network mode....in the cl-ps mode the SA *label* is pretty important. The only reason we have usually not traditionally incorporated a SA label in co mode network traffic units is that, under misconnectivity defect-free conditions, it is redundant information...the connection itself provides that information. However, there are important benefits to be had from having a SA in each/every traffic unit, and if these are already there 'for free' then it would be sheer folly not to recognise them for what they are and use them. =20 regards, Neil...have great weekend yourself, I'm signing off now. -----Original Message----- From: Igor Bryskin [mailto:i_bryskin@yahoo.com]=20 Sent: 07 September 2007 22:33 To: Harrison,N,Neil,JCGA1 R; Dimitri.Papadimitriou@alcatel-lucent.be; adrian@olddog.co.uk; zali@cisco.com; Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org Cc: rcallon@juniper.net Subject: RE: Closing the GELS Mailing List True, however one can argue that SA is not a label, rather a connection property that the connection ingress knows about and signales downstream (just like bandwidth, for example), while the label is something it does not know yet and needs to get it from downstream so that the downstream node could recognize frames labeled with the label and forward them accordingly. Have a great weekend. Igor neil.2.harrison@bt.com wrote:=20 Hi Igor...I understand what you mean...and yes for *forwarding* purposes (on the assumption the requirements of a connection are met) you are right. It is, however, also important for the CP to tell the sink(s) of the connection what SA it expects to appear in the CV OAM pkts and this esp important if the co-ps mode layer network is based on the less optimal label-swapping paradigm. Of course, if we don't use label-swapping as in the case of PBB-TE then the CV function (of correct connectivity verification) appears 'for free' in each/every traffic unit....not just the OAM pkts, which are really only now required to distinguish a quiescent traffic case from a simple broken connection. =20 regards, Neil -----Original Message----- From: Igor Bryskin [mailto:i_bryskin@yahoo.com]=20 Sent: 07 September 2007 20:21 To: Harrison,N,Neil,JCGA1 R; Dimitri.Papadimitriou@alcatel-lucent.be; adrian@olddog.co.uk; zali@cisco.com; Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org Cc: rcallon@juniper.net Subject: RE: Closing the GELS Mailing List Hi Neil, I think there is a difference between a "data plane label" which is a Layer Information (LI) used by a given server layer and a "control plane label", which is a piece of information signaled between adjacent controllers for the purpose of connection provisioning. IMO the former is always a superset of the latter. Let's take, for instance, connection oriented Ethernet. MAC SA is a very important part of the data plane label because it identifies the source of the connection. However, the connection frames are forwarded according to MAC DA/VID, and hence connection ingress node, for example, needs only be signaled with this tuple by the downstream neighbor, hence the control plane label is MAC DA/VID (or just VID, for those who like the idea of the VID cross-connects architecture). So, IMO IEEE should be responsible for the definition of data plane labels, while CCAMP for control plane labels. Cheers, Igor=20 neil.2.harrison@bt.com wrote:=20 Dimitri wrote 07 September 2007 16:36 in response to Adrian=20 > >=20 > > This is also something we would expect to describe within > > CCAMP although=20 > > "what is a label" would come to us from the data plane=20 > specification. >=20 > do i interpreet correctly your statement that if the=20 > specification that CCAMP is going to receive from IEEE does=20 > not speak about "label" and its encoding there will be no=20 > place to discuss any "label processing" and "label=20 > distribution" protocol in IETF - being domain-wide or link-local > - >=20 > in that case, isn't the .1Q specification outside scope of=20 > this effort since not referring - as of today at least - to=20 > any "label" semantic as part of the Ethernet frame header=20 > information field ? >=20 > thanks, > -d. What do you think a MAC DA, MAC SA and VID are? These are all 'labels'. You also have to remember that the nature of the labels required in a traffic unit are determined by the type of the network mode one is dealing with. In the co-cs and co-ps modes we have a construction known as a 'connection'. This implies specific architectural requirements....but the most significant, for this discussion at least, is that a connection must have a single source. What this means is that one does not have to incorporate a SA label in a co mode traffic unit....under defect-free conditions it is redundant information as the connection itself provides the source information. {Compare this to the cl-ps mode which does not have connections...here having a SA in the traffic unit is essential} Ergo why co-cs and co-ps mode technologies to date that respect the requirements of a connection have only focussed on incorporating a DA (forwarding) label. Further, these forwarding labels only need to be distinct in resolving some number (N say) of different client layer (link-connection) instances within a server layer (network connection) resource partition. However, there are advantages from having both a SA and DA label in a co-ps traffic unit that are network unique and not just link-connection unique (ie not swapped)....the inherent robustness under misconnectivity defects (without any adjunct OAM flow) is one of these. And of course, these are the nature of the native labels one already gets in Ethernet due to its cl-ps mode origins. So why would one even contemplate not using these since they are already there? The VID label is slightly different in that one can consider it as a 'route discriminator label' and a local extension to the SA or DA, ie it provides the ability to identify disjoint paths between nodal end points. The mere fact IEEE may not refer to the above quantities as 'labels' does not change the fact that this is what they are. So I'm not clear what your real point is here. regards, Neil _____ =20 Sick sense of humor? Visit Yahoo! TV's Comedy = with an Edge to see what's on, when.=20 _____ =20 Yahoo! oneSearch: Finally, mobile search that gives answers, not web links.=20 ------_=_NextPart_001_01C7F198.02B4D2B3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi Igor, I'd disagree with you for the reasons I attempted to = explain to=20 Dimitri, ie depends on the network mode....in the cl-ps mode the SA = *label* is=20 pretty important.  The only reason we have usually not = traditionally=20 incorporated a SA label in co mode network traffic units is that, under=20 misconnectivity defect-free conditions, it is redundant = information...the=20 connection itself provides that information.  However, there are = important=20 benefits to be had from having a SA in each/every traffic unit, and if = these are=20 already there 'for free' then it would be sheer folly not to recognise = them for=20 what they are and use them.
 
regards, Neil...have great weekend yourself, I'm signing off=20 now.
-----Original Message-----
From: Igor = Bryskin=20 [mailto:i_bryskin@yahoo.com]
Sent: 07 September 2007=20 22:33
To: Harrison,N,Neil,JCGA1 R;=20 Dimitri.Papadimitriou@alcatel-lucent.be; adrian@olddog.co.uk; = zali@cisco.com;=20 Attila.Takacs@ericsson.com; ccamp@ops.ietf.org;=20 gels@rtg.ietf.org
Cc: rcallon@juniper.net
Subject: = RE:=20 Closing the GELS Mailing List

True, however one = can argue=20 that SA is not a label, rather a connection property that the = connection=20 ingress knows about and signales downstream (just like bandwidth, for=20 example), while the label is something it does not know yet and needs = to get=20 it from downstream so that the downstream node could recognize frames = labeled=20 with the label and forward them accordingly.

Have a great=20 weekend.
Igor

neil.2.harrison@bt.com wrote:
Hi Igor...I understand what you mean...and yes for = *forwarding*=20 purposes (on the assumption the requirements of a connection are = met) you=20 are right.  It is, however, also important for the CP to tell = the=20 sink(s) of the connection what SA it expects to appear in the CV OAM = pkts=20 and this esp important if the co-ps mode layer network is based on = the less=20 optimal label-swapping paradigm.  Of course, if we don't use=20 label-swapping as in the case of PBB-TE then the CV function (of = correct=20 connectivity verification) appears 'for free' in each/every traffic=20 unit....not just the OAM pkts, which are really only now required to = distinguish a quiescent traffic case from a simple broken=20 connection.
 
regards, Neil
-----Original Message-----
From: = Igor Bryskin=20 [mailto:i_bryskin@yahoo.com]
Sent: 07 September 2007=20 20:21
To: Harrison,N,Neil,JCGA1 R;=20 Dimitri.Papadimitriou@alcatel-lucent.be; adrian@olddog.co.uk;=20 zali@cisco.com; Attila.Takacs@ericsson.com; ccamp@ops.ietf.org;=20 gels@rtg.ietf.org
Cc: = rcallon@juniper.net
Subject: RE:=20 Closing the GELS Mailing List

Hi Neil,
I think there is a difference between a = "data=20 plane label" which is a Layer Information (LI) used by a given = server=20 layer and a "control plane label", which is a piece of information = signaled between adjacent controllers for the purpose of = connection=20 provisioning. IMO the former is always a superset of the latter. = Let's=20 take, for instance, connection oriented Ethernet. MAC SA is a very = important part of the data plane label because it identifies the = source of=20 the connection. However, the connection frames are forwarded = according to=20 MAC DA/VID, and hence connection ingress node, for example, needs = only be=20 signaled with this tuple by the downstream neighbor, hence the = control=20 plane label is MAC DA/VID (or just VID, for those who like the = idea of the=20 VID cross-connects architecture).
So, IMO IEEE should be responsible for = the=20 definition of data plane labels, while CCAMP for control plane=20 labels.
Cheers,
Igor=20


neil.2.harrison@bt.com = wrote:=20
Dimitri=20 wrote 07 September 2007 16:36 in response to Adrian=20

> >
> > This is also something = we would=20 expect to describe within
> > CCAMP although
> = >=20 "what is a label" would come to us from the data plane
>=20 specification.
>
> do i interpreet correctly your = statement=20 that if the
> specification that CCAMP is going to = receive from=20 IEEE does
> not speak about "label" and its encoding = there will=20 be no
> place to discuss any "label processing" and = "label=20
> distribution" protocol in IETF - being domain-wide or=20 link-local
> -
>
> in that case, isn't the = .1Q=20 specification outside scope of
> this effort since not = referring=20 - as of today at least - to
> any "label" semantic as = part of the=20 Ethernet frame header
> information field ?
> =
>=20 thanks,
> -d.

What do you think a MAC DA, MAC SA = and VID=20 are? These are all 'labels'.

You also have to remember = that the=20 nature of the labels required in a
traffic unit are = determined by the=20 type of the network mode one is
dealing with.

In the = co-cs and=20 co-ps modes we have a construction known as a
'connection'. = This=20 implies specific architectural requirements....but
the most=20 significant, for this discussion at least, is that a = connection
must=20 have a single source. What this means is that one does not have=20 to
incorporate a SA label in a co mode traffic unit....under=20 defect-free
conditions it is redundant information as the = connection=20 itself provides
the source information. {Compare this to the = cl-ps=20 mode which does not
have connections...here having a SA in = the=20 traffic unit is essential}

Ergo why co-cs and co-ps mode=20 technologies to date that respect the
requirements of a = connection=20 have only focussed on incorporating a DA
(forwarding) label. = Further,=20 these forwarding labels only need to be
distinct in resolving = some=20 number (N say) of different client layer
(link-connection) = instances=20 within a server layer (network connection)
resource = partition.=20 However, there are advantages from having both a SA
and DA = label in a=20 co-ps traffic unit that are network unique and not
just=20 link-connection unique (ie not swapped)....the inherent=20 robustness
under misconnectivity defects (without any adjunct = OAM=20 flow) is one of
these. And of course, these are the nature of = the=20 native labels one
already gets in Ethernet due to its cl-ps = mode=20 origins. So why would
one even contemplate not using these = since they=20 are already there?

The VID label is slightly different in = that=20 one can consider it as a
'route discriminator label' and a = local=20 extension to the SA or DA, ie it
provides the ability to = identify=20 disjoint paths between nodal end
points.

The mere fact = IEEE=20 may not refer to the above quantities as 'labels'
does not = change the=20 fact that this is what they are. So I'm not clear
what your = real=20 point is here.

regards, = Neil



Sick sense of humor? Visit Yahoo! TV's Comedy=20 with an Edge to see what's on, when. =


Yahoo! oneSearch: Finally, mobile=20 search that gives answers, not web links. = ------_=_NextPart_001_01C7F198.02B4D2B3-- From owner-ccamp@ops.ietf.org Fri Sep 07 18:08:08 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITlzk-0000DO-55 for ccamp-archive@ietf.org; Fri, 07 Sep 2007 18:08:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITlzh-0005jR-AS for ccamp-archive@ietf.org; Fri, 07 Sep 2007 18:08:08 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITlqg-000KjZ-NI for ccamp-data@psg.com; Fri, 07 Sep 2007 21:58:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.1 Received: from [209.191.85.53] (helo=web36802.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITlqc-000Khq-UC for ccamp@ops.ietf.org; Fri, 07 Sep 2007 21:58:44 +0000 Received: (qmail 36392 invoked by uid 60001); 7 Sep 2007 21:58:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=NI6v1U2c0lMJxzf/VLSFlED/8B0KiBag29kv7+9TxayHt3tVJoVNHT0f2WyrP7XH1rcJB1MYrT8qJDxvnkD8YnPSXm93hzHvrlKI5d1yqVGtF5Z54ngMh79wa4Ee5pKjWuEQajiG2a2QWrsw7B5eOK2B+8rrd/AbkQZxnd3n/6g=; X-YMail-OSG: OX5hRGUVM1n1ug6Ju4Glrkt3NnWPajQzClC.WJ8pfKB89UNy3WRo1nWa6__YPCq9r.qMs8loKw.gakBSsDPboKel9qyPd_XXujb4QlDsq3KNh9BePChM8v.leQ-- Received: from [67.102.145.11] by web36802.mail.mud.yahoo.com via HTTP; Fri, 07 Sep 2007 14:58:42 PDT Date: Fri, 7 Sep 2007 14:58:42 -0700 (PDT) From: Igor Bryskin Subject: RE: Closing the GELS Mailing List To: neil.2.harrison@bt.com, Dimitri.Papadimitriou@alcatel-lucent.be, adrian@olddog.co.uk, zali@cisco.com, Attila.Takacs@ericsson.com, ccamp@ops.ietf.org, gels@rtg.ietf.org Cc: rcallon@juniper.net In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C0106EDE0@E03MVB2-UKBR.domain1.systemhost.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-303205946-1189202322=:36343" Content-Transfer-Encoding: 8bit Message-ID: <93117.36343.qm@web36802.mail.mud.yahoo.com> Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 --0-303205946-1189202322=:36343 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I fully understand what are saying and I think we are in agreement here: I am not saying that SA is unimportant, quite on the contrary. What I am saying is that SA is not a label in the CP signaling sense, rather, it is a property that is signaled in the opposite direction compared to one the label is signaled (like bandwidth, link affinities, etc.) Igor neil.2.harrison@bt.com wrote: Message Hi Igor, I'd disagree with you for the reasons I attempted to explain to Dimitri, ie depends on the network mode....in the cl-ps mode the SA *label* is pretty important. The only reason we have usually not traditionally incorporated a SA label in co mode network traffic units is that, under misconnectivity defect-free conditions, it is redundant information...the connection itself provides that information. However, there are important benefits to be had from having a SA in each/every traffic unit, and if these are already there 'for free' then it would be sheer folly not to recognise them for what they are and use them. regards, Neil...have great weekend yourself, I'm signing off now. -----Original Message----- From: Igor Bryskin [mailto:i_bryskin@yahoo.com] Sent: 07 September 2007 22:33 To: Harrison,N,Neil,JCGA1 R; Dimitri.Papadimitriou@alcatel-lucent.be; adrian@olddog.co.uk; zali@cisco.com; Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org Cc: rcallon@juniper.net Subject: RE: Closing the GELS Mailing List True, however one can argue that SA is not a label, rather a connection property that the connection ingress knows about and signales downstream (just like bandwidth, for example), while the label is something it does not know yet and needs to get it from downstream so that the downstream node could recognize frames labeled with the label and forward them accordingly. Have a great weekend. Igor neil.2.harrison@bt.com wrote: Hi Igor...I understand what you mean...and yes for *forwarding* purposes (on the assumption the requirements of a connection are met) you are right. It is, however, also important for the CP to tell the sink(s) of the connection what SA it expects to appear in the CV OAM pkts and this esp important if the co-ps mode layer network is based on the less optimal label-swapping paradigm. Of course, if we don't use label-swapping as in the case of PBB-TE then the CV function (of correct connectivity verification) appears 'for free' in each/every traffic unit....not just the OAM pkts, which are really only now required to distinguish a quiescent traffic case from a simple broken connection. regards, Neil -----Original Message----- From: Igor Bryskin [mailto:i_bryskin@yahoo.com] Sent: 07 September 2007 20:21 To: Harrison,N,Neil,JCGA1 R; Dimitri.Papadimitriou@alcatel-lucent.be; adrian@olddog.co.uk; zali@cisco.com; Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org Cc: rcallon@juniper.net Subject: RE: Closing the GELS Mailing List Hi Neil, I think there is a difference between a "data plane label" which is a Layer Information (LI) used by a given server layer and a "control plane label", which is a piece of information signaled between adjacent controllers for the purpose of connection provisioning. IMO the former is always a superset of the latter. Let's take, for instance, connection oriented Ethernet. MAC SA is a very important part of the data plane label because it identifies the source of the connection. However, the connection frames are forwarded according to MAC DA/VID, and hence connection ingress node, for example, needs only be signaled with this tuple by the downstream neighbor, hence the control plane label is MAC DA/VID (or just VID, for those who like the idea of the VID cross-connects architecture). So, IMO IEEE should be responsible for the definition of data plane labels, while CCAMP for control plane labels. Cheers, Igor neil.2.harrison@bt.com wrote: Dimitri wrote 07 September 2007 16:36 in response to Adrian > > > > This is also something we would expect to describe within > > CCAMP although > > "what is a label" would come to us from the data plane > specification. > > do i interpreet correctly your statement that if the > specification that CCAMP is going to receive from IEEE does > not speak about "label" and its encoding there will be no > place to discuss any "label processing" and "label > distribution" protocol in IETF - being domain-wide or link-local > - > > in that case, isn't the .1Q specification outside scope of > this effort since not referring - as of today at least - to > any "label" semantic as part of the Ethernet frame header > information field ? > > thanks, > -d. What do you think a MAC DA, MAC SA and VID are? These are all 'labels'. You also have to remember that the nature of the labels required in a traffic unit are determined by the type of the network mode one is dealing with. In the co-cs and co-ps modes we have a construction known as a 'connection'. This implies specific architectural requirements....but the most significant, for this discussion at least, is that a connection must have a single source. What this means is that one does not have to incorporate a SA label in a co mode traffic unit....under defect-free conditions it is redundant information as the connection itself provides the source information. {Compare this to the cl-ps mode which does not have connections...here having a SA in the traffic unit is essential} Ergo why co-cs and co-ps mode technologies to date that respect the requirements of a connection have only focussed on incorporating a DA (forwarding) label. Further, these forwarding labels only need to be distinct in resolving some number (N say) of different client layer (link-connection) instances within a server layer (network connection) resource partition. However, there are advantages from having both a SA and DA label in a co-ps traffic unit that are network unique and not just link-connection unique (ie not swapped)....the inherent robustness under misconnectivity defects (without any adjunct OAM flow) is one of these. And of course, these are the nature of the native labels one already gets in Ethernet due to its cl-ps mode origins. So why would one even contemplate not using these since they are already there? The VID label is slightly different in that one can consider it as a 'route discriminator label' and a local extension to the SA or DA, ie it provides the ability to identify disjoint paths between nodal end points. The mere fact IEEE may not refer to the above quantities as 'labels' does not change the fact that this is what they are. So I'm not clear what your real point is here. regards, Neil --------------------------------- Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when. --------------------------------- Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. --------------------------------- Shape Yahoo! in your own image. Join our Network Research Panel today! --0-303205946-1189202322=:36343 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I fully understand what are saying and I think we are in agreement here: I am not saying that SA is unimportant, quite on the contrary. What I am saying is that SA is not a label in the CP signaling sense, rather, it is a property that is signaled in the opposite direction compared to one the label is signaled (like bandwidth, link affinities, etc.)

Igor

neil.2.harrison@bt.com wrote:
Message
Hi Igor, I'd disagree with you for the reasons I attempted to explain to Dimitri, ie depends on the network mode....in the cl-ps mode the SA *label* is pretty important.  The only reason we have usually not traditionally incorporated a SA label in co mode network traffic units is that, under misconnectivity defect-free conditions, it is redundant information...the connection itself provides that information.  However, there are important benefits to be had from having a SA in each/every traffic unit, and if these are already there 'for free' then it would be sheer folly not to recognise them for what they are and use them.
 
regards, Neil...have great weekend yourself, I'm signing off now.
-----Original Message-----
From: Igor Bryskin [mailto:i_bryskin@yahoo.com]
Sent: 07 September 2007 22:33
To: Harrison,N,Neil,JCGA1 R; Dimitri.Papadimitriou@alcatel-lucent.be; adrian@olddog.co.uk; zali@cisco.com; Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org
Cc: rcallon@juniper.net
Subject: RE: Closing the GELS Mailing List

True, however one can argue that SA is not a label, rather a connection property that the connection ingress knows about and signales downstream (just like bandwidth, for example), while the label is something it does not know yet and needs to get it from downstream so that the downstream node could recognize frames labeled with the label and forward them accordingly.

Have a great weekend.
Igor

neil.2.harrison@bt.com wrote:
Hi Igor...I understand what you mean...and yes for *forwarding* purposes (on the assumption the requirements of a connection are met) you are right.  It is, however, also important for the CP to tell the sink(s) of the connection what SA it expects to appear in the CV OAM pkts and this esp important if the co-ps mode layer network is based on the less optimal label-swapping paradigm.  Of course, if we don't use label-swapping as in the case of PBB-TE then the CV function (of correct connectivity verification) appears 'for free' in each/every traffic unit....not just the OAM pkts, which are really only now required to distinguish a quiescent traffic case from a simple broken connection.
 
regards, Neil
-----Original Message-----
From: Igor Bryskin [mailto:i_bryskin@yahoo.com]
Sent: 07 September 2007 20:21
To: Harrison,N,Neil,JCGA1 R; Dimitri.Papadimitriou@alcatel-lucent.be; adrian@olddog.co.uk; zali@cisco.com; Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org
Cc: rcallon@juniper.net
Subject: RE: Closing the GELS Mailing List

Hi Neil,
I think there is a difference between a "data plane label" which is a Layer Information (LI) used by a given server layer and a "control plane label", which is a piece of information signaled between adjacent controllers for the purpose of connection provisioning. IMO the former is always a superset of the latter. Let's take, for instance, connection oriented Ethernet. MAC SA is a very important part of the data plane label because it identifies the source of the connection. However, the connection frames are forwarded according to MAC DA/VID, and hence connection ingress node, for example, needs only be signaled with this tuple by the downstream neighbor, hence the control plane label is MAC DA/VID (or just VID, for those who like the idea of the VID cross-connects architecture).
So, IMO IEEE should be responsible for the definition of data plane labels, while CCAMP for control plane labels.
Cheers,
Igor


neil.2.harrison@bt.com wrote:
Dimitri wrote 07 September 2007 16:36 in response to Adrian

> >
> > This is also something we would expect to describe within
> > CCAMP although
> > "what is a label" would come to us from the data plane
> specification.
>
> do i interpreet correctly your statement that if the
> specification that CCAMP is going to receive from IEEE does
> not speak about "label" and its encoding there will be no
> place to discuss any "label processing" and "label
> distribution" protocol in IETF - being domain-wide or link-local
> -
>
> in that case, isn't the .1Q specification outside scope of
> this effort since not referring - as of today at least - to
> any "label" semantic as part of the Ethernet frame header
> information field ?
>
> thanks,
> -d.

What do you think a MAC DA, MAC SA and VID are? These are all 'labels'.

You also have to remember that the nature of the labels required in a
traffic unit are determined by the type of the network mode one is
dealing with.

In the co-cs and co-ps modes we have a construction known as a
'connection'. This implies specific architectural requirements....but
the most significant, for this discussion at least, is that a connection
must have a single source. What this means is that one does not have to
incorporate a SA label in a co mode traffic unit....under defect-free
conditions it is redundant information as the connection itself provides
the source information. {Compare this to the cl-ps mode which does not
have connections...here having a SA in the traffic unit is essential}

Ergo why co-cs and co-ps mode technologies to date that respect the
requirements of a connection have only focussed on incorporating a DA
(forwarding) label. Further, these forwarding labels only need to be
distinct in resolving some number (N say) of different client layer
(link-connection) instances within a server layer (network connection)
resource partition. However, there are advantages from having both a SA
and DA label in a co-ps traffic unit that are network unique and not
just link-connection unique (ie not swapped)....the inherent robustness
under misconnectivity defects (without any adjunct OAM flow) is one of
these. And of course, these are the nature of the native labels one
already gets in Ethernet due to its cl-ps mode origins. So why would
one even contemplate not using these since they are already there?

The VID label is slightly different in that one can consider it as a
'route discriminator label' and a local extension to the SA or DA, ie it
provides the ability to identify disjoint paths between nodal end
points.

The mere fact IEEE may not refer to the above quantities as 'labels'
does not change the fact that this is what they are. So I'm not clear
what your real point is here.

regards, Neil



Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when.


Yahoo! oneSearch: Finally, mobile search that gives answers, not web links.


Shape Yahoo! in your own image. Join our Network Research Panel today! --0-303205946-1189202322=:36343-- From ljm@cinablog.com Fri Sep 07 22:35:51 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITqAp-0004ls-65; Fri, 07 Sep 2007 22:35:51 -0400 Received: from [121.148.59.3] (helo=[121.148.59.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITqAo-0000h9-NJ; Fri, 07 Sep 2007 22:35:51 -0400 Received: from [121.148.59.3] by mx1.biz.mail.yahoo.com; Sat, 8 Sep 2007 11:35:47 +0900 Message-ID: <01c7f1c0$f65bba90$033b9479@ljm> From: "Maryann Fair" To: Subject: you have nothing to lose, just a lot to gain! Date: Sat, 8 Sep 2007 11:35:47 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250" 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.9 (++++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 MegaDik will increase the capacity limit of the Corpora Cavernosa http://palcheo.com From owner-ccamp@ops.ietf.org Fri Sep 07 22:47:19 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITqLv-0006W5-2R for ccamp-archive@ietf.org; Fri, 07 Sep 2007 22:47:19 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITqLu-0000vj-JL for ccamp-archive@ietf.org; Fri, 07 Sep 2007 22:47:18 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITqCf-0000X9-RF for ccamp-data@psg.com; Sat, 08 Sep 2007 02:37:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [212.23.3.27] (helo=doppler.zen.co.uk) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITqCc-0000Tn-PP for ccamp@ops.ietf.org; Sat, 08 Sep 2007 02:37:44 +0000 Received: from [212.23.3.140] (helo=pythagoras.zen.co.uk) by doppler.zen.co.uk with esmtp (Exim 4.50) id 1ITltJ-0001w9-DU for ccamp@ops.ietf.org; Fri, 07 Sep 2007 22:01:29 +0000 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1ITltI-0007bf-2Z for ccamp@ops.ietf.org; Fri, 07 Sep 2007 22:01:28 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Sep 2007 23:01:27 +0100 Message-ID: <067401c7f19a$a0755490$0302a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: liaison to IETF (ccamp, MPLS, BFD, PWE3, and L3VPN) on MFA Forum MPLS ICI Date: Fri, 7 Sep 2007 22:57:09 +0100 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-OriginalArrivalTime: 07 Sep 2007 22:01:27.0537 (UTC) FILETIME=[A399C610:01C7F19A] X-Originating-Pythagoras-IP: [88.96.235.138] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Hi, Here is another liaison from the MFA Forum. This one asks for our review of a new specification, but gives no deadline for the review. See the liaison and the specification at www.olddog.co.uk/ccamp.htm Cheers, Adrian ----- Original Message ----- From: "J. Rao Cherukuri" To: ; ; ; ; ; "Ronald Bonica" ; "Stewart Bryant (stbryant)" ; ; ; ; "George Swallow (swallow)" ; "Loa Andersson" Cc: "Ross Callon" ; ; ; "David Sinicrope (RL/TNT)" ; ; "Bocci, Matthew (Matthew)" ; "J. Rao Cherukuri" ; Sent: Friday, September 07, 2007 1:28 AM Subject: liaison to IETF (ccamp, MPLS, BFD, PWE3, and L3VPN) on MFA Forum MPLS ICI Dear All, The MFA Forum is currently working on an MPLS Inter-Carrier Interconnect (MPLS-ICI) specification to support IP VPNs, MPLS Pseudo Wires, Data Trunks, and VoIP. This specification is being driven by the MFA Forum service provider members. The objective of this Technical Specification is to enable a set of MPLS services, across administrative domains operated by different carriers. The MPLS ICI is a bi-directional IP-MPLS logical link between an Autonomous System Border Router (ASBR) in one service provider network and an ASBR in another service provider network. This document is targeted to equipment vendors to specify the necessary ASBR requirements and to service providers to provide guidance on how to use these capabilities. This document uses protocols developed in appropriate standard bodies (e.g., IETF, ITU) where applicable. This document is in our first level ballot procedure. Please review and provide comments. Thank you for your consideration of this matter. Cordially, David Sinicrope, A&D Chair, MFA Forum Rao Cherukuri Chairman, MFA Forum Technical Committee (draft MPLS ICI) From Nam@mt-company.net Sat Sep 08 00:36:20 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITs3Q-0000pH-GS for ccamp-archive@ietf.org; Sat, 08 Sep 2007 00:36:20 -0400 Received: from [200.220.218.39] (helo=[200.220.218.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITs3O-0002hV-N1 for ccamp-archive@ietf.org; Sat, 08 Sep 2007 00:36:20 -0400 Received: by 10.32.2.135 with SMTP id DytscEggIeaDI; Sat, 8 Sep 2007 01:36:19 -0300 (GMT) Received: by 192.168.183.109 with SMTP id htwbgQHAEWAJWc.8868350569402; Sat, 8 Sep 2007 01:36:17 -0300 (GMT) Message-ID: <000d01c7f1d1$ca55d4b0$27dadcc8@usuariod> From: "Nam Madore" To: Subject: novatric Date: Sat, 8 Sep 2007 01:36:14 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C7F1B8.A5089CB0" 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f ------=_NextPart_000_0004_01C7F1B8.A5089CB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://haofir.com/ Wazzup ccamp-archive When I looked in the mirror after every shower, I couldn=92t help but = wonder whether or not I was average. After doing some research online, I = realized that I was under-average =3D ( mitricoaia eberle ------=_NextPart_000_0004_01C7F1B8.A5089CB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://haofir.com/
Wazzup ccamp-archive
When I looked in the mirror after every = shower, I=20 couldn=92t help but wonder whether or not I was average. After doing = some research=20 online, I realized that I was under-average =3D (
mitricoaia eberle
------=_NextPart_000_0004_01C7F1B8.A5089CB0-- From owner-ccamp@ops.ietf.org Sat Sep 08 04:15:04 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITvT5-0005uU-Mr for ccamp-archive@ietf.org; Sat, 08 Sep 2007 04:15:04 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITvT4-0002gY-Cu for ccamp-archive@ietf.org; Sat, 08 Sep 2007 04:15:03 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITvHS-000B8W-Im for ccamp-data@psg.com; Sat, 08 Sep 2007 08:03:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [62.23.212.7] (helo=smail6.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITvHP-000B86-DN for ccamp@ops.ietf.org; Sat, 08 Sep 2007 08:03:01 +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 l8882KZI029670; Sat, 8 Sep 2007 10:02:20 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Sat, 8 Sep 2007 10:02:50 +0200 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: Closing the GELS Mailing List Date: Sat, 8 Sep 2007 10:02:44 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E3800132149A@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <150025.59428.qm@web36811.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing the GELS Mailing List thread-index: AcfxhFFC5MDKHllkRmqpnDUfKCOC6AACP26g References: <2ECAA42C79676B42AEBAC11229CA7D0C0106EDCA@E03MVB2-UKBR.domain1.systemhost.net> <150025.59428.qm@web36811.mail.mud.yahoo.com> From: "PAPADIMITRIOU Dimitri" To: "Igor Bryskin" , , , , , , Cc: X-OriginalArrivalTime: 08 Sep 2007 08:02:50.0797 (UTC) FILETIME=[A6E64DD0:01C7F1EE] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 igor, > So, IMO IEEE should be responsible for the definition of data=20 > plane labels, while CCAMP for control plane labels. a label distribution protocol is a set of procedures by which one node informs another of the label/FEC bindings it has made if these labels are distributed via the gmpls control plane driving population of the LIBs to which difference are u pointing out here ? so, not sure to see the point (whatever the number of levels of indirection between the fwd'ing plane encoding and control plane encoding u will always fall back on the former, the label distribution protocol exchanges a piece of information used by the nodes to perform their forwarding decision)=20 -d. > -----Original Message----- > From: Igor Bryskin [mailto:i_bryskin@yahoo.com]=20 > Sent: Friday, September 07, 2007 9:21 PM > To: neil.2.harrison@bt.com; PAPADIMITRIOU Dimitri;=20 > adrian@olddog.co.uk; zali@cisco.com;=20 > Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org > Cc: rcallon@juniper.net > Subject: RE: Closing the GELS Mailing List >=20 > Hi Neil, > =20 > I think there is a difference between a "data plane label"=20 > which is a Layer Information (LI) used by a given server=20 > layer and a "control plane label", which is a piece of=20 > information signaled between adjacent controllers for the=20 > purpose of connection provisioning. IMO the former is always=20 > a superset of the latter. Let's take, for instance,=20 > connection oriented Ethernet. MAC SA is a very important part=20 > of the data plane label because it identifies the source of=20 > the connection. However, the connection frames are forwarded=20 > according to MAC DA/VID, and hence connection ingress node,=20 > for example, needs only be signaled with this tuple by the=20 > downstream neighbor, hence the control plane label is MAC=20 > DA/VID (or just VID, for those who like the idea of the VID=20 > cross-connects architecture). > =20 > So, IMO IEEE should be responsible for the definition of data=20 > plane labels, while CCAMP for control plane labels. > =20 > Cheers, > Igor=20 >=20 >=20 > neil.2.harrison@bt.com wrote: >=20 > Dimitri wrote 07 September 2007 16:36 in response to Adrian=20 > =09 > > >=20 > > > This is also something we would expect to describe within > > > CCAMP although=20 > > > "what is a label" would come to us from the data plane=20 > > specification. > >=20 > > do i interpreet correctly your statement that if the=20 > > specification that CCAMP is going to receive from IEEE does=20 > > not speak about "label" and its encoding there will be no=20 > > place to discuss any "label processing" and "label=20 > > distribution" protocol in IETF - being domain-wide or=20 > link-local > > - > >=20 > > in that case, isn't the .1Q specification outside scope of=20 > > this effort since not referring - as of today at least - to=20 > > any "label" semantic as part of the Ethernet frame header=20 > > information field ? > >=20 > > thanks, > > -d. > =09 > What do you think a MAC DA, MAC SA and VID are? These=20 > are all 'labels'. > =09 > You also have to remember that the nature of the labels=20 > required in a > traffic unit are determined by the type of the network=20 > mode one is > dealing with. > =09 > In the co-cs and co-ps modes we have a construction known as a > 'connection'. This implies specific architectural=20 > requirements....but > the most significant, for this discussion at least, is=20 > that a connection > must have a single source. What this means is that one=20 > does not have to > incorporate a SA label in a co mode traffic=20 > unit....under defect-free > conditions it is redundant information as the=20 > connection itself provides > the source information. {Compare this to the cl-ps mode=20 > which does not > have connections...here having a SA in the traffic unit=20 > is essential} > =09 > Ergo why co-cs and co-ps mode technologies to date that=20 > respect the > requirements of a connection have only focussed on=20 > incorporating a DA > (forwarding) label. Further, these forwarding labels=20 > only need to be > distinct in resolving some number (N say) of different=20 > client layer > (link-connection) instances within a server layer=20 > (network connection) > resource partition. However, there are advantages from=20 > having both a SA > and DA label in a co-ps traffic unit that are network=20 > unique and not > just link-connection unique (ie not swapped)....the=20 > inherent robustness > under misconnectivity defects (without any adjunct OAM=20 > flow) is one of > these. And of course, these are the nature of the=20 > native labels one > already gets in Ethernet due to its cl-ps mode origins.=20 > So why would > one even contemplate not using these since they are=20 > already there? > =09 > The VID label is slightly different in that one can=20 > consider it as a > 'route discriminator label' and a local extension to=20 > the SA or DA, ie it > provides the ability to identify disjoint paths between=20 > nodal end > points. > =09 > The mere fact IEEE may not refer to the above=20 > quantities as 'labels' > does not change the fact that this is what they are. So=20 > I'm not clear > what your real point is here. > =09 > regards, Neil > =09 > =09 >=20 >=20 > ________________________________ >=20 > Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge=20 > ions/222> to see what's on, when.=20 >=20 From amgarcia@promat-cheminee.com Sat Sep 08 07:02:44 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITy5M-0003w8-7Y; Sat, 08 Sep 2007 07:02:44 -0400 Received: from [41.201.212.158] (helo=[41.201.212.158]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITy5L-000431-J9; Sat, 08 Sep 2007 07:02:43 -0400 Received: from [41.201.212.158] by mail.promat-cheminee.com; Sat, 8 Sep 2007 12:02:16 +0100 Message-ID: <01c7f207$b79d2310$9ed4c929@amgarcia> From: "Herschel Yang" To: Subject: US $ 119.95 Viagra 50mg x 60 pills price Date: Sat, 8 Sep 2007 12:02:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 3.8 (+++) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Viagra 50mg x 60 pills US $ 2.00 Per Pill price http://guessfavor.com From owner-ccamp@ops.ietf.org Sat Sep 08 08:47:02 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITziI-0004iE-3X for ccamp-archive@ietf.org; Sat, 08 Sep 2007 08:47:02 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITziF-0006lv-CG for ccamp-archive@ietf.org; Sat, 08 Sep 2007 08:46:59 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITzYg-000Inl-P7 for ccamp-data@psg.com; Sat, 08 Sep 2007 12:37:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [212.23.3.141] (helo=heisenberg.zen.co.uk) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITzYd-000InC-RN for ccamp@ops.ietf.org; Sat, 08 Sep 2007 12:37:05 +0000 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1ITzYb-0005PD-18 for ccamp@ops.ietf.org; Sat, 08 Sep 2007 12:37:01 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Sep 2007 13:36:54 +0100 Message-ID: <069d01c7f214$ecd50680$0302a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: liaison to IETF (ccamp, MPLS, BFD, PWE3, and L3VPN) on MFA Forum MPLS ICI Date: Sat, 8 Sep 2007 13:32:50 +0100 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-OriginalArrivalTime: 08 Sep 2007 12:36:55.0047 (UTC) FILETIME=[F06FB970:01C7F214] X-Originating-Heisenberg-IP: [88.96.235.138] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 FYI, The MFA would like a response to their liaison by 18th October. Adrian ----- Original Message ----- From: "David Sinicrope (RL/TNT)" To: "Adrian Farrel" ; "J. Rao Cherukuri" Cc: "Ross Callon" ; ; ; ; "Bocci, Matthew (Matthew)" ; ; ; ; "Ronald Bonica" ; "Stewart Bryant (stbryant)" ; ; ; ; "George Swallow (swallow)" ; "Loa Andersson" Sent: Friday, September 07, 2007 11:28 PM Subject: RE: liaison to IETF (ccamp, MPLS, BFD, PWE3, and L3VPN) on MFA Forum MPLS ICI Hi Adrian, Our next MFA Forum Technical Committee meeting is scheduled for October 22-26. If at all possible, we would like to have comments and feedback from the IETF by 10/18/2007 so that we could review and address them during that meeting. I realize that for the size of the document a little over 5 weeks for review and comment is very short notice. If not by 10/18/2007, then as soon as possible afterwards would help us. We are aiming to complete the document by year end and would need to have IETF feedback resolved and incorporated by the end of November at the latest to meet that goal. Please feel free to contact me with any other questions you may have. Thank-you for your help and support. Best Regards, David -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Friday, September 07, 2007 5:44 PM To: J. Rao Cherukuri; David Sinicrope (RL/TNT) Cc: Ross Callon; townsley@cisco.com; jari.arkko@piuha.net; andrew.g.malis@verizon.com; Bocci, Matthew (Matthew); nabil.n.bitar@verizon.com; dbrungard@att.com; rick.wilder@alcatel-lucent.com; Ronald Bonica; Stewart Bryant (stbryant); danny@arbor.net; dward@cisco.com; jhaas@pfrc.org; George Swallow (swallow); Loa Andersson Subject: Re: liaison to IETF (ccamp, MPLS, BFD, PWE3, and L3VPN) on MFA Forum MPLS ICI Rao, David, > This document is in our first level ballot procedure. > Please review and provide comments. Please suggest an appropriate timescale for review feedback. Thanks, Adrian ----- Original Message ----- From: "J. Rao Cherukuri" To: ; ; ; ; ; "Ronald Bonica" ; "Stewart Bryant (stbryant)" ; ; ; ; "George Swallow (swallow)" ; "Loa Andersson" Cc: "Ross Callon" ; ; ; "David Sinicrope (RL/TNT)" ; ; "Bocci, Matthew (Matthew)" ; "J. Rao Cherukuri" ; Sent: Friday, September 07, 2007 1:28 AM Subject: liaison to IETF (ccamp, MPLS, BFD, PWE3, and L3VPN) on MFA Forum MPLS ICI Dear All, The MFA Forum is currently working on an MPLS Inter-Carrier Interconnect (MPLS-ICI) specification to support IP VPNs, MPLS Pseudo Wires, Data Trunks, and VoIP. This specification is being driven by the MFA Forum service provider members. The objective of this Technical Specification is to enable a set of MPLS services, across administrative domains operated by different carriers. The MPLS ICI is a bi-directional IP-MPLS logical link between an Autonomous System Border Router (ASBR) in one service provider network and an ASBR in another service provider network. This document is targeted to equipment vendors to specify the necessary ASBR requirements and to service providers to provide guidance on how to use these capabilities. This document uses protocols developed in appropriate standard bodies (e.g., IETF, ITU) where applicable. This document is in our first level ballot procedure. Please review and provide comments. Thank you for your consideration of this matter. Cordially, David Sinicrope, A&D Chair, MFA Forum Rao Cherukuri Chairman, MFA Forum Technical Committee (draft MPLS ICI) From ebean@airfasthvac.com Sat Sep 08 09:38:47 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IU0WM-0004xv-V9; Sat, 08 Sep 2007 09:38:46 -0400 Received: from [220.87.218.147] (helo=[220.87.218.147]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IU0WM-0000bg-HY; Sat, 08 Sep 2007 09:38:46 -0400 Received: from [220.87.218.147] by mail.jadeinc.com; Sat, 8 Sep 2007 22:38:45 +0900 Message-ID: <01c7f21d$93e4d790$93da57dc@ebean> From: "Jenna Becker" To: Subject: Please read on.... Date: Sat, 8 Sep 2007 22:38:45 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 2.1 (++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 What type of herbs are used in MegaDik Pills? http://pcmasg.com From owner-ccamp@ops.ietf.org Sat Sep 08 09:42:30 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IU0Zy-00005C-7F for ccamp-archive@ietf.org; Sat, 08 Sep 2007 09:42:30 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IU0Zw-0000j8-Ju for ccamp-archive@ietf.org; Sat, 08 Sep 2007 09:42:30 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IU0U0-0000PA-Lm for ccamp-data@psg.com; Sat, 08 Sep 2007 13:36:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [209.191.85.59] (helo=web36808.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IU0Tw-0000Og-32 for ccamp@ops.ietf.org; Sat, 08 Sep 2007 13:36:18 +0000 Received: (qmail 29442 invoked by uid 60001); 8 Sep 2007 13:36:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=S3lpUEU8LC2a0BCzkszcs6TgLFBFXMSpjKDSb/zhpNUa3EEd2SHsnOGQsmwYqS7SymUEBjNyFokPzAJoscxThA9+S6qRu8kUy2KJqh4qm78IiFkz9fr6HMaKj56HUt+7QhK/ENuTYkFUiweD1s+Vp62Y+WLxWWCA7ergiiRGmwo=; X-YMail-OSG: HNxTpxEVM1kIFDJ5nJQFNXDiqEIRTZx6hwypN1TUjHwACMV.oYVxM4e7W0jUrw5qXIrUy2O1UUfzeozNtwgW6spgj6YrPYZVpwYQ6LDisuhi3Gd3ZnhPGvsdzA-- Received: from [68.98.133.125] by web36808.mail.mud.yahoo.com via HTTP; Sat, 08 Sep 2007 06:36:15 PDT Date: Sat, 8 Sep 2007 06:36:15 -0700 (PDT) From: Igor Bryskin Subject: RE: Closing the GELS Mailing List To: PAPADIMITRIOU Dimitri , neil.2.harrison@bt.com, adrian@olddog.co.uk, zali@cisco.com, Attila.Takacs@ericsson.com, ccamp@ops.ietf.org, gels@rtg.ietf.org Cc: rcallon@juniper.net In-Reply-To: <8144761F31F48D43AD53D09F5350E3800132149A@FRVELSMBS22.ad2.ad.alcatel.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2017222141-1189258575=:29167" Content-Transfer-Encoding: 8bit Message-ID: <216751.29167.qm@web36808.mail.mud.yahoo.com> Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c --0-2017222141-1189258575=:29167 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dimitri, As Neil correctly pointed out, there is a great advantage in having connection source ID within label of every packet forwarded over the connection (and MPLS’s great deficiency is the lack of LSP source ID in the MPLS label). The source ID must be within the (data plane) label and not anywhere else, because the label constitutes Layer Information (LI) in ITU terms, and only LI is accessible to a server layer that claims transparency for its clients. On the other hand source MA in co Ethernet is not used for packet forwarding, hence it should not be signaled as a part of the (control plane) label, which is information that must be put by an upstream node into the packet header, so that the downstream node could recognize and properly forward the packet. The conclusions in the context of co Ethernet: a) Data plane label is something determined only by IEEE, because it exists independently from any Control Plane: Ethernet connections could be configured by NMS without any Control Plane (no control plane labels at all). As far as CCAMP is concerned, data plane label is untouchable; b) Control plane label is always a subset of data plane and is an essential subject of CCAMP discussions: is it DMAC/VID? just VID? nothing as in case of statically configured connections? Is it network-scope? node-scope? link-scope? Stuff like that. Cheers, Igor > So, IMO IEEE should be responsible for the definition of data > plane labels, while CCAMP for control plane labels. a label distribution protocol is a set of procedures by which one node informs another of the label/FEC bindings it has made if these labels are distributed via the gmpls control plane driving population of the LIBs to which difference are u pointing out here ? so, not sure to see the point (whatever the number of levels of indirection between the fwd'ing plane encoding and control plane encoding u will always fall back on the former, the label distribution protocol exchanges a piece of information used by the nodes to perform their forwarding decision) -d. > -----Original Message----- > From: Igor Bryskin [mailto:i_bryskin@yahoo.com] > Sent: Friday, September 07, 2007 9:21 PM > To: neil.2.harrison@bt.com; PAPADIMITRIOU Dimitri; > adrian@olddog.co.uk; zali@cisco.com; > Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org > Cc: rcallon@juniper.net > Subject: RE: Closing the GELS Mailing List > > Hi Neil, > > I think there is a difference between a "data plane label" > which is a Layer Information (LI) used by a given server > layer and a "control plane label", which is a piece of > information signaled between adjacent controllers for the > purpose of connection provisioning. IMO the former is always > a superset of the latter. Let's take, for instance, > connection oriented Ethernet. MAC SA is a very important part > of the data plane label because it identifies the source of > the connection. However, the connection frames are forwarded > according to MAC DA/VID, and hence connection ingress node, > for example, needs only be signaled with this tuple by the > downstream neighbor, hence the control plane label is MAC > DA/VID (or just VID, for those who like the idea of the VID > cross-connects architecture). > > So, IMO IEEE should be responsible for the definition of data > plane labels, while CCAMP for control plane labels. > > Cheers, > Igor > > > neil.2.harrison@bt.com wrote: > > Dimitri wrote 07 September 2007 16:36 in response to Adrian > > > > > > > This is also something we would expect to describe within > > > CCAMP although > > > "what is a label" would come to us from the data plane > > specification. > > > > do i interpreet correctly your statement that if the > > specification that CCAMP is going to receive from IEEE does > > not speak about "label" and its encoding there will be no > > place to discuss any "label processing" and "label > > distribution" protocol in IETF - being domain-wide or > link-local > > - > > > > in that case, isn't the .1Q specification outside scope of > > this effort since not referring - as of today at least - to > > any "label" semantic as part of the Ethernet frame header > > information field ? > > > > thanks, > > -d. > > What do you think a MAC DA, MAC SA and VID are? These > are all 'labels'. > > You also have to remember that the nature of the labels > required in a > traffic unit are determined by the type of the network > mode one is > dealing with. > > In the co-cs and co-ps modes we have a construction known as a > 'connection'. This implies specific architectural > requirements....but > the most significant, for this discussion at least, is > that a connection > must have a single source. What this means is that one > does not have to > incorporate a SA label in a co mode traffic > unit....under defect-free > conditions it is redundant information as the > connection itself provides > the source information. {Compare this to the cl-ps mode > which does not > have connections...here having a SA in the traffic unit > is essential} > > Ergo why co-cs and co-ps mode technologies to date that > respect the > requirements of a connection have only focussed on > incorporating a DA > (forwarding) label. Further, these forwarding labels > only need to be > distinct in resolving some number (N say) of different > client layer > (link-connection) instances within a server layer > (network connection) > resource partition. However, there are advantages from > having both a SA > and DA label in a co-ps traffic unit that are network > unique and not > just link-connection unique (ie not swapped)....the > inherent robustness > under misconnectivity defects (without any adjunct OAM > flow) is one of > these. And of course, these are the nature of the > native labels one > already gets in Ethernet due to its cl-ps mode origins. > So why would > one even contemplate not using these since they are > already there? > > The VID label is slightly different in that one can > consider it as a > 'route discriminator label' and a local extension to > the SA or DA, ie it > provides the ability to identify disjoint paths between > nodal end > points. > > The mere fact IEEE may not refer to the above > quantities as 'labels' > does not change the fact that this is what they are. So > I'm not clear > what your real point is here. > > regards, Neil > > > > > ________________________________ > > Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge > > ions/222> to see what's on, when. > --------------------------------- Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. --0-2017222141-1189258575=:29167 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Dimitri,
As Neil correctly pointed out, there is a great advantage in having connection source ID within label of every packet forwarded over the connection (and MPLS’s great deficiency is the lack of LSP source ID in the MPLS label). The source ID must be within the (data plane) label and not anywhere else, because the label constitutes Layer Information (LI) in ITU terms, and only LI is accessible to a server layer that claims transparency for its clients. On the other hand source MA in co Ethernet is not used for packet forwarding, hence it should not be signaled as a part of the (control plane) label, which is information that must be put by an upstream node into the packet header, so that the downstream node could recognize and properly forward the packet.
 
The conclusions in the context of co Ethernet:
 
a)     Data plane label is something determined only by IEEE, because it exists independently from any Control Plane: Ethernet connections could be configured by NMS without any Control Plane (no control plane labels at all). As far as CCAMP is concerned, data plane label is untouchable;
b)    Control plane label is always a subset of data plane and is an essential subject of CCAMP discussions: is it DMAC/VID? just VID?  nothing as in case of statically configured connections? Is it network-scope? node-scope? link-scope? Stuff like that.
 
Cheers,
Igor




> So, IMO IEEE should be responsible for the definition of data
> plane labels, while CCAMP for control plane labels.

a label distribution protocol is a set of procedures by which one node
informs another of the label/FEC bindings it has made

if these labels are distributed via the gmpls control plane driving
population of the LIBs to which difference are u pointing out here ? so,
not sure to see the point (whatever the number of levels of indirection
between the fwd'ing plane encoding and control plane encoding u will
always fall back on the former, the label distribution protocol
exchanges a piece of information used by the nodes to perform their
forwarding decision)

-d.

> -----Original Message-----
> From: Igor Bryskin [mailto:i_bryskin@yahoo.com]
> Sent: Friday, September 07, 2007 9:21 PM
> To: neil.2.harrison@bt.com; PAPADIMITRIOU Dimitri;
> adrian@olddog.co.uk; zali@cisco.com;
> Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org
> Cc: rcallon@juniper.net
> Subject: RE: Closing the GELS Mailing List
>
> Hi Neil,
>
> I think there is a difference between a "data plane label"
> which is a Layer Information (LI) used by a given server
> layer and a "control plane label", which is a piece of
> information signaled between adjacent controllers for the
> purpose of connection provisioning. IMO the former is always
> a superset of the latter. Let's take, for instance,
> connection oriented Ethernet. MAC SA is a very important part
> of the data plane label because it identifies the source of
> the connection. However, the connection frames are forwarded
> according to MAC DA/VID, and hence connection ingress node,
> for example, needs only be signaled with this tuple by the
> downstream neighbor, hence the control plane label is MAC
> DA/VID (or just VID, for those who like the idea of the VID
> cross-connects architecture).
>
> So, IMO IEEE should be responsible for the definition of data
> plane labels, while CCAMP for control plane labels.
>
> Cheers,
> Igor
>
>
> neil.2.harrison@bt.com wrote:
>
> Dimitri wrote 07 September 2007 16:36 in response to Adrian
>
> > >
> > > This is also something we would expect to describe within
> > > CCAMP although
> > > "what is a label" would come to us from the data plane
> > specification.
> >
> > do i interpreet correctly your statement that if the
> > specification that CCAMP is going to receive from IEEE does
> > not speak about "label" and its encoding there will be no
> > place to discuss any "label processing" and "label
> > distribution" protocol in IETF - being domain-wide or
> link-local
> > -
> >
> > in that case, isn't the .1Q specification outside scope of
> > this effort since not referring - as of today at least - to
> > any "label" semantic as part of the Ethernet frame header
> > information field ?
> >
> > thanks,
> > -d.
>
> What do you think a MAC DA, MAC SA and VID are? These
> are all 'labels'.
>
> You also have to remember that the nature of the labels
> required in a
> traffic unit are determined by the type of the network
> mode one is
> dealing with.
>
> In the co-cs and co-ps modes we have a construction known as a
> 'connection'. This implies specific architectural
> requirements....but
> the most significant, for this discussion at least, is
> that a connection
> must have a single source. What this means is that one
> does not have to
> incorporate a SA label in a co mode traffic
> unit....under defect-free
> conditions it is redundant information as the
> connection itself provides
> the source information. {Compare this to the cl-ps mode
> which does not
> have connections...here having a SA in the traffic unit
> is essential}
>
> Ergo why co-cs and co-ps mode technologies to date that
> respect the
> requirements of a connection have only focussed on
> incorporating a DA
> (forwarding) label. Further, these forwarding labels
> only need to be
> distinct in resolving some number (N say) of different
> client layer
> (link-connection) instances within a server layer
> (network connection)
> resource partition. However, there are advantages from
> having both a SA
> and DA label in a co-ps traffic unit that are network
> unique and not
> just link-connection unique (ie not swapped)....the
> inherent robustness
> under misconnectivity defects (without any adjunct OAM
> flow) is one of
> these. And of course, these are the nature of the
> native labels one
> already gets in Ethernet due to its cl-ps mode origins.
> So why would
> one even contemplate not using these since they are
> already there?
>
> The VID label is slightly different in that one can
> consider it as a
> 'route discriminator label' and a local extension to
> the SA or DA, ie it
> provides the ability to identify disjoint paths between
> nodal end
> points.
>
> The mere fact IEEE may not refer to the above
> quantities as 'labels'
> does not change the fact that this is what they are. So
> I'm not clear
> what your real point is here.
>
> regards, Neil
>
>
>
>
> ________________________________
>
> Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge
> > ions/222> to see what's on, when.
>



Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. --0-2017222141-1189258575=:29167-- From Forma@luthier-nice.com Sat Sep 08 09:54:29 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IU0lZ-00048X-FY for ccamp-archive@megatron.ietf.org; Sat, 08 Sep 2007 09:54:29 -0400 Received: from dynamic-acs-24-239-114-120.zoominternet.net ([24.239.114.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IU0lX-0003cY-Uh for ccamp-archive@megatron.ietf.org; Sat, 08 Sep 2007 09:54:29 -0400 Received: from your-ae066c3a9b by luthier-nice.com with ASMTP id DD7456E6 for ; Sat, 8 Sep 2007 09:55:03 -0400 Received: from your-ae066c3a9b ([170.174.12.66]) by luthier-nice.com with ESMTP id A67AA951706D for ; Sat, 8 Sep 2007 09:55:03 -0400 Message-ID: <000201c7f21f$c9fe6970$7872ef18@yourae066c3a9b> From: "bettylu Forma" To: Subject: galwegia Date: Sat, 8 Sep 2007 09:54:35 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7F1FE.42ECC970" 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.1 (++++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0007_01C7F1FE.42ECC970 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.hollanyc.com/ Wassup Forma Kim likes big pe*nis men - get yours now nazif hayslett ------=_NextPart_000_0007_01C7F1FE.42ECC970 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.hollanyc.com/
Wassup Forma
Kim likes big pe*nis men - get yours = now
nazif hayslett
------=_NextPart_000_0007_01C7F1FE.42ECC970-- From KristyJim@luthier-nice.com Sat Sep 08 09:54:43 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IU0ln-00049S-2e for ccamp-archive@ietf.org; Sat, 08 Sep 2007 09:54:43 -0400 Received: from dynamic-acs-24-239-114-120.zoominternet.net ([24.239.114.120]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IU0ll-000176-3n for ccamp-archive@ietf.org; Sat, 08 Sep 2007 09:54:42 -0400 Received: from your-ae066c3a9b by luthier-nice.com with ASMTP id B2E499A1 for ; Sat, 8 Sep 2007 09:54:59 -0400 Received: from your-ae066c3a9b ([117.133.179.191]) by luthier-nice.com with ESMTP id 6491D9A28FD4 for ; Sat, 8 Sep 2007 09:54:59 -0400 Message-ID: <000201c7f21f$d1f01a70$7872ef18@yourae066c3a9b> From: "Kristy Jim" To: Subject: galnnub Date: Sat, 8 Sep 2007 09:54:48 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7F1FE.4ADE7A70" 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: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0007_01C7F1FE.4ADE7A70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.husacu.com/ Yo ccamp-archive damn, i was so small but now muccch bigger. Bengt Hedge ------=_NextPart_000_0007_01C7F1FE.4ADE7A70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.husacu.com/
Yo ccamp-archive
damn, i was so small but now muccch = bigger.
Bengt Hedge
------=_NextPart_000_0007_01C7F1FE.4ADE7A70-- From ihwatt@aesbrokers.com Sat Sep 08 10:13:12 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IU13g-00065Z-PL; Sat, 08 Sep 2007 10:13:12 -0400 Received: from chello087207245068.chello.pl ([87.207.245.68]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IU13f-0004C7-4x; Sat, 08 Sep 2007 10:13:12 -0400 Received: from madzia ([76.234.100.146]:27242 "HELO madzia" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 44f5cf57aesbrokers.com with ESMTP id 9508F68462C9D5 (ORCPT ); Sat, 8 Sep 2007 16:13:22 +0200 Message-ID: <001c01c7f233$2d77d370$072cbdcc@madzia> From: Brock To: ccamp-archive@ietf.org Subject: go belief Date: Sat, 8 Sep 2007 16:13:22 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C7F233.2D77D370" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.2969 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2800.0000 X-Spam-Score: 0.5 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C7F233.2D77D370 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable are not able to explore a locale with your five senses. It is cybernetics is based on human neural networks, the fact that one constant s= ubject in magazines. With all the attention one would ------=_NextPart_000_0019_01C7F233.2D77D370 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable

its craft. To eliminate the craftmanship you eliminate the

Are you wanting a bigger p e n _i s?

As se -e -n on TV

Over 730,000 Men around the world are already satisfied
Gain 3+ Inches In Leng _th
Increase Your P _en -is Wi _dth (Girth) By up _to 26%
100% Safe To Take, With NO Side Effects
No Pum ps! No Surg ery! No Ex ercises!
*3 FREE Bottles

old computer had a capacity of 8 fonts compared to 200, any
------=_NextPart_000_0019_01C7F233.2D77D370-- From owner-ccamp@ops.ietf.org Sat Sep 08 10:44:00 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IU1XU-00025D-PR for ccamp-archive@ietf.org; Sat, 08 Sep 2007 10:44:00 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IU1XU-0002jJ-4b for ccamp-archive@ietf.org; Sat, 08 Sep 2007 10:44:00 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IU1N5-0007av-8h for ccamp-data@psg.com; Sat, 08 Sep 2007 14:33:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [217.32.164.137] (helo=smtp1.smtp.bt.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IU1Mv-0007aB-7J for ccamp@ops.ietf.org; Sat, 08 Sep 2007 14:33:10 +0000 Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 8 Sep 2007 15:33:02 +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_01C7F225.293E5CF2" Subject: RE: Closing the GELS Mailing List Date: Sat, 8 Sep 2007 15:32:36 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C0106EDF4@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <216751.29167.qm@web36808.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing the GELS Mailing List Thread-Index: AcfyHTv9AzpIN5m4QLG1qvp0tsAYngAAGXwA From: To: , , , , , , Cc: X-OriginalArrivalTime: 08 Sep 2007 14:33:02.0918 (UTC) FILETIME=[299C7660:01C7F225] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f45599941caef2d9ac4ed98df73589d5 This is a multi-part message in MIME format. ------_=_NextPart_001_01C7F225.293E5CF2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Igor...just want to slightly correct/amend something below...please see in-line: -----Original Message----- From: Igor Bryskin [mailto:i_bryskin@yahoo.com]=20 Sent: 08 September 2007 14:36 To: PAPADIMITRIOU Dimitri; Harrison,N,Neil,JCGA1 R; adrian@olddog.co.uk; zali@cisco.com; Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org Cc: rcallon@juniper.net Subject: RE: Closing the GELS Mailing List Dimitri, As Neil correctly pointed out, there is a great advantage in having connection source ID within label of every packet forwarded over the connection (and MPLS's great deficiency is the lack of LSP source ID in the MPLS label).=20 NH=3D> Yes, it is true that having a SA label in each/every traffic unit is an important advantage...and so is having a DA address label (for forwarding) that does not have to be swapped. As I pointed out before, one can take some short-cuts and traditional co-ps mode technologies have (perhaps unconsciously?) done so, viz: - if one respects the requirements of a connection then you can omit the SA label from the DP traffic units....as under defect-free conditions it is redundant information. However, this means OAM (essentially a CV flow that contains the SA label) should (but really ought to be must for customer integrity/security reasons) be run on ALL connections (irrespective of their importance) as one cannot predict a priori where misconnectivity defects will occur. But this is significantly operationally inferior to having the SA information carried in the traffic unit as this makes the network inherently robust to such defects without any OAM at all. - wrt forwarding one only needs to resolve/identify (ie label) the number of client instances that a given server layer resource partition can support per client link connection.....noting that said labels are indeed indirection proxies for the true DA anyway. However, this is also operationally inferior to using a true connection DA for forwarding that is not swapped. =20 Now if you don't respect the requirements of a connection, and both LDP and PHP in MPLS don't as they create mp2p constructs, then you have to appeal to a higher layer entity to effect a demerging function, ie essentially recover the lost SA information. If the client is a cl-ps mode technology with non-overlapping addresses this can do the job directly. If this is not the case you have to add the lost information some other way....and in MPLS this is done by adding a further 1-hop LSP where the label here now takes on the semantic of SA. But this is actually not a very sensible approach because one of the key operational things we need in any layer network is consistent Characteristic Information (ie consistent traffic unit structure, consistent traffic unit functional field semantics and consistent OAM). Why is this important? Well, if one has misconnectivity defects present it is important that the trail (co mode) or flow (cl mode) termination points handles the traffic units and OAM in a consistent and predictable way. MPLS does not have consistent CI....indeed I can list at least 4 different semantics of a label and more will emerge as folks consider new applications like p2mp constructs. =20 There are many other consequences of merging constructs, but I don't want to get into these here. =20 regards, Neil =20 The source ID must be within the (data plane) label and not anywhere else, because the label constitutes Layer Information (LI) in ITU terms, and only LI is accessible to a server layer that claims transparency for its clients. On the other hand source MA in co Ethernet is not used for packet forwarding, hence it should not be signaled as a part of the (control plane) label, which is information that must be put by an upstream node into the packet header, so that the downstream node could recognize and properly forward the packet.=20 The conclusions in the context of co Ethernet: a) Data plane label is something determined only by IEEE, because it exists independently from any Control Plane: Ethernet connections could be configured by NMS without any Control Plane (no control plane labels at all). As far as CCAMP is concerned, data plane label is untouchable; b) Control plane label is always a subset of data plane and is an essential subject of CCAMP discussions: is it DMAC/VID? just VID? nothing as in case of statically configured connections? Is it network-scope? node-scope? link-scope? Stuff like that. Cheers, Igor > So, IMO IEEE should be responsible for the definition of data=20 > plane labels, while CCAMP for control plane labels. a label distribution protocol is a set of procedures by which one node informs another of the label/FEC bindings it has made if these labels are distributed via the gmpls control plane driving population of the LIBs to which difference are u pointing out here ? so, not sure to see the point (whatever the number of levels of indirection between the fwd'ing plane encoding and control plane encoding u will always fall back on the former, the label distribution protocol exchanges a piece of information used by the nodes to perform their forwarding decision)=20 -d. > -----Original Message----- > From: Igor Bryskin [mailto:i_bryskin@yahoo.com]=20 > Sent: Friday, September 07, 2007 9:21 PM > To: neil.2.harrison@bt.com; PAPADIMITRIOU Dimitri;=20 > adrian@olddog.co.uk; zali@cisco.com;=20 > Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org > Cc: rcallon@juniper.net > Subject: RE: Closing the GELS Mailing List >=20 > Hi Neil, >=20 > I think there is a difference between a "data plane label"=20 > which is a Layer Information (LI) used by a given server=20 > layer and a "control plane label", which is a piece of=20 > information signaled between adjacent controllers for the=20 > purpose of connection provisioning. IMO the former is always=20 > a superset of the latter. Let's take, for instance,=20 > connection oriented Ethernet. MAC SA is a very important part=20 > of the data plane label because it identifies the source of=20 > the connection. However, the connection frames are forwarded=20 > according to MAC DA/VID, and hence connection ingress node,=20 > for example, needs only be signaled with this tuple by the=20 > downstream neighbor, hence the control plane label is MAC=20 > DA/VID (or just VID, for those who like the idea of the VID=20 > cross-connects architecture). >=20 > So, IMO IEEE should be responsible for the definition of data=20 > plane labels, while CCAMP for control plane labels. >=20 > Cheers, > Igor=20 >=20 >=20 > neil.2.harrison@bt.com wrote: >=20 > Dimitri wrote 07 September 2007 16:36 in response to Adrian=20 >=20 > > >=20 > > > This is also something we would expect to describe within > > > CCAMP although=20 > > > "what is a label" would come to us from the data plane=20 > > specification. > >=20 > > do i interpreet correctly your statement that if the=20 > > specification that CCAMP is going to receive from IEEE does=20 > > not speak about "label" and its encoding there will be no=20 > > place to discuss any "label processing" and "label=20 > > distribution" protocol in IETF - being domain-wide or=20 > link-local > > - > >=20 > > in that case, isn't the .1Q specification outside scope of=20 > > this effort since not referring - as of today at least - to=20 > > any "label" semantic as part of the Ethernet frame header=20 > > information field ? > >=20 > > thanks, > > -d. >=20 > What do you think a MAC DA, MAC SA and VID are? These=20 > are all 'labels'. >=20 > You also have to remember that the nature of the labels=20 > required in a > traffic unit are determined by the type of the network=20 > mode one is > dealing with. >=20 > In the co-cs and co-ps modes we have a construction known as a > 'connection'. This implies specific architectural=20 > requirements....but > the most significant, for this discussion at least, is=20 > that a connection > must have a single source. What this means is that one=20 > does not have to > incorporate a SA label in a co mode traffic=20 > unit....under defect-free > conditions it is redundant information as the=20 > connection itself provides > the source information. {Compare this to the cl-ps mode=20 > which does not > have connections...here having a SA in the traffic unit=20 > is essential} >=20 > Ergo why co-cs and co-ps mode technologies to date that=20 > respect the > requirements of a connection have only focussed on=20 > incorporating a DA > (forwarding) label. Further, these forwarding labels=20 > only need to be > distinct in resolving some number (N say) of different=20 > client layer > (link-connection) instances within a server layer=20 > (network connection) > resource partition. However, there are advantages from=20 > having both a SA > and DA label in a co-ps traffic unit that are network=20 > unique and not > just link-connection unique (ie not swapped)....the=20 > inherent robustness > under misconnectivity defects (without any adjunct OAM=20 > flow) is one of > these. And of course, these are the nature of the=20 > native labels one > already gets in Ethernet due to its cl-ps mode origins.=20 > So why would > one even contemplate not using these since they are=20 > already there? >=20 > The VID label is slightly different in that one can=20 > consider it as a > 'route discriminator label' and a local extension to=20 > the SA or DA, ie it > provides the ability to identify disjoint paths between=20 > nodal end > points. >=20 > The mere fact IEEE may not refer to the above=20 > quantities as 'labels' > does not change the fact that this is what they are. So=20 > I'm not clear > what your real point is here. >=20 > regards, Neil >=20 >=20 >=20 >=20 > ________________________________ >=20 > Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge=20 > > ions/222> to see what's on, when.=20 >=20 _____ =20 Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV.=20 ------_=_NextPart_001_01C7F225.293E5CF2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Thanks Igor...just want to slightly correct/amend something=20 below...please see in-line:
-----Original Message-----
From: Igor = Bryskin=20 [mailto:i_bryskin@yahoo.com]
Sent: 08 September 2007=20 14:36
To: PAPADIMITRIOU Dimitri; Harrison,N,Neil,JCGA1 R;=20 adrian@olddog.co.uk; zali@cisco.com; Attila.Takacs@ericsson.com;=20 ccamp@ops.ietf.org; gels@rtg.ietf.org
Cc:=20 rcallon@juniper.net
Subject: RE: Closing the GELS Mailing=20 List

Dimitri,
As Neil correctly pointed out, there is a = great=20 advantage in having connection source ID within label of every = packet=20 forwarded over the connection (and MPLS’s great deficiency is = the lack of=20 LSP source ID in the MPLS label). 
NH=3D> Yes, it is = true that=20 having a SA label in each/every traffic unit is an important = advantage...and so=20 is having a DA address label (for forwarding) that does not have to = be=20 swapped.  As I pointed out before, one can take some = short-cuts=20 and traditional co-ps mode technologies have (perhaps = unconsciously?) done=20 so, viz:
 -    if one respects the = requirements of a=20 connection then you can omit the SA label from the DP traffic = units....as=20 under defect-free conditions it is redundant information.  = However,=20 this means OAM (essentially a CV flow that contains the SA label) = should=20 (but really ought to be must for customer integrity/security = reasons) be run=20 on ALL connections (irrespective of their importance) as one cannot = predict=20 a priori where misconnectivity defects will occur.  But this is = significantly operationally inferior to having the SA information = carried in=20 the traffic unit as this makes the network inherently robust to such = defects=20 without any OAM at all.
-    wrt=20 forwarding one only needs to resolve/identify (ie label) the number = of=20 client instances that a given server layer resource partition can = support=20 per client link connection.....noting that said labels are indeed=20 indirection proxies for the true DA anyway.  However, this is = also=20 operationally inferior to using a true connection DA for = forwarding=20 that is not swapped.
 
Now if you don't = respect the=20 requirements of a connection, and both LDP and PHP in MPLS don't as = they=20 create mp2p constructs, then you have to appeal to a higher layer = entity to=20 effect a demerging function, ie essentially recover the lost SA=20 information.  If the client is a cl-ps mode technology with=20 non-overlapping addresses this can do the job directly.  If = this is not=20 the case you have to add the lost information some other way....and = in MPLS=20 this is done by adding a further 1-hop LSP where the label here now = takes on=20 the semantic of SA.  But this is actually not a very sensible = approach=20 because one of the key operational things we need in any layer = network is=20 consistent Characteristic Information (ie consistent traffic unit = structure,=20 consistent traffic unit functional field semantics and consistent=20 OAM).  Why is this important?  Well, if one has = misconnectivity=20 defects present it is important that the trail (co mode) or flow (cl = mode)=20 termination points handles the traffic units and OAM in a consistent = and=20 predictable way.  MPLS does not have consistent CI....indeed I = can list=20 at least 4 different semantics of a label and more will emerge as = folks=20 consider new applications like p2mp constructs.
 
There are many other = consequences=20 of merging constructs, but I don't want to get into these=20 here.
 
regards, = Neil
 
  The=20 source ID must be within the (data plane) label and not anywhere = else,=20 because the label constitutes Layer Information (LI) in ITU terms, = and only=20 LI is accessible to a server layer that claims transparency for its = clients.=20 On the other hand source MA in co Ethernet is not used for packet=20 forwarding, hence it should not be signaled as a part of the = (control plane)=20 label, which is information that must be put by an upstream node = into the=20 packet header, so that the downstream node could recognize and = properly=20 forward the packet.
The conclusions in the context of co = Ethernet:
<!--[if=20 !supportLists]-->a)    =20 <!--[endif]-->Data plane label is something = determined=20 only by IEEE, because it exists independently from any Control = Plane:=20 Ethernet connections could be configured by NMS without any Control = Plane=20 (no control plane labels at all). As far as CCAMP is concerned, data = plane=20 label is untouchable;
<!--[if=20 !supportLists]-->b)   =20 <!--[endif]-->Control plane label is always a = subset of=20 data plane and is an essential subject of CCAMP discussions: is it = DMAC/VID?=20 just VID?  nothing as in case of statically = configured=20 connections? Is it network-scope? node-scope? link-scope? Stuff like = that.
Cheers,
Igor

<!--[if=20 = !supportLineBreakNewLine]-->
<!--[endif]-->

>= ;=20 So, IMO IEEE should be responsible for the definition of data =
> plane=20 labels, while CCAMP for control plane labels.

a label = distribution=20 protocol is a set of procedures by which one node
informs another = of the=20 label/FEC bindings it has made

if these labels are = distributed via=20 the gmpls control plane driving
population of the LIBs to which=20 difference are u pointing out here ? so,
not sure to see the = point=20 (whatever the number of levels of indirection
between the fwd'ing = plane=20 encoding and control plane encoding u will
always fall back on = the=20 former, the label distribution protocol
exchanges a piece of = information=20 used by the nodes to perform their
forwarding decision)=20

-d.

> -----Original Message-----
> From: = Igor=20 Bryskin [mailto:i_bryskin@yahoo.com]
> Sent: Friday, = September 07,=20 2007 9:21 PM
> To: neil.2.harrison@bt.com; PAPADIMITRIOU = Dimitri;=20
> adrian@olddog.co.uk; zali@cisco.com;
>=20 Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; = gels@rtg.ietf.org
>=20 Cc: rcallon@juniper.net
> Subject: RE: Closing the GELS = Mailing=20 List
>
> Hi Neil,
>
> I think there is a=20 difference between a "data plane label"
> which is a Layer=20 Information (LI) used by a given server
> layer and a = "control plane=20 label", which is a piece of
> information signaled between = adjacent=20 controllers for the
> purpose of connection provisioning. IMO = the=20 former is always
> a superset of the latter. Let's take, for=20 instance,
> connection oriented Ethernet. MAC SA is a very = important=20 part
> of the data plane label because it identifies the = source of=20
> the connection. However, the connection frames are = forwarded=20
> according to MAC DA/VID, and hence connection ingress node, =
> for example, needs only be signaled with this tuple by the =
>=20 downstream neighbor, hence the control plane label is MAC
> = DA/VID=20 (or just VID, for those who like the idea of the VID
> = cross-connects=20 architecture).
>
> So, IMO IEEE should be responsible = for the=20 definition of data
> plane labels, while CCAMP for control = plane=20 labels.
>
> Cheers,
> Igor
>
> =
>=20 neil.2.harrison@bt.com wrote:
>
> Dimitri wrote 07 = September=20 2007 16:36 in response to Adrian
>
> > > =
> >=20 > This is also something we would expect to describe = within
> >=20 > CCAMP although
> > > "what is a label" would come = to us=20 from the data plane
> > specification.
> > =
> >=20 do i interpreet correctly your statement that if the
> >=20 specification that CCAMP is going to receive from IEEE does
> = >=20 not speak about "label" and its encoding there will be no
> = >=20 place to discuss any "label processing" and "label
> >=20 distribution" protocol in IETF - being domain-wide or
>=20 link-local
> > -
> >
> > in that case, = isn't the=20 .1Q specification outside scope of
> > this effort since = not=20 referring - as of today at least - to
> > any "label" = semantic as=20 part of the Ethernet frame header
> > information field = ?
>=20 >
> > thanks,
> > -d.
>
> What do = you=20 think a MAC DA, MAC SA and VID are? These
> are all = 'labels'.
>=20
> You also have to remember that the nature of the labels =
>=20 required in a
> traffic unit are determined by the type of the = network=20
> mode one is
> dealing with.
>
> In the = co-cs and=20 co-ps modes we have a construction known as a
> 'connection'. = This=20 implies specific architectural
> requirements....but
> = the most=20 significant, for this discussion at least, is
> that a=20 connection
> must have a single source. What this means is = that one=20
> does not have to
> incorporate a SA label in a co = mode=20 traffic
> unit....under defect-free
> conditions it is=20 redundant information as the
> connection itself = provides
> the=20 source information. {Compare this to the cl-ps mode
> which = does=20 not
> have connections...here having a SA in the traffic unit =
>=20 is essential}
>
> Ergo why co-cs and co-ps mode = technologies to=20 date that
> respect the
> requirements of a connection = have=20 only focussed on
> incorporating a DA
> (forwarding) = label.=20 Further, these forwarding labels
> only need to be
> = distinct=20 in resolving some number (N say) of different
> client = layer
>=20 (link-connection) instances within a server layer
> (network=20 connection)
> resource partition. However, there are = advantages from=20
> having both a SA
> and DA label in a co-ps traffic = unit that=20 are network
> unique and not
> just link-connection = unique (ie=20 not swapped)....the
> inherent robustness
> under=20 misconnectivity defects (without any adjunct OAM
> flow) is = one=20 of
> these. And of course, these are the nature of the =
> native=20 labels one
> already gets in Ethernet due to its cl-ps mode = origins.=20
> So why would
> one even contemplate not using these = since=20 they are
> already there?
>
> The VID label is = slightly=20 different in that one can
> consider it as a
> 'route=20 discriminator label' and a local extension to
> the SA or DA, = ie=20 it
> provides the ability to identify disjoint paths between =
>=20 nodal end
> points.
>
> The mere fact IEEE may = not refer=20 to the above
> quantities as 'labels'
> does not change = the=20 fact that this is what they are. So
> I'm not clear
> = what your=20 real point is here.
>
> regards, Neil
>
> =
>=20
>
> ________________________________
>
> = Sick=20 sense of humor? Visit Yahoo! TV's Comedy with an Edge
> = >=20 ions/222> to see what's on, when.
>=20



Ready for the edge of your seat? Check = out=20 tonight's top picks on Yahoo! TV. ------_=_NextPart_001_01C7F225.293E5CF2-- From lsqufvpeynli@bramsche.com Sat Sep 08 11:07:59 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IU1uh-0000iW-Tg; Sat, 08 Sep 2007 11:07:59 -0400 Received: from e176219073.adsl.alicedsl.de ([85.176.219.73]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IU1uh-0003Sa-66; Sat, 08 Sep 2007 11:07:59 -0400 Received: from [85.176.219.73] by mx1.websuche.de; Sat, 8 Sep 2007 16:08:11 +0100 Message-ID: <01c7f22a$12477690$49dbb055@lsqufvpeynli> From: "Isabelle Higgins" To: Subject: Re:STATUS LIGHT Date: Sat, 8 Sep 2007 16:08:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Score: 4.2 (++++) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Have you ever wanted a expensive Watch? We have the piece for you! We stock all the high scale for a very small fraction of the price. www.poeelkwij.com From owner-ccamp@ops.ietf.org Sat Sep 08 12:50:04 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IU3VU-0002Y1-KJ for ccamp-archive@ietf.org; Sat, 08 Sep 2007 12:50:04 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IU3VT-0001iD-41 for ccamp-archive@ietf.org; Sat, 08 Sep 2007 12:50:04 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IU3KY-000Nvf-K0 for ccamp-data@psg.com; Sat, 08 Sep 2007 16:38:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [62.23.212.7] (helo=smail6.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IU3KR-000Nrs-2E for ccamp@ops.ietf.org; Sat, 08 Sep 2007 16:38:44 +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 l88GbwYW031642; Sat, 8 Sep 2007 18:37:58 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS07.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Sat, 8 Sep 2007 18:38:28 +0200 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: Closing the GELS Mailing List Date: Sat, 8 Sep 2007 18:38:22 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E380013214BD@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <216751.29167.qm@web36808.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing the GELS Mailing List thread-index: AcfyHT6Fns26LJYEQlGdFkPBvk9UrAAAJN+w References: <8144761F31F48D43AD53D09F5350E3800132149A@FRVELSMBS22.ad2.ad.alcatel.com> <216751.29167.qm@web36808.mail.mud.yahoo.com> From: "PAPADIMITRIOU Dimitri" To: "Igor Bryskin" , , , , , , Cc: X-OriginalArrivalTime: 08 Sep 2007 16:38:28.0855 (UTC) FILETIME=[AF6B5070:01C7F236] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 igor =20 > The conclusions in the context of co Ethernet: > =20 > a) Data plane label is something determined only by=20 > IEEE, because it exists independently from any Control Plane: > Ethernet connections could be configured by NMS without any=20 > Control Plane (no control plane labels at all). As far as=20 > CCAMP is concerned, data plane label is untouchable; IEEE 802.1 does not deal with the data plane in that sense. it defines "control" of forwarding components it is an issue we need to consider.=20 we are not taking a data plane specification in its basic sense for which CCAMP adds a control plane. to the modes 802.1 currently considers MSTP (domain-wide bridging through spanning tree), SPB (shortest-path tree bridging) and PBB-TE (for which we have no outline so far) result in specification detailing operations of forwarding components.=20 if i take the latter its is intended to "support provisioning systems that explicitly select traffic engineered paths within Provider Backbone Bridge Networks (P802.1ah) by allowing a network operator to disable unknown destination address forwarding and source address learning for administratively selected VLAN Identifiers, while allowing other network control protocols to dynamically determine active topologies for other services." ... far from being a data plane specification in its base sense. > b) Control plane label is always a subset of data=20 > plane and is an essential subject of CCAMP discussions: is it=20 > DMAC/VID? just VID? nothing as in case of statically=20 > configured connections? Is it network-scope? node-scope?=20 > link-scope? Stuff like that. i will use examples to make this clearer to allow something along the PBB-TE line work is ongoing to define states which force the port state being learning off and forwarding on (for all VID allocated to PBB-TE but not to MSTP), disable broadcast/unknown unicast while allowing filtering of unicast only (both are control of MAC relay operations), etc. -> all these control-driven operation fall outside CCAMP scope (at least as far as my understanding goes) -> the question is not "IEEE defines the data plane and IETF the control plane" =3D> the question is which control components can CCAMP consider that complements amended 802.1ah bridge control & operation: data path setup/provisioning mechanism (explicit source-initiated routing) ? traffic engineering which first requires to see which TE model IEEE will consider ? others ? =20 -d. > -----Original Message----- > From: Igor Bryskin [mailto:i_bryskin@yahoo.com]=20 > Sent: Saturday, September 08, 2007 3:36 PM > To: PAPADIMITRIOU Dimitri; neil.2.harrison@bt.com;=20 > adrian@olddog.co.uk; zali@cisco.com;=20 > Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org > Cc: rcallon@juniper.net > Subject: RE: Closing the GELS Mailing List >=20 > Dimitri, > =09 > As Neil correctly pointed out, there is a great=20 > advantage in having connection source ID within label of=20 > every packet forwarded over the connection (and MPLS's great=20 > deficiency is the lack of LSP source ID in the MPLS label).=20 > The source ID must be within the (data plane) label and not=20 > anywhere else, because the label constitutes Layer=20 > Information (LI) in ITU terms, and only LI is accessible to a=20 > server layer that claims transparency for its clients. On the=20 > other hand source MA in co Ethernet is not used for packet=20 > forwarding, hence it should not be signaled as a part of the=20 > (control plane) label, which is information that must be put=20 > by an upstream node into the packet header, so that the=20 > downstream node could recognize and properly forward the packet.=20 > =20 > The conclusions in the context of co Ethernet: > =20 > a) Data plane label is something determined only by=20 > IEEE, because it exists independently from any Control Plane:=20 > Ethernet connections could be configured by NMS without any=20 > Control Plane (no control plane labels at all). As far as=20 > CCAMP is concerned, data plane label is untouchable; > b) Control plane label is always a subset of data=20 > plane and is an essential subject of CCAMP discussions: is it=20 > DMAC/VID? just VID? nothing as in case of statically=20 > configured connections? Is it network-scope? node-scope?=20 > link-scope? Stuff like that. > =20 > Cheers, > Igor > =09 > =09 > =09 > =09 > > So, IMO IEEE should be responsible for the definition of data=20 > > plane labels, while CCAMP for control plane labels. > =09 > a label distribution protocol is a set of procedures by=20 > which one node > informs another of the label/FEC bindings it has made > =09 > if these labels are distributed via the gmpls control=20 > plane driving > population of the LIBs to which difference are u=20 > pointing out here ? so, > not sure to see the point (whatever the number of=20 > levels of indirection > between the fwd'ing plane encoding and control plane=20 > encoding u will > always fall back on the former, the label distribution protocol > exchanges a piece of information used by the nodes to=20 > perform their > forwarding decision)=20 > =09 > -d. > =09 > > -----Original Message----- > > From: Igor Bryskin [mailto:i_bryskin@yahoo.com]=20 > > Sent: Friday, September 07, 2007 9:21 PM > > To: neil.2.harrison@bt.com; PAPADIMITRIOU Dimitri;=20 > > adrian@olddog.co.uk; zali@cisco.com;=20 > > Attila.Takacs@ericsson.com; ccamp@ops.ietf.org;=20 > gels@rtg.ietf.org > > Cc: rcallon@juniper.net > > Subject: RE: Closing the GELS Mailing List > >=20 > > Hi Neil, > >=20 > > I think there is a difference between a "data plane label"=20 > > which is a Layer Information (LI) used by a given server=20 > > layer and a "control plane label", which is a piece of=20 > > information signaled between adjacent controllers for the=20 > > purpose of connection provisioning. IMO the former is always=20 > > a superset of the latter. Let's take, for instance,=20 > > connection oriented Ethernet. MAC SA is a very important part=20 > > of the data plane label because it identifies the source of=20 > > the connection. However, the connection frames are forwarded=20 > > according to MAC DA/VID, and hence connection ingress node,=20 > > for example, needs only be signaled with this tuple by the=20 > > downstream neighbor, hence the control plane label is MAC=20 > > DA/VID (or just VID, for those who like the idea of the VID=20 > > cross-connects architecture). > >=20 > > So, IMO IEEE should be responsible for the definition of data=20 > > plane labels, while CCAMP for control plane labels. > >=20 > > Cheers, > > Igor=20 > >=20 > >=20 > > neil.2.harrison@bt.com wrote: > >=20 > > Dimitri wrote 07 September 2007 16:36 in response to Adrian=20 > >=20 > > > >=20 > > > > This is also something we would expect to describe within > > > > CCAMP although=20 > > > > "what is a label" would come to us from the data plane=20 > > > specification. > > >=20 > > > do i interpreet correctly your statement that if the=20 > > > specification that CCAMP is going to receive from IEEE does=20 > > > not speak about "label" and its encoding there will be no=20 > > > place to discuss any "label processing" and "label=20 > > > distribution" protocol in IETF - being domain-wide or=20 > > link-local > > > - > > >=20 > > > in that case, isn't the .1Q specification outside scope of=20 > > > this effort since not referring - as of today at least - to=20 > > > any "label" semantic as part of the Ethernet frame header=20 > > > information field ? > > >=20 > > > thanks, > > > -d. > >=20 > > What do you think a MAC DA, MAC SA and VID are? These=20 > > are all 'labels'. > >=20 > > You also have to remember that the nature of the labels=20 > > required in a > > traffic unit are determined by the type of the network=20 > > mode one is > > dealing with. > >=20 > > In the co-cs and co-ps modes we have a construction known as a > > 'connection'. This implies specific architectural=20 > > requirements....but > > the most significant, for this discussion at least, is=20 > > that a connection > > must have a single source. What this means is that one=20 > > does not have to > > incorporate a SA label in a co mode traffic=20 > > unit....under defect-free > > conditions it is redundant information as the=20 > > connection itself provides > > the source information. {Compare this to the cl-ps mode=20 > > which does not > > have connections...here having a SA in the traffic unit=20 > > is essential} > >=20 > > Ergo why co-cs and co-ps mode technologies to date that=20 > > respect the > > requirements of a connection have only focussed on=20 > > incorporating a DA > > (forwarding) label. Further, these forwarding labels=20 > > only need to be > > distinct in resolving some number (N say) of different=20 > > client layer > > (link-connection) instances within a server layer=20 > > (network connection) > > resource partition. However, there are advantages from=20 > > having both a SA > > and DA label in a co-ps traffic unit that are network=20 > > unique and not > > just link-connection unique (ie not swapped)....the=20 > > inherent robustness > > under misconnectivity defects (without any adjunct OAM=20 > > flow) is one of > > these. And of course, these are the nature of the=20 > > native labels one > > already gets in Ethernet due to its cl-ps mode origins.=20 > > So why would > > one even contemplate not using these since they are=20 > > already there? > >=20 > > The VID label is slightly different in that one can=20 > > consider it as a > > 'route discriminator label' and a local extension to=20 > > the SA or DA, ie it > > provides the ability to identify disjoint paths between=20 > > nodal end > > points. > >=20 > > The mere fact IEEE may not refer to the above=20 > > quantities as 'labels' > > does not change the fact that this is what they are. So=20 > > I'm not clear > > what your real point is here. > >=20 > > regards, Neil > >=20 > >=20 > >=20 > >=20 > > ________________________________ > >=20 > > Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge=20 > > > ions/222> to see what's on, when.=20 > >=20 > =09 > =09 >=20 >=20 > ________________________________ >=20 > Ready for the edge of your seat? Check out tonight's top=20 > picks=20 > on=20 > Yahoo! TV.=20 >=20 From vzvmz9estzu@gala.net Sat Sep 08 13:32:17 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IU4AL-0001ry-Lb; Sat, 08 Sep 2007 13:32:17 -0400 Received: from catv-5984b1ee.catv.broadband.hu ([89.132.177.238] helo=fbakcvw) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IU4AJ-0008Hw-5u; Sat, 08 Sep 2007 13:32:15 -0400 To: From: "Kyoko Briana" Subject: Top 0nlinePharmacy, 70% discount on all popular pills, order today ttqh Message-ID: <4973s87449.480q88104901@gala.net> Date: Sat, 08 Sep 2007 19:32:26 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--r4ttsppjvb6wmpg6chhvng2hz6yf7" X-Spam-Score: 4.5 (++++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 ----r4ttsppjvb6wmpg6chhvng2hz6yf7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Save your $ Pharmacy : Pick the meds you want to order & checkout (2 steps to finish an order) : Fast delivery & discrete packaging to your doorstep : We sell both BRAND(100% original brand) & GENERIC(35% cheaper) : We give up to 70% discount (on retail shop price) for BOTH brand & generic meds : Meds we sell: Cia|lisViagra, UltramAtivan, CelebrexSoma, MeridiaClenbuterol, LuvoxPaxilZoloft & other 20 popular meds View all medications we have http://biny.kiperfumed.com http://bogcqc.kiperfumed.com ----r4ttsppjvb6wmpg6chhvng2hz6yf7 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Save your $ Pharmacy
: Pick the meds you want to order & checkout (2 steps to finish an order)
: Fast delivery & discrete packaging to your doorstep
: We sell both BRAND(100% original brand) & GENERIC(35% cheaper)
: We give up to 70% discount (on retail shop price) for BOTH brand & generic meds
: Meds we sell: Cia|lisViagra, UltramAtivan, CelebrexSoma, MeridiaClenbuterol, LuvoxPaxilZoloft & other 20 popular meds


View all medications we have (1st link)
If above link not load up, try this (2nd link)




come forth calling gym. latter raise likely besides, ----r4ttsppjvb6wmpg6chhvng2hz6yf7-- From xra9xiqnx@advsol.com Sat Sep 08 13:54:22 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IU4Vi-00008b-I9; Sat, 08 Sep 2007 13:54:22 -0400 Received: from [97.82.218.68] (helo=cccy) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IU4Vi-0000Xg-AM; Sat, 08 Sep 2007 13:54:22 -0400 To: From: "Neoma Sandee" Subject: -== Buy SwissRep|ica iRolex online, Great selection of fine QualityWatches qmuy Message-ID: <61746g17236.4790p34018958@advsol.com> Date: Sat, 08 Sep 2007 01:59:17 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--nul8vjos2pgd4b9eh2b5gi35f" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 ----nul8vjos2pgd4b9eh2b5gi35f Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Super Branded Watches (85% Price Off) : RolexMen : RolexLady : Alain Silberstein : Audemars Piguet : Breitling : Bvlgari : Cartier : Chanel : Chopard : Franck Muller : IWC : Jaeger-Lecoultre : Omega : Panerai Luminor : Patek Philippe : Tag Heuer Only from $189 Each :- Click below link http://rvwn.kiperfumed.com http://rhqg.kiperfumed.com ----nul8vjos2pgd4b9eh2b5gi35f Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Super Branded Watches (85% Price Off)
RolexMen
RolexLady
Alain Silberstein
Audemars Piguet
Breitling
Bvlgari
Cartier
Chanel
Chopard
Franck Muller
IWC
Jaeger-Lecoultre
Omega
Panerai Luminor
Patek Philippe
Tag Heuer
Only from $189 Each :- Click below link
[Link 1]     [Link 2]

arm burst dare embarrass pronunciation circumstances, not times tears bear?
----nul8vjos2pgd4b9eh2b5gi35f-- From mjrcolors@dimondbros.com Sat Sep 08 16:23:08 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IU6pg-00054u-Tl; Sat, 08 Sep 2007 16:23:08 -0400 Received: from chello089079068240.chello.pl ([89.79.68.240] helo=papanast-dm8z4h.chello.pl) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IU6pg-0006iS-95; Sat, 08 Sep 2007 16:23:08 -0400 Received: from papanastdm8z4h ([63.218.213.114]:44394 "HELO papanastdm8z4h" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by f0444f59dimondbros.com with ESMTP id 1169FE6051FB74 (ORCPT ); Sat, 8 Sep 2007 22:23:04 +0200 Message-ID: <001101c7f266$d3020760$0218da14@papanastdm8z4h> From: Lori Pope To: ccamp-archive@ietf.org Subject: you to christian Date: Sat, 8 Sep 2007 22:23:04 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C7F266.D3020760" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.1106 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2720.1158 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C7F266.D3020760 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable field of view is fundamentally limited, and these displays assienment in part given to our computer class was to connect easy to think= of all the possibilities, and easier to forget that ------=_NextPart_000_000E_01C7F266.D3020760 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable

relearning, from scratch, of all things dealing with social

Are you wanting a bigger p e n _i s?

As se -e -n on TV

Over 749,000 Men around the world are already satisfied
Gain 2+ Inches In Leng _th
Increase Your P _en -is Wi _dth (Girth) By up _to 23%
100% Safe To Take, With NO Side Effects
No Pum ps! No Surg ery! No Ex ercises!
*3 FREE Bottles

writing a program that will simulate these things, I'm not
------=_NextPart_000_000E_01C7F266.D3020760-- From Amanda-pillai@telerecording.co.uk Sat Sep 08 23:01:40 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUD3M-0002lV-TT for ccamp-archive@ietf.org; Sat, 08 Sep 2007 23:01:40 -0400 Received: from b-internet.87.103.242.109.snt.ru ([87.103.242.109]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUD3L-00088B-O5 for ccamp-archive@ietf.org; Sat, 08 Sep 2007 23:01:40 -0400 Received: by 10.96.84.181 with SMTP id MjyFjgqgKiost; Sun, 9 Sep 2007 10:01:42 +0700 (GMT) Received: by 192.168.174.191 with SMTP id GmFUJpaNIKtJqF.1436916983983; Sun, 9 Sep 2007 10:01:40 +0700 (GMT) Message-ID: <000201c7f28d$bce3e170$6df26757@ngts19d28455e7> From: "Amanda pillai" To: Subject: ekac-mul Date: Sun, 9 Sep 2007 10:01:37 +0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C7F2C8.6942B970" 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: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0005_01C7F2C8.6942B970 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable http://hoodoski.com/ Yo pillai wishing you had a bigger one-eyed wonder? and do something about it Alistair jakucinskas ------=_NextPart_000_0005_01C7F2C8.6942B970 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
Yo pillai
wishing you had a bigger one-eyed wonder? and = do=20 something about it
Alistair jakucinskas
------=_NextPart_000_0005_01C7F2C8.6942B970-- From alt@mailusb.com Sun Sep 09 00:54:25 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUEoT-00049N-Go for ccamp-archive@ietf.org; Sun, 09 Sep 2007 00:54:25 -0400 Received: from [125.187.32.244] (helo=m19.mailyes.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUEoS-0001XS-Oy for ccamp-archive@ietf.org; Sun, 09 Sep 2007 00:54:25 -0400 Received: (qmail 5687 invoked by uid 0); 9 Sep 2007 13:31:54 +0900 Message-ID: <20070909043154.5686.qmail@m19.mailyes.net> To: ccamp-archive Subject: =?ISO-2022-JP?B?GyRCOiMkSiRpPlIycCRKJDcbKEI=?= =?ISO-2022-JP?B?GyRCJEdCKEVQTz8yRBsoQg==?= From: freemail Reply-to: delivery_rt Date: 2007-09-09 13:30:02 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: GOOD Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20070907183805_cbvm Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 3.6 (+++) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 $B!!!!!!(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B!!!!!!!!!z!!$46a=j=P2q$$$+$i$N!!$*!!F@!!>p!!Js!!!z(B $B!!!!!!(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B!!!!!!!!!!!!"v(BVIP$B=w@-$N$4>R2p"v!AB(2q$$$X$NF;!A(B $B!!!!(Bhttp://black-6969.org.uk/pc/index2.php?u9psp4$B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!(B $B!?!@!?!@!?!@!?!@!?!@!?!@!?!@!?!@!?!@!?!@!?!@!?!@!?!@!?!@!?!@!?!@!?(B $B!@!?:G=*9pCN(B!!$B!!%3%l$rF($7$?$i5.J}$NL$Mh$O!&!&!&L5$$(B!! $B(#!=!=($WD(B $B!C!@!?('!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=(B $B(&!=!=(%(B $B!!%2%j%i%$%Y%s%H=*N;$^$G$"$H$o$:$+!*(B $B!!4JC1EPO?!u7G<(HD=q$-9~$_$G4JC1$K!_!_$,!*#2=54VJg=8$7$F$*$j$^$9!#%.%j%.%jEPO?$G!!$b==J,;q3J$OF@$i$l$^$9(B? $B!!(Bhttp://black-6969.org.uk/pc/index2.php?u9psp4 $B!!(B $B!!LGB?$K$*L\$K$+$+$l$J$$(BVIP$B2q0wMM$H$N$*IU$-9g$$$H%P%C%/%"%C%W$r"v(B> $B!~(,(,(,(,"!(,!~(,"!(,!~(,"!(,!~(B -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- $B"#"""#(B http://black-6969.org.uk/pc/index2.php?u9psp4 $B"#"""#(B $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!($(B $B:G9bJv=P2q$$%5%$%H!*!X$46a=j=P2q$$!Y(B URL $B!'(B http://black-6969.org.uk/pc/index2.php?u9psp4 $B$3$N%a!<%k$K=q$+$l$?FbMF$NL5CG7G:\!"L5CGJ#@=$r6X$8$^$9!#(B Copyright (C) 2007 gokinjo All Rights Reserved. $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(%(B $B"(G[?.Dd;_$O$3$A$i$+$i(B notmail@gmail.com From ercan_korumer@racsoftware.com Sun Sep 09 01:04:18 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUEy2-0007t7-B2 for ccamp-archive@megatron.ietf.org; Sun, 09 Sep 2007 01:04:18 -0400 Received: from [125.123.80.226] (helo=[125.123.80.226]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUExy-0001h9-Rz for ccamp-archive@megatron.ietf.org; Sun, 09 Sep 2007 01:04:17 -0400 Received: from microsof-jnf1ci ([119.117.140.141] helo=microsof-jnf1ci) by [125.123.80.226] ( sendmail 8.13.3/8.13.1) with esmtpa id 1ZJXZa-000NEK-tJ for ccamp-archive@megatron.ietf.org; Sun, 9 Sep 2007 13:05:01 +0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 9 Sep 2007 13:04:46 +0800 To: ccamp-archive@megatron.ietf.org From: "ercan korumer" Subject: efterh}n Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.1 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Wassup ccamp-archive Say hello to my little friend, well big friend now Kai Scheper http://www.hrdmin.com/ From ositei@assetresource.net Sun Sep 09 03:47:49 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUHWH-0007N7-DX for ccamp-archive@ietf.org; Sun, 09 Sep 2007 03:47:49 -0400 Received: from clr75.neoplus.adsl.tpnet.pl ([83.31.119.75] helo=assetresource.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IUHWH-0004jC-0K for ccamp-archive@ietf.org; Sun, 09 Sep 2007 03:47:49 -0400 Message-ID: Reply-To: "DTamika KManley" From: "DTamika KManley" Subject: yo To: Date: Sun, 09 Sep 2007 09:47:57 +0100 MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed hello Rickey This one will skyrocket, checksymbol-chvc Get in now, else regret later Rufus From vvqk47sxsh@typepad.com Sun Sep 09 11:13:20 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUOTQ-0007Om-D2; Sun, 09 Sep 2007 11:13:20 -0400 Received: from [41.248.6.150] (helo=haykg) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IUOTN-00050R-Da; Sun, 09 Sep 2007 11:13:20 -0400 To: From: "Alease Margherita" Subject: 80% Save Codeine,Valiun,XanaK,AmbienK,PhenterminK,ViagraK,CialiK, SomaK fzdku Message-ID: <02322b38088.513e19235673@typepad.com> Date: Sun, 09 Sep 2007 17:13:06 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--weh1prko2tpv0f8yhppbmdi8264t" X-Spam-Score: 2.3 (++) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d ----weh1prko2tpv0f8yhppbmdi8264t Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit PharmaShop 80% Discount - Discreet Packaging - Cheapest Medication - Worldwide shipping - Buy in Bulk and Save CodeineK XanaxK ValiumK PhenterminK ViagraK ViagraGelK CialiK CialiKSoftTabs ViagraSoftTabsK SomaK AdalatK AllegraK AmbienK AtaraxK AtivanK CiproK EffexorK GlucophageK LevitraK LipitorK MeridiaK NorvascK PaxilK PropeciaK ProzacK UltramK ZocorK Zoloftk ZybanK plus 30 meds more http://keygwe.kjbottom.com (Link 1) http://kvld.kjbottom.com (Link 2) ----weh1prko2tpv0f8yhppbmdi8264t Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
PharmaShop 80% Discount
Discreet Packaging
Cheapest Medication
Worldwide shipping
Buy in Bulk and Save
CodeineK
XanaxK
ValiumK
PhenterminK
ViagraK
ViagraGelK
CialiK
CialiKSoftTabs
ViagraSoftTabsK
SomaK
AdalatK
AllegraK
AmbienK
AtaraxK
AtivanK
CiproK
EffexorK
GlucophageK
LevitraK
LipitorK
MeridiaK
NorvascK
PaxilK
PropeciaK
ProzacK
UltramK
ZocorK
ZoloftK
ZybanK
plus 30 meds more
Buy Here - start from (link A)
(link B)

room truth important talked, independent knew next captain garden person number,



----weh1prko2tpv0f8yhppbmdi8264t-- From owner-ccamp@ops.ietf.org Sun Sep 09 11:24:55 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUOed-0002DZ-HJ for ccamp-archive@ietf.org; Sun, 09 Sep 2007 11:24:55 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUOeb-0005N2-3G for ccamp-archive@ietf.org; Sun, 09 Sep 2007 11:24:55 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IUOT8-000IpB-Vj for ccamp-data@psg.com; Sun, 09 Sep 2007 15:13:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [209.191.85.60] (helo=web36809.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IUOT4-000IoP-FY for ccamp@ops.ietf.org; Sun, 09 Sep 2007 15:13:00 +0000 Received: (qmail 55500 invoked by uid 60001); 9 Sep 2007 15:12:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=ZlTo74nB5RW2M5XHWYnXReoM5XcQupF4W1OBiW6h6Xwl7f6p89ZFqFUBD3Q5QBV+VcfHJLGiyPP8IVr3tCjbGuoV76Bp/jX/L4in1veQ1MuIOfvuSDzCbdt/s48QwVbL2Of9fcyU/8b0YwGloMTOrzm5p6Ffy7NvKeyeBgTafYQ=; X-YMail-OSG: Wx2WZE8VM1nk32oyTNipDm6IPYZUOx0.9WTB6zNU Received: from [68.98.133.125] by web36809.mail.mud.yahoo.com via HTTP; Sun, 09 Sep 2007 08:12:57 PDT Date: Sun, 9 Sep 2007 08:12:57 -0700 (PDT) From: Igor Bryskin Subject: RE: Closing the GELS Mailing List To: PAPADIMITRIOU Dimitri , neil.2.harrison@bt.com, adrian@olddog.co.uk, zali@cisco.com, Attila.Takacs@ericsson.com, ccamp@ops.ietf.org, gels@rtg.ietf.org Cc: rcallon@juniper.net In-Reply-To: <8144761F31F48D43AD53D09F5350E380013214BD@FRVELSMBS22.ad2.ad.alcatel.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1831663776-1189350777=:55044" Content-Transfer-Encoding: 8bit Message-ID: <790583.55044.qm@web36809.mail.mud.yahoo.com> Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd --0-1831663776-1189350777=:55044 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dimitri, Please, see in line. Igor PAPADIMITRIOU Dimitri wrote: igor > The conclusions in the context of co Ethernet: > > a) Data plane label is something determined only by > IEEE, because it exists independently from any Control Plane: > Ethernet connections could be configured by NMS without any > Control Plane (no control plane labels at all). As far as > CCAMP is concerned, data plane label is untouchable; IEEE 802.1 does not deal with the data plane in that sense. it defines "control" of forwarding components it is an issue we need to consider. we are not taking a data plane specification in its basic sense for which CCAMP adds a control plane. IB>> I totally disagree. That is exactly what we should do in CCAMP and my understanding is that this is what operators expect us to do. to the modes 802.1 currently considers MSTP (domain-wide bridging through spanning tree), SPB (shortest-path tree bridging) and PBB-TE (for which we have no outline so far) result in specification detailing operations of forwarding components. if i take the latter its is intended to "support provisioning systems that explicitly select traffic engineered paths within Provider Backbone Bridge Networks (P802.1ah) by allowing a network operator to disable unknown destination address forwarding and source address learning for administratively selected VLAN Identifiers, while allowing other network control protocols to dynamically determine active topologies for other services." ... far from being a data plane specification in its base sense. > b) Control plane label is always a subset of data > plane and is an essential subject of CCAMP discussions: is it > DMAC/VID? just VID? nothing as in case of statically > configured connections? Is it network-scope? node-scope? > link-scope? Stuff like that. i will use examples to make this clearer to allow something along the PBB-TE line work is ongoing to define states which force the port state being learning off and forwarding on (for all VID allocated to PBB-TE but not to MSTP), disable broadcast/unknown unicast while allowing filtering of unicast only (both are control of MAC relay operations), etc. -> all these control-driven operation fall outside CCAMP scope (at least as far as my understanding goes) IB>> Again, this is exactly opposite to my understanding. IMO we should consider only connection-oriented Ethernet, such as 802.1ay for PBB-TE or, say, 802.1xyz for VID cross-connected Ethernet (only after such data plane is endorsed by IEEE). We should not consider any connectionless Ethernet (802.1ad,ah, etc.).: GMPLS so far is/was all about connections and nothing else: to correct deficiencies of connectionless Ethernet native control plane ((R,M)STPs) in CCAMP IMO is as inappropriate as correcting deficiencies of MPLS in ITU (I mean designing T-MPLS) Cheers, Igor -> the question is not "IEEE defines the data plane and IETF the control plane" => the question is which control components can CCAMP consider that complements amended 802.1ah bridge control & operation: data path setup/provisioning mechanism (explicit source-initiated routing) ? traffic engineering which first requires to see which TE model IEEE will consider ? others ? -d. > -----Original Message----- > From: Igor Bryskin [mailto:i_bryskin@yahoo.com] > Sent: Saturday, September 08, 2007 3:36 PM > To: PAPADIMITRIOU Dimitri; neil.2.harrison@bt.com; > adrian@olddog.co.uk; zali@cisco.com; > Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org > Cc: rcallon@juniper.net > Subject: RE: Closing the GELS Mailing List > > Dimitri, > > As Neil correctly pointed out, there is a great > advantage in having connection source ID within label of > every packet forwarded over the connection (and MPLS's great > deficiency is the lack of LSP source ID in the MPLS label). > The source ID must be within the (data plane) label and not > anywhere else, because the label constitutes Layer > Information (LI) in ITU terms, and only LI is accessible to a > server layer that claims transparency for its clients. On the > other hand source MA in co Ethernet is not used for packet > forwarding, hence it should not be signaled as a part of the > (control plane) label, which is information that must be put > by an upstream node into the packet header, so that the > downstream node could recognize and properly forward the packet. > > The conclusions in the context of co Ethernet: > > a) Data plane label is something determined only by > IEEE, because it exists independently from any Control Plane: > Ethernet connections could be configured by NMS without any > Control Plane (no control plane labels at all). As far as > CCAMP is concerned, data plane label is untouchable; > b) Control plane label is always a subset of data > plane and is an essential subject of CCAMP discussions: is it > DMAC/VID? just VID? nothing as in case of statically > configured connections? Is it network-scope? node-scope? > link-scope? Stuff like that. > > Cheers, > Igor > > > > > > So, IMO IEEE should be responsible for the definition of data > > plane labels, while CCAMP for control plane labels. > > a label distribution protocol is a set of procedures by > which one node > informs another of the label/FEC bindings it has made > > if these labels are distributed via the gmpls control > plane driving > population of the LIBs to which difference are u > pointing out here ? so, > not sure to see the point (whatever the number of > levels of indirection > between the fwd'ing plane encoding and control plane > encoding u will > always fall back on the former, the label distribution protocol > exchanges a piece of information used by the nodes to > perform their > forwarding decision) > > -d. > > > -----Original Message----- > > From: Igor Bryskin [mailto:i_bryskin@yahoo.com] > > Sent: Friday, September 07, 2007 9:21 PM > > To: neil.2.harrison@bt.com; PAPADIMITRIOU Dimitri; > > adrian@olddog.co.uk; zali@cisco.com; > > Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; > gels@rtg.ietf.org > > Cc: rcallon@juniper.net > > Subject: RE: Closing the GELS Mailing List > > > > Hi Neil, > > > > I think there is a difference between a "data plane label" > > which is a Layer Information (LI) used by a given server > > layer and a "control plane label", which is a piece of > > information signaled between adjacent controllers for the > > purpose of connection provisioning. IMO the former is always > > a superset of the latter. Let's take, for instance, > > connection oriented Ethernet. MAC SA is a very important part > > of the data plane label because it identifies the source of > > the connection. However, the connection frames are forwarded > > according to MAC DA/VID, and hence connection ingress node, > > for example, needs only be signaled with this tuple by the > > downstream neighbor, hence the control plane label is MAC > > DA/VID (or just VID, for those who like the idea of the VID > > cross-connects architecture). > > > > So, IMO IEEE should be responsible for the definition of data > > plane labels, while CCAMP for control plane labels. > > > > Cheers, > > Igor > > > > > > neil.2.harrison@bt.com wrote: > > > > Dimitri wrote 07 September 2007 16:36 in response to Adrian > > > > > > > > > > This is also something we would expect to describe within > > > > CCAMP although > > > > "what is a label" would come to us from the data plane > > > specification. > > > > > > do i interpreet correctly your statement that if the > > > specification that CCAMP is going to receive from IEEE does > > > not speak about "label" and its encoding there will be no > > > place to discuss any "label processing" and "label > > > distribution" protocol in IETF - being domain-wide or > > link-local > > > - > > > > > > in that case, isn't the .1Q specification outside scope of > > > this effort since not referring - as of today at least - to > > > any "label" semantic as part of the Ethernet frame header > > > information field ? > > > > > > thanks, > > > -d. > > > > What do you think a MAC DA, MAC SA and VID are? These > > are all 'labels'. > > > > You also have to remember that the nature of the labels > > required in a > > traffic unit are determined by the type of the network > > mode one is > > dealing with. > > > > In the co-cs and co-ps modes we have a construction known as a > > 'connection'. This implies specific architectural > > requirements....but > > the most significant, for this discussion at least, is > > that a connection > > must have a single source. What this means is that one > > does not have to > > incorporate a SA label in a co mode traffic > > unit....under defect-free > > conditions it is redundant information as the > > connection itself provides > > the source information. {Compare this to the cl-ps mode > > which does not > > have connections...here having a SA in the traffic unit > > is essential} > > > > Ergo why co-cs and co-ps mode technologies to date that > > respect the > > requirements of a connection have only focussed on > > incorporating a DA > > (forwarding) label. Further, these forwarding labels > > only need to be > > distinct in resolving some number (N say) of different > > client layer > > (link-connection) instances within a server layer > > (network connection) > > resource partition. However, there are advantages from > > having both a SA > > and DA label in a co-ps traffic unit that are network > > unique and not > > just link-connection unique (ie not swapped)....the > > inherent robustness > > under misconnectivity defects (without any adjunct OAM > > flow) is one of > > these. And of course, these are the nature of the > > native labels one > > already gets in Ethernet due to its cl-ps mode origins. > > So why would > > one even contemplate not using these since they are > > already there? > > > > The VID label is slightly different in that one can > > consider it as a > > 'route discriminator label' and a local extension to > > the SA or DA, ie it > > provides the ability to identify disjoint paths between > > nodal end > > points. > > > > The mere fact IEEE may not refer to the above > > quantities as 'labels' > > does not change the fact that this is what they are. So > > I'm not clear > > what your real point is here. > > > > regards, Neil > > > > > > > > > > ________________________________ > > > > Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge > > > ions/222> to see what's on, when. > > > > > > > ________________________________ > > Ready for the edge of your seat? Check out tonight's top > picks > on > Yahoo! TV. > --------------------------------- Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. --0-1831663776-1189350777=:55044 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Dimitri,
 
Please, see in line.
 
Igor

PAPADIMITRIOU Dimitri <Dimitri.Papadimitriou@alcatel-lucent.be> wrote:
igor

> The conclusions in the context of co Ethernet:
>
> a) Data plane label is something determined only by
> IEEE, because it exists independently from any Control Plane:
> Ethernet connections could be configured by NMS without any
> Control Plane (no control plane labels at all). As far as
> CCAMP is concerned, data plane label is untouchable;


IEEE 802.1 does not deal with the data plane in that sense. it defines
"control" of forwarding components it is an issue we need to consider.

we are not taking a data plane specification in its basic sense for
which CCAMP adds a control plane.
 
IB>>  I totally disagree. That is exactly what we should do in CCAMP and my understanding is that this is what operators expect us to do.
 
 to the modes 802.1 currently considers
MSTP (domain-wide bridging through spanning tree), SPB (shortest-path
tree bridging) and PBB-TE (for which we have no outline so far) result
in specification detailing operations of forwarding components.

if i take the latter its is intended to "support provisioning systems
that explicitly select traffic engineered paths within Provider Backbone
Bridge Networks (P802.1ah) by allowing a network operator to disable
unknown destination address forwarding and source address learning for
administratively selected VLAN Identifiers, while allowing other network
control protocols to dynamically determine active topologies for other
services." ... far from being a data plane specification in its base
sense.


> b) Control plane label is always a subset of data
> plane and is an essential subject of CCAMP discussions: is it
> DMAC/VID? just VID? nothing as in case of statically
> configured connections? Is it network-scope? node-scope?
> link-scope? Stuff like that.


i will use examples to make this clearer to allow something along the
PBB-TE line work is ongoing to define states which force the port state
being learning off and forwarding on (for all VID allocated to PBB-TE
but not to MSTP), disable broadcast/unknown unicast while allowing
filtering of unicast only (both are control of MAC relay operations),
etc. -> all these control-driven operation fall outside CCAMP scope (at
least as far as my understanding goes)
 
IB>> Again, this is exactly opposite to my understanding. IMO we should consider only connection-oriented Ethernet, such as 802.1ay for PBB-TE or, say, 802.1xyz for VID cross-connected Ethernet (only after such data plane is endorsed by IEEE). We should not consider any connectionless Ethernet (802.1ad,ah, etc.).: GMPLS so far  is/was all about connections and nothing else: to correct deficiencies of connectionless Ethernet native control plane ((R,M)STPs) in CCAMP IMO is as inappropriate as correcting deficiencies of MPLS in ITU (I mean designing T-MPLS)
 
Cheers,
Igor  


-> the question is not "IEEE defines the data plane and IETF the control
plane"


=> the question is which control components can CCAMP consider that
complements amended 802.1ah bridge control & operation: data path
setup/provisioning mechanism (explicit source-initiated routing) ?
traffic engineering which first requires to see which TE model IEEE will
consider ? others ?



-d.
> -----Original Message-----
> From: Igor Bryskin [mailto:i_bryskin@yahoo.com]
> Sent: Saturday, September 08, 2007 3:36 PM
> To: PAPADIMITRIOU Dimitri; neil.2.harrison@bt.com;
> adrian@olddog.co.uk; zali@cisco.com;
> Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org
> Cc: rcallon@juniper.net
> Subject: RE: Closing the GELS Mailing List
>
> Dimitri,
>
> As Neil correctly pointed out, there is a great
> advantage in having connection source ID within label of
> every packet forwarded over the connection (and MPLS's great
> deficiency is the lack of LSP source ID in the MPLS label).
> The source ID must be within the (data plane) label and not
> anywhere else, because the label constitutes Layer
> Information (LI) in ITU terms, and only LI is accessible to a
> server layer that claims transparency for its clients. On the
> other hand source MA in co Ethernet is not used for packet
> forwarding, hence it should not be signaled as a part of the
> (control plane) label, which is information that must be put
> by an upstream node into the packet header, so that the
> downstream node could recognize and properly forward the packet.
>
> The conclusions in the context of co Ethernet:
>
> a) Data plane label is something determined only by
> IEEE, because it exists independently from any Control Plane:
> Ethernet connections could be configured by NMS without any
> Control Plane (no control plane labels at all). As far as
> CCAMP is concerned, data plane label is untouchable;
> b) Control plane label is always a subset of data
> plane and is an essential subject of CCAMP discussions: is it
> DMAC/VID? just VID? nothing as in case of statically
> configured connections? Is it network-scope? node-scope?
> link-scope? Stuff like that.
>
> Cheers,
> Igor
>
>
>
>
> > So, IMO IEEE should be responsible for the definition of data
> > plane labels, while CCAMP for control plane labels.
>
> a label distribution protocol is a set of procedures by
> which one node
> informs another of the label/FEC bindings it has made
>
> if these labels are distributed via the gmpls control
> plane driving
> population of the LIBs to which difference are u
> pointing out here ? so,
> not sure to see the point (whatever the number of
> levels of indirection
> between the fwd'ing plane encoding and control plane
> encoding u will
> always fall back on the former, the label distribution protocol
> exchanges a piece of information used by the nodes to
> perform their
> forwarding decision)
>
> -d.
>
> > -----Original Message-----
> > From: Igor Bryskin [mailto:i_bryskin@yahoo.com]
> > Sent: Friday, September 07, 2007 9:21 PM
> > To: neil.2.harrison@bt.com; PAPADIMITRIOU Dimitri;
> > adrian@olddog.co.uk; zali@cisco.com;
> > Attila.Takacs@ericsson.com; ccamp@ops.ietf.org;
> gels@rtg.ietf.org
> > Cc: rcallon@juniper.net
> > Subject: RE: Closing the GELS Mailing List
> >
> > Hi Neil,
> >
> > I think there is a difference between a "data plane label"
> > which is a Layer Information (LI) used by a given server
> > layer and a "control plane label", which is a piece of
> > information signaled between adjacent controllers for the
> > purpose of connection provisioning. IMO the former is always
> > a superset of the latter. Let's take, for instance,
> > connection oriented Ethernet. MAC SA is a very important part
> > of the data plane label because it identifies the source of
> > the connection. However, the connection frames are forwarded
> > according to MAC DA/VID, and hence connection ingress node,
> > for example, needs only be signaled with this tuple by the
> > downstream neighbor, hence the control plane label is MAC
> > DA/VID (or just VID, for those who like the idea of the VID
> > cross-connects architecture).
> >
> > So, IMO IEEE should be responsible for the definition of data
> > plane labels, while CCAMP for control plane labels.
> >
> > Cheers,
> > Igor
> >
> >
> > neil.2.harrison@bt.com wrote:
> >
> > Dimitri wrote 07 September 2007 16:36 in response to Adrian
> >
> > > >
> > > > This is also something we would expect to describe within
> > > > CCAMP although
> > > > "what is a label" would come to us from the data plane
> > > specification.
> > >
> > > do i interpreet correctly your statement that if the
> > > specification that CCAMP is going to receive from IEEE does
> > > not speak about "label" and its encoding there will be no
> > > place to discuss any "label processing" and "label
> > > distribution" protocol in IETF - being domain-wide or
> > link-local
> > > -
> > >
> > > in that case, isn't the .1Q specification outside scope of
> > > this effort since not referring - as of today at least - to
> > > any "label" semantic as part of the Ethernet frame header
> > > information field ?
> > >
> > > thanks,
> > > -d.
> >
> > What do you think a MAC DA, MAC SA and VID are? These
> > are all 'labels'.
> >
> > You also have to remember that the nature of the labels
> > required in a
> > traffic unit are determined by the type of the network
> > mode one is
> > dealing with.
> >
> > In the co-cs and co-ps modes we have a construction known as a
> > 'connection'. This implies specific architectural
> > requirements....but
> > the most significant, for this discussion at least, is
> > that a connection
> > must have a single source. What this means is that one
> > does not have to
> > incorporate a SA label in a co mode traffic
> > unit....under defect-free
> > conditions it is redundant information as the
> > connection itself provides
> > the source information. {Compare this to the cl-ps mode
> > which does not
> > have connections...here having a SA in the traffic unit
> > is essential}
> >
> > Ergo why co-cs and co-ps mode technologies to date that
> > respect the
> > requirements of a connection have only focussed on
> > incorporating a DA
> > (forwarding) label. Further, these forwarding labels
> > only need to be
> > distinct in resolving some number (N say) of different
> > client layer
> > (link-connection) instances within a server layer
> > (network connection)
> > resource partition. However, there are advantages from
> > having both a SA
> > and DA label in a co-ps traffic unit that are network
> > unique and not
> > just link-connection unique (ie not swapped)....the
> > inherent robustness
> > under misconnectivity defects (without any adjunct OAM
> > flow) is one of
> > these. And of course, these are the nature of the
> > native labels one
> > already gets in Ethernet due to its cl-ps mode origins.
> > So why would
> > one even contemplate not using these since they are
> > already there?
> >
> > The VID label is slightly different in that one can
> > consider it as a
> > 'route discriminator label' and a local extension to
> > the SA or DA, ie it
> > provides the ability to identify disjoint paths between
> > nodal end
> > points.
> >
> > The mere fact IEEE may not refer to the above
> > quantities as 'labels'
> > does not change the fact that this is what they are. So
> > I'm not clear
> > what your real point is here.
> >
> > regards, Neil
> >
> >
> >
> >
> > ________________________________
> >
> > Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge
> > > ions/222> to see what's on, when.
> >
>
>
>
>
> ________________________________
>
> Ready for the edge of your seat? Check out tonight's top
> picks
> on
> Yahoo! TV.
>


 


Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. --0-1831663776-1189350777=:55044-- From Bardur_Robbs@croisiere-nature.com Sun Sep 09 11:56:31 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUP9D-0006PQ-VG for ccamp-archive@ietf.org; Sun, 09 Sep 2007 11:56:31 -0400 Received: from host7-121-dynamic.12-79-r.retail.telecomitalia.it ([79.12.121.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUP98-00087f-4y for ccamp-archive@ietf.org; Sun, 09 Sep 2007 11:56:31 -0400 Received: from pc by croisiere-nature.com with ASMTP id 2184900E for ; Sun, 9 Sep 2007 17:53:52 +0200 Received: from pc ([151.106.90.100]) by croisiere-nature.com with ESMTP id 19BF993A59FD for ; Sun, 9 Sep 2007 17:53:52 +0200 Message-ID: <000d01c7f2f9$8851f700$07790c4f@pc> From: "Bardur Robbs" To: Subject: edulcer Date: Sun, 9 Sep 2007 17:53:15 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7F30A.4BDAC700" 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: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0007_01C7F30A.4BDAC700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://smitana.com/ Good day Robbs Ooze confidence in every situation with your bigger and better penis Karthik Kamilis ------=_NextPart_000_0007_01C7F30A.4BDAC700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://smitana.com/
Good day Robbs
Ooze confidence in every situation with your = bigger and=20 better penis
Karthik Kamilis
------=_NextPart_000_0007_01C7F30A.4BDAC700-- From Najum@mdhelicopters.co.uk Sun Sep 09 12:22:41 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUPYX-0005CC-FU for ccamp-archive@megatron.ietf.org; Sun, 09 Sep 2007 12:22:41 -0400 Received: from e178135154.adsl.alicedsl.de ([85.178.135.154] helo=e178177014.adsl.alicedsl.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUPYV-0000Gs-OH for ccamp-archive@megatron.ietf.org; Sun, 09 Sep 2007 12:22:41 -0400 Received: from bjk1903 ([114.130.40.67]:31898 "EHLO bjk1903" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by e178177014.adsl.alicedsl.de with ESMTP id S22ZCQQLXCBLNDKE (ORCPT ); Sun, 9 Sep 2007 18:22:54 +0200 Message-ID: <000b01c7f2fd$a3aed460$0eb1b255@bjk1903> From: "Najum Joanisse" To: Subject: lppanhoj Date: Sun, 9 Sep 2007 18:22:39 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7F30E.6737A460" 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: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0007_01C7F30E.6737A460 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://skitkit.com/ Yo Joanisse Adding inches to your cock.. aron lintunen ------=_NextPart_000_0007_01C7F30E.6737A460 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://skitkit.com/
Yo Joanisse
Adding inches to your cock..
aron lintunen
------=_NextPart_000_0007_01C7F30E.6737A460-- From jim@mac.com Sun Sep 09 18:06:03 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUUup-0002vz-AK for ccamp-archive@ietf.org; Sun, 09 Sep 2007 18:06:03 -0400 Received: from c911df2e.bhz.virtua.com.br ([201.17.223.46]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUUum-0006sr-8S for ccamp-archive@ietf.org; Sun, 09 Sep 2007 18:06:03 -0400 Received: from [201.17.223.46] by nserver2.apple.com; Sun, 09 Sep 2007 22:06:12 +0000 Message-ID: <000801c7f32d$03d01db6$62f8b8b4@botheqj> From: "gan garson" To: Subject: Local representatives wanted. Really high wages, no investment is required. Date: Sun, 09 Sep 2007 20:18:49 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C7F32D.03CC80C7" 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: 1.5 (+) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C7F32D.03CC80C7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, First and Primarily, we would kindly like to express our deep greetings = to you and your relatives and wish you all good health and happiness and = more success in business. Our International Company is looking for new = employees on various vacancies. We are by now for a long time in the = market and now we employ employees to work from home.=20 Our Company Head Office is positioned in United Kingdom with branches = all over the world. Our supreme wish now is to enlarge our business = level to more countries, so we are advertising here in hope of = cooperating with you all. We be grateful for sincere and ingenious = employers. You do not need to invest any sum of money and we do not ask = you to provide us with your bank account number! We are occupied in = totally officially authorized activity and working in our company you = can achieve career growth at a permanent job. We are looking for a highly motivated professional, with experience of = working with people. The position is home-based. We offer a part-time = position with flexible working hours. And we would be happy to consider = a full-time job share candidate. The right person will have good communication and interpersonal skills = and some knowledge of advertising. Candidates must be able to remain = focused and motivated when working alone.=20 Thank you and we are looking forward to cooperate in long term base with = you all. If you are interested in our vacancies, please feel free to make contact = with us for further information. The preference is given to people with understanding of foreign = languages. If you are interested please send next information to: = ReggieSanfordGA@gmail.com 1) Full name=20 2) Contact phone numbers 3) Languages=20 4) Part time job/Full time We are looking forward to hearing from you soon. Best Regards, keefer jim ------=_NextPart_000_0005_01C7F32D.03CC80C7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello,
First and Primarily, we would kindly like to express our deep greetings = to you and your relatives and wish you all good health and happiness and = more success in business. Our International Company is looking for new = employees on various vacancies. We are by now for a long time in the = market and now we employ employees to work from home.

=20 Our Company Head Office is positioned in United Kingdom with branches = all over the world. Our supreme wish now is to enlarge our business = level to more countries, so we are advertising here in hope of = cooperating with you all. We be grateful for sincere and ingenious = employers. You do not need to invest any sum of money and we do not ask = you to provide us with your bank account number! We are occupied in = totally officially authorized activity and working in our company you = can achieve career growth at a permanent job.

=20 We are looking for a highly motivated professional, with experience of = working with people. The position is home-based. We offer a part-time = position with flexible working hours. And we would be happy to consider = a full-time job share candidate.

=20 The right person will have good communication and interpersonal skills = and some knowledge of advertising. Candidates must be able to remain = focused and motivated when working alone.

Thank you and we are looking forward to cooperate in long term base with = you all.
If you are interested in our vacancies, please feel free to make contact = with us for further information.
The preference is given to people with understanding of foreign = languages. If you are interested please send next information to: = ReggieSanfordGA@gmail.com
1) Full name
2) Contact phone numbers
3) Languages
4) Part time job/Full time

We are looking forward to hearing from you soon.

Best Regards,
keefer jim ------=_NextPart_000_0005_01C7F32D.03CC80C7-- From jonell@stswithuns.com Sun Sep 09 19:15:17 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUVzo-0005o9-Ui for ccamp-archive@ietf.org; Sun, 09 Sep 2007 19:15:17 -0400 Received: from ppp85-141-207-45.pppoe.mtu-net.ru ([85.141.207.45]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUVzo-0008AS-4a for ccamp-archive@ietf.org; Sun, 09 Sep 2007 19:15:16 -0400 Received: from [85.141.207.45] by dns01e.hants.gov.uk; Sun, 09 Sep 2007 23:15:21 +0000 Message-ID: <000701c7f337$0308badb$3be0628d@wlovogb> From: "bernarr hung" To: Subject: IMMEDIATE cash to spend ANY way you like Date: Sun, 09 Sep 2007 21:27:58 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C7F337.0305409A" 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: 3.5 (+++) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C7F337.0305409A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No Hassle Business Loans! If you have your own business and want: - IMMEDIATE cash to spend ANY way you like - Extra money to give the business a boost. Worried that your credit is less than perfect? Not an issue. Just call the number below. You'll thank me later! Call Free 1-877-208-5642 24 hours a day, 7 days a week including Sundays and Holidays! ------=_NextPart_000_0004_01C7F337.0305409A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

No Hassle Business Loans!

If you have your own business and = want:

- IMMEDIATE cash to spend ANY way you = like
- Extra money to give the business a boost.

Worried that your credit is less than = perfect? Not an issue.

Just call the number = below.

You'll thank me later!

Call Free = 1-877-208-5642

24 hours a day, 7 days a week = including Sundays and Holidays!

------=_NextPart_000_0004_01C7F337.0305409A-- From rle3dil@belgacom.net Mon Sep 10 04:08:54 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUeKE-0006mY-18; Mon, 10 Sep 2007 04:08:54 -0400 Received: from host-ip2-44.crowley.pl ([85.128.44.2] helo=xmhgrbd) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IUeKD-00051O-Av; Mon, 10 Sep 2007 04:08:53 -0400 To: From: "Therese Ferne" Subject: Let's upgrade yourPenis, add 2 inches longer nfkn Message-ID: <34437n71348.031a42655190@belgacom.net> Date: Mon, 10 Sep 2007 10:09:51 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--kuivtil9ft7qnarh8kk1v05ive7" X-Spam-Score: 2.0 (++) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c ----kuivtil9ft7qnarh8kk1v05ive7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Safe & Effective PenisEnlargement Over 1,500,000 bottles sold worldwide WeOffer Full MoneyBack Guarantee if you are not completely satisfied with the results of Man-XL, you have nothing to lose, just a lot to gain 1) Gain Up to 3+ Inches In Length 2) Increase YourPenis Width (Girth) By upto 20% 3) Help Stop PrematureEjaculation! 4) Produce Stronger, Rock HardErections 5) 100% Safe To Take, With NO Side Effects 6) Fast Shipping WorldWide 7) Doctor Approved And Recommended 8) No Pumps, No Surgery, No Exercises 9) Very discrete shipping and billing 10) Up to 3 FREE Bottles Of Man-XL 11) Highly secure 128bit order processing Buy This herbal EnlargementPills here http://doeod.kjofthe.com http://dbfcw.kjofthe.com ----kuivtil9ft7qnarh8kk1v05ive7 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Safe & Effective PenisEnlargement
Over 1,500,000 bottles sold worldwide
WeOffer Full MoneyBack Guarantee if you are not completely satisfied with the results of Man-XL, you have nothing to lose, just a lot to gain
1) Gain Up to 3+ Inches In Length
2) Increase YourPenis Width (Girth) By upto 20%
3) Help Stop PrematureEjaculation!
4) Produce Stronger, Rock HardErections
5) 100% Safe To Take, With NO Side Effects
6) Fast Shipping WorldWide
7) Doctor Approved And Recommended
8) No Pumps, No Surgery, No Exercises
9) Very discrete shipping and billing
10) Up to 3 FREE Bottles Of Man-XL
11) Highly secure 128bit order processing
Did you know... Man-XL was featured in leading mens magazines such as FHM, MAXIM, plus many others, and rated No.1 choice forPenisEnlargement Also seen on TV
Buy This herbal EnlargementPills here (Link 1)
(Link 2)




with pray favorite twenty-one social. gray six course changed?
----kuivtil9ft7qnarh8kk1v05ive7-- From leander@strykercorp.com Mon Sep 10 08:35:59 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUiUh-0004b0-BN for ccamp-archive@ietf.org; Mon, 10 Sep 2007 08:35:59 -0400 Received: from [77.239.188.29] (helo=77.239.188.29) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUiUg-0004UB-Cs for ccamp-archive@ietf.org; Mon, 10 Sep 2007 08:35:59 -0400 Received: from [77.239.188.29] by NS1-AUTH.SPRINTLINK.NET; Mon, 10 Sep 2007 12:38:57 +0000 Message-ID: <000601c7f3a7$011ada3e$e07996bb@kkivo> From: "jon abhiram" To: Subject: Just call the number below Date: Mon, 10 Sep 2007 10:51:34 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7F3A7.01156312" 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: 3.8 (+++) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C7F3A7.01156312 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No Hassle Business Loans! If you have your own business and want: IMMEDIATE cash to spend ANY way you like Extra money to give the = business a boost.orried that your credit is less than perfect? Not an = issue. Just call the number below. You'll thank me later! Call Free 1 [877] 2 0 8 5 6 4 2 24 hours a day, 7 days a week including Sundays and Holidays! ------=_NextPart_000_0003_01C7F3A7.01156312 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Call Free 1 [877] 2 = 0 8 5 6 4 2

24 hours a day, 7 days a week including Sundays and = Holidays!

------=_NextPart_000_0003_01C7F3A7.01156312-- From owner-ccamp@ops.ietf.org Mon Sep 10 08:52:41 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUikr-0008EM-Br for ccamp-archive@ietf.org; Mon, 10 Sep 2007 08:52:41 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUikp-00045t-Ve for ccamp-archive@ietf.org; Mon, 10 Sep 2007 08:52:41 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IUiYj-000CaV-DV for ccamp-data@psg.com; Mon, 10 Sep 2007 12:40:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [217.32.164.137] (helo=smtp1.smtp.bt.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IUiYf-000CZV-SW for ccamp@ops.ietf.org; Mon, 10 Sep 2007 12:40:07 +0000 Received: from E03MVY1-UKDY.domain1.systemhost.net ([193.113.30.58]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 13:40:03 +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: Closing the GELS Mailing List Date: Mon, 10 Sep 2007 13:40:01 +0100 Message-ID: In-Reply-To: <8144761F31F48D43AD53D09F5350E380013214BD@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing the GELS Mailing List Thread-Index: AcfyHT6Fns26LJYEQlGdFkPBvk9UrAAAJN+wAGI6+4A= From: To: , , , , , , , Cc: X-OriginalArrivalTime: 10 Sep 2007 12:40:03.0598 (UTC) FILETIME=[B5A5D2E0:01C7F3A7] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc Colleagues, It would appear to me that we are going around in circles and that they are basically the same circles that we have gone around before. This would incorrectly imply that we have gone nowhere. IMO the path is quite simple and outlined in Adrian's e-mail dated 5th September. The design team produce documents (1) & (2) ("GMPLS Extensions for PE to PE Ethernet Label Switched Paths(LSPs)" & "GMPLS control of P2P TE for PBB-TE (802.1Qay)"). The second document describes our understanding of the 802.1Qay data plane including swapping rules. We liaise these to IEEE and if we got them (i.e. our understanding of the data plane) right then we can go ahead and define the data plane specific control protocol machinery. If we didn't quite get them right IEEE tell us and we adjust the documents accordingly. So let's wait & see what the design team create & what the IEEE reaction to those documents is. Ben owner-ccamp@ops.ietf.org <> wrote: > igor >=20 >> The conclusions in the context of co Ethernet: >>=20 >> a) Data plane label is something determined only by >> IEEE, because it exists independently from any Control Plane: >> Ethernet connections could be configured by NMS without any Control >> Plane (no control plane labels at all). As far as CCAMP is concerned, >> data plane label is untouchable; >=20 >=20 > IEEE 802.1 does not deal with the data plane in that sense. > it defines "control" of forwarding components it is an issue > we need to consider. >=20 > we are not taking a data plane specification in its basic > sense for which CCAMP adds a control plane. to the modes > 802.1 currently considers MSTP (domain-wide bridging through > spanning tree), SPB (shortest-path tree bridging) and PBB-TE > (for which we have no outline so far) result in specification > detailing operations of forwarding components. >=20 > if i take the latter its is intended to "support provisioning > systems that explicitly select traffic engineered paths > within Provider Backbone Bridge Networks (P802.1ah) by > allowing a network operator to disable unknown destination > address forwarding and source address learning for > administratively selected VLAN Identifiers, while allowing > other network control protocols to dynamically determine > active topologies for other services." ... far from being a > data plane specification in its base sense. >=20 >=20 >> b) Control plane label is always a subset of data >> plane and is an essential subject of CCAMP discussions: is it >> DMAC/VID? just VID? nothing as in case of statically configured >> connections? Is it network-scope? node-scope? >> link-scope? Stuff like that. >=20 >=20 > i will use examples to make this clearer to allow something along the > PBB-TE line work is ongoing to define states which force the > port state > being learning off and forwarding on (for all VID allocated to PBB-TE > but not to MSTP), disable broadcast/unknown unicast while allowing > filtering of unicast only (both are control of MAC relay operations), > etc. -> all these control-driven operation fall outside CCAMP > scope (at > least as far as my understanding goes) >=20 >=20 > -> the question is not "IEEE defines the data plane and IETF > the control > plane" >=20 >=20 > =3D> the question is which control components can CCAMP consider that > complements amended 802.1ah bridge control & operation: data path > setup/provisioning mechanism (explicit source-initiated routing) ? > traffic engineering which first requires to see which TE > model IEEE will > consider ? others ? >=20 >=20 >=20 > -d. >> -----Original Message----- >> From: Igor Bryskin [mailto:i_bryskin@yahoo.com] >> Sent: Saturday, September 08, 2007 3:36 PM >> To: PAPADIMITRIOU Dimitri; neil.2.harrison@bt.com; >> adrian@olddog.co.uk; zali@cisco.com; >> Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org >> Cc: rcallon@juniper.net Subject: RE: Closing the GELS Mailing List >>=20 >> Dimitri, >>=20 >> As Neil correctly pointed out, there is a great >> advantage in having connection source ID within label of >> every packet forwarded over the connection (and MPLS's great >> deficiency is the lack of LSP source ID in the MPLS label). >> The source ID must be within the (data plane) label and not >> anywhere else, because the label constitutes Layer >> Information (LI) in ITU terms, and only LI is accessible to a >> server layer that claims transparency for its clients. On the >> other hand source MA in co Ethernet is not used for packet >> forwarding, hence it should not be signaled as a part of the >> (control plane) label, which is information that must be put >> by an upstream node into the packet header, so that the >> downstream node could recognize and properly forward the packet. >>=20 >> The conclusions in the context of co Ethernet: >>=20 >> a) Data plane label is something determined only by >> IEEE, because it exists independently from any Control Plane: >> Ethernet connections could be configured by NMS without any >> Control Plane (no control plane labels at all). As far as >> CCAMP is concerned, data plane label is untouchable; >> b) Control plane label is always a subset of data >> plane and is an essential subject of CCAMP discussions: is it >> DMAC/VID? just VID? nothing as in case of statically >> configured connections? Is it network-scope? node-scope? link-scope? >> Stuff like that.=20 >>=20 >> Cheers, >> Igor >>=20 >>=20 >>=20 >>=20 >> > So, IMO IEEE should be responsible for the definition of data >> > plane labels, while CCAMP for control plane labels. >>=20 >> a label distribution protocol is a set of procedures by >> which one node >> informs another of the label/FEC bindings it has made >>=20 >> if these labels are distributed via the gmpls control >> plane driving >> population of the LIBs to which difference are u >> pointing out here ? so, >> not sure to see the point (whatever the number of >> levels of indirection >> between the fwd'ing plane encoding and control plane >> encoding u will >> always fall back on the former, the label distribution protocol >> exchanges a piece of information used by the nodes to >> perform their >> forwarding decision) >>=20 >> -d. >>=20 >> > -----Original Message----- >> > From: Igor Bryskin [mailto:i_bryskin@yahoo.com] >> > Sent: Friday, September 07, 2007 9:21 PM >> > To: neil.2.harrison@bt.com; PAPADIMITRIOU Dimitri; >> > adrian@olddog.co.uk; zali@cisco.com; >> > Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; >> gels@rtg.ietf.org >> > Cc: rcallon@juniper.net >> > Subject: RE: Closing the GELS Mailing List >> > >> > Hi Neil, >> > >> > I think there is a difference between a "data plane label" >> > which is a Layer Information (LI) used by a given server >> > layer and a "control plane label", which is a piece of >> > information signaled between adjacent controllers for the >> > purpose of connection provisioning. IMO the former is always >> > a superset of the latter. Let's take, for instance, >> > connection oriented Ethernet. MAC SA is a very important part >> > of the data plane label because it identifies the source of >> > the connection. However, the connection frames are forwarded >> > according to MAC DA/VID, and hence connection ingress node, >> > for example, needs only be signaled with this tuple by the >> > downstream neighbor, hence the control plane label is MAC >> > DA/VID (or just VID, for those who like the idea of the VID >> > cross-connects architecture). >> > >> > So, IMO IEEE should be responsible for the definition of data >> > plane labels, while CCAMP for control plane labels. > >> > Cheers, >> > Igor >> > >> > >> > neil.2.harrison@bt.com wrote: >> > >> > Dimitri wrote 07 September 2007 16:36 in response to Adrian > >> > > > >> > > > This is also something we would expect to describe within > >> > > CCAMP although > > > "what is a label" would come to us from >> the data plane > > specification. > > >> > > do i interpreet correctly your statement that if the >> > > specification that CCAMP is going to receive from IEEE does >> > > not speak about "label" and its encoding there will be no >> > > place to discuss any "label processing" and "label >> > > distribution" protocol in IETF - being domain-wide or > >> link-local > > - >> > > >> > > in that case, isn't the .1Q specification outside scope of >> > > this effort since not referring - as of today at least - to >> > > any "label" semantic as part of the Ethernet frame header > > >> information field ? > > >> > > thanks, >> > > -d. >> > >> > What do you think a MAC DA, MAC SA and VID are? These > are all >> 'labels'. > >> > You also have to remember that the nature of the labels > >> required in a > traffic unit are determined by the type of the >> network > mode one is > dealing with. >> > >> > In the co-cs and co-ps modes we have a construction known as a >> > 'connection'. This implies specific architectural > >> requirements....but > the most significant, for this discussion at >> least, is > that a connection > must have a single source. What >> this means is that one > does not have to > incorporate a SA label >> in a co mode traffic > unit....under defect-free >> > conditions it is redundant information as the >> > connection itself provides >> > the source information. {Compare this to the cl-ps mode > which >> does not > have connections...here having a SA in the traffic unit >> > is essential} > >> > Ergo why co-cs and co-ps mode technologies to date that > >> respect the > requirements of a connection have only focussed on > >> incorporating a DA > (forwarding) label. Further, these forwarding >> labels > only need to be > distinct in resolving some number (N >> say) of different > client layer > (link-connection) instances >> within a server layer > (network connection) > resource partition. >> However, there are advantages from > having both a SA > and DA >> label in a co-ps traffic unit that are network > unique and not > >> just link-connection unique (ie not swapped)....the > inherent >> robustness > under misconnectivity defects (without any adjunct OAM >> > flow) is one of > these. And of course, these are the nature of >> the > native labels one > already gets in Ethernet due to its >> cl-ps mode origins. > So why would > one even contemplate not >> using these since they are > already there? > > The VID label is >> slightly different in that one can > consider it as a > 'route >> discriminator label' and a local extension to > the SA or DA, ie >> it > provides the ability to identify disjoint paths between > >> nodal end > points. > >> > The mere fact IEEE may not refer to the above >> > quantities as 'labels' >> > does not change the fact that this is what they are. So > I'm >> not clear > what your real point is here. >> > >> > regards, Neil >> > >> > >> > >> > >> > ________________________________ >> > >> > Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge >> > > ions/222> to see what's on, when. >> > >>=20 >>=20 >>=20 >>=20 >> ________________________________ >>=20 >> Ready for the edge of your seat? Check out tonight's top >> picks >> on >> Yahoo! TV. From Mindaugas-onesyda@gumasol.de Mon Sep 10 11:32:03 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUlF5-0005VQ-47 for ccamp-archive@ietf.org; Mon, 10 Sep 2007 11:32:03 -0400 Received: from m252.class147.petrotel.pl ([217.28.147.252]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUlF4-0002H0-CQ for ccamp-archive@ietf.org; Mon, 10 Sep 2007 11:32:02 -0400 Received: from labolatorium ([150.168.84.175]:5852 "EHLO labolatorium" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by m252.class147.petrotel.pl with ESMTP id S22FELIUVXXZOXRR (ORCPT ); Mon, 10 Sep 2007 17:32:03 +0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 Sep 2007 17:31:38 +0200 To: ccamp-archive@ietf.org From: "Mindaugas onesyda" Subject: panozneb Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.0 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Yo ccamp-archive My wife complains about my small cock ALL THE TIME! jenifer hew http://luisio.com/ From Weizhe.MacMartin@gumasol.de Mon Sep 10 11:39:56 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUlMi-0002d0-4F for ccamp-archive@ietf.org; Mon, 10 Sep 2007 11:39:56 -0400 Received: from m252.class147.petrotel.pl ([217.28.147.252]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUlMh-0002TB-F5 for ccamp-archive@ietf.org; Mon, 10 Sep 2007 11:39:56 -0400 Received: by 10.144.57.27 with SMTP id XofFDGDrKpjxy; Mon, 10 Sep 2007 17:39:36 +0200 (GMT) Received: by 192.168.73.84 with SMTP id dTHenfgUyCwedr.3786255070390; Mon, 10 Sep 2007 17:39:34 +0200 (GMT) Message-ID: <000901c7f3c0$c7f65af0$fc931cd9@labolatorium> From: "Weizhe MacMartin" To: Subject: parille Date: Mon, 10 Sep 2007 17:39:31 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7F3D1.8B7F2AF0" 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.0 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0003_01C7F3D1.8B7F2AF0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable http://mensange.com/ Yo MacMartin VERY easy and VERY effective cock nlargement Espen Cobb ------=_NextPart_000_0003_01C7F3D1.8B7F2AF0 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
http://mensange.com/
Yo MacMartin
VERY easy and VERY effective cock = nlargement
Espen Cobb
------=_NextPart_000_0003_01C7F3D1.8B7F2AF0-- From Nana@gumasol.de Mon Sep 10 11:46:50 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUlTO-0006mP-02 for ccamp-archive@ietf.org; Mon, 10 Sep 2007 11:46:50 -0400 Received: from m252.class147.petrotel.pl ([217.28.147.252]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUlTN-0002dk-AQ for ccamp-archive@ietf.org; Mon, 10 Sep 2007 11:46:49 -0400 Received: from labolatorium ([126.163.4.179]:18598 "EHLO labolatorium" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by m252.class147.petrotel.pl with ESMTP id S22YBXZPRKJKBLCS (ORCPT ); Mon, 10 Sep 2007 17:46:42 +0200 Message-ID: <000701c7f3c1$beb5ed60$fc931cd9@labolatorium> From: "Nana Rambaldini" To: Subject: parquent Date: Mon, 10 Sep 2007 17:46:25 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7F3D2.823EBD60" 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.0 (++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0003_01C7F3D2.823EBD60 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable http://ltibia.com/ Good day Nana I fill her whole mouth now Pranitha Gottesman ------=_NextPart_000_0003_01C7F3D2.823EBD60 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
http://ltibia.com/
Good day Nana
I fill her whole mouth now
Pranitha Gottesman
------=_NextPart_000_0003_01C7F3D2.823EBD60-- From zwv1tmbyl@laposte.net Mon Sep 10 12:32:48 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUmBs-0000Tm-F7; Mon, 10 Sep 2007 12:32:48 -0400 Received: from [222.68.241.249] (helo=156.154.24.150) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IUmBr-0003xE-Ei; Mon, 10 Sep 2007 12:32:48 -0400 To: dccp@ietf.org From: "Jannet Vera" Subject: -== Buy SwissRep|ica iRolex online, Great selection of fine QualityWatches bridge Message-ID: <453c64415.38l16667286@unisys.com> Date: Mon, 10 Sep 2007 11:32:41 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--o9dvlrxxcjqcm2ngaz17jd0hx" X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 ----o9dvlrxxcjqcm2ngaz17jd0hx Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Super Branded Watches (85% Price Off) : RolexMen : RolexLady : Alain Silberstein : Audemars Piguet : Breitling : Bvlgari : Cartier : Chanel : Chopard : Franck Muller : IWC : Jaeger-Lecoultre : Omega : Panerai Luminor : Patek Philippe : Tag Heuer Only from $189 Each :- Click below link http://rcraot.kkcuptea.com http://rccwje.kkcuptea.com ----o9dvlrxxcjqcm2ngaz17jd0hx Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Super Branded Watches (85% Price Off)
RolexMen
RolexLady
Alain Silberstein
Audemars Piguet
Breitling
Bvlgari
Cartier
Chanel
Chopard
Franck Muller
IWC
Jaeger-Lecoultre
Omega
Panerai Luminor
Patek Philippe
Tag Heuer
Only from $189 Each :- Click below link
[Link 1]     [Link 2]

address fancy added was pleasure, was letter or perhaps journey?
----o9dvlrxxcjqcm2ngaz17jd0hx-- From dfdsf@101bridalshowertips.com Mon Sep 10 19:30:55 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUsiV-0003BW-PM for ccamp-archive@megatron.ietf.org; Mon, 10 Sep 2007 19:30:55 -0400 Received: from [190.156.45.100] (helo=Dynamic-IP-19015645100.cable.net.co) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUsiU-0000le-03 for ccamp-archive@megatron.ietf.org; Mon, 10 Sep 2007 19:30:55 -0400 Received: by 10.92.25.118 with SMTP id FNjjPBXhFGmdV; Mon, 10 Sep 2007 18:31:11 -0500 (GMT) Received: by 192.168.20.144 with SMTP id jaPkzscBGvJLQc.9308066194711; Mon, 10 Sep 2007 18:31:09 -0500 (GMT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 Sep 2007 18:31:06 -0500 To: ccamp-archive@megatron.ietf.org From: "Rasmei dfdsf" Subject: tilaicos Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Antivirus: avast! (VPS 000774-1, 10/09/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 2.1 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Wazzup ccamp-archive A girl once told me i was too small.. alonzo Finnie http://maqxtr.com/ From sssd87bgeb@varig.com Mon Sep 10 23:48:47 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUwk3-0006bK-OY for ccamp-archive@ietf.org; Mon, 10 Sep 2007 23:48:47 -0400 Received: from h-66-167-215-158.sfldmidn.dynamic.covad.net ([66.167.215.158] helo=pomakf) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IUwk3-0006a5-Ad for ccamp-archive@ietf.org; Mon, 10 Sep 2007 23:48:47 -0400 To: From: "Natisha Nancy" Subject: 80% Save Codeine, Valiun,XanaK,AmbienK,PhenterminK,ViagraK,CialiK, SomaK xlzqc Message-ID: <62327s31919.9458o54768193@varig.com> Date: Mon, 10 Sep 2007 23:48:55 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--lr1crc9fwbwsz2kd8z1bmo1rtq8f" X-Spam-Score: 2.7 (++) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 ----lr1crc9fwbwsz2kd8z1bmo1rtq8f Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit PharmaShop 80% Discount - Discreet Packaging - Cheapest Medication - Worldwide shipping - Buy in Bulk and Save CodeineK XanaxK ValiumK PhenterminK ViagraK ViagraGelK CialiK CialiKSoftTabs ViagraSoftTabsK SomaK AdalatK AllegraK AmbienK AtaraxK AtivanK CiproK EffexorK GlucophageK LevitraK LipitorK MeridiaK NorvascK PaxilK PropeciaK ProzacK UltramK ZocorK Zoloftk ZybanK plus 30 meds more http://kjuu.kkroomin.com (Link 1) http://knmgjs.kkroomin.com (Link 2) ----lr1crc9fwbwsz2kd8z1bmo1rtq8f Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
PharmaShop 80% Discount
Discreet Packaging
Cheapest Medication
Worldwide shipping
Buy in Bulk and Save
CodeineK
XanaxK
ValiumK
PhenterminK
ViagraK
ViagraGelK
CialiK
CialiKSoftTabs
ViagraSoftTabsK
SomaK
AdalatK
AllegraK
AmbienK
AtaraxK
AtivanK
CiproK
EffexorK
GlucophageK
LevitraK
LipitorK
MeridiaK
NorvascK
PaxilK
PropeciaK
ProzacK
UltramK
ZocorK
ZoloftK
ZybanK
plus 30 meds more
Buy Here - start from (link A)
(link B)

account principle second wrong. matter argue become showed worthy wrong.



----lr1crc9fwbwsz2kd8z1bmo1rtq8f-- From xrems@bluepoint.com.mx Tue Sep 11 03:39:42 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV0LW-0000wn-BU; Tue, 11 Sep 2007 03:39:42 -0400 Received: from mail.wci-group.com ([63.144.4.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IV0LV-0003cX-PK; Tue, 11 Sep 2007 03:39:42 -0400 Received: from [63.144.4.11] by srvmailgb.bluepoint.com.mx; Tue, 11 Sep 2007 02:43:04 -0500 Date: Tue, 11 Sep 2007 02:43:04 -0500 From: "Cornelia Yoder" X-Mailer: The Bat! (v2.12.00) Business Reply-To: xrems@bluepoint.com.mx X-Priority: 3 (Normal) Message-ID: <729019154.30638476228308@bluepoint.com.mx> To: ccamp-archive@ietf.org Subject: Hello ! MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Hi ! I am Elen. I would like to get acquainted with you. If not you against write to me here on address hellga@m4-cross.com I will wait very much Bye From Magnusson@activinnovation.ch Tue Sep 11 06:11:16 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV2iB-0004kp-WD for ccamp-archive@ietf.org; Tue, 11 Sep 2007 06:11:16 -0400 Received: from host150-160-dynamic.16-87-r.retail.telecomitalia.it ([87.16.160.150] helo=host117-122-dynamic.59-82-r.retail.telecomitalia.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IV2iA-00066h-Ef for ccamp-archive@ietf.org; Tue, 11 Sep 2007 06:11:15 -0400 Received: by 10.220.90.166 with SMTP id CqskTrtMJVJhR; Tue, 11 Sep 2007 12:10:59 +0200 (GMT) Received: by 192.168.194.8 with SMTP id nrzwlBblzHqEyy.7821221824041; Tue, 11 Sep 2007 12:10:57 +0200 (GMT) Message-ID: <000b01c7f45c$09fd43f0$757a3b52@Stefano> From: "Timo Magnusson" To: Subject: sabp Date: Tue, 11 Sep 2007 12:10:54 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C7F46C.CD8613F0" 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.9 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0005_01C7F46C.CD8613F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://lustaus.com/ Yo ccamp-archive ladies like em big, so i enlarged mine.. samantha Nisbett ------=_NextPart_000_0005_01C7F46C.CD8613F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://lustaus.com/
Yo ccamp-archive
ladies like em big, so i enlarged = mine..
samantha Nisbett
------=_NextPart_000_0005_01C7F46C.CD8613F0-- From Amzad.Ka@activinnovation.ch Tue Sep 11 06:15:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV2lp-0000jm-HP for ccamp-archive@megatron.ietf.org; Tue, 11 Sep 2007 06:15:01 -0400 Received: from host150-160-dynamic.16-87-r.retail.telecomitalia.it ([87.16.160.150] helo=host117-122-dynamic.59-82-r.retail.telecomitalia.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IV2lo-0007aL-Sm for ccamp-archive@megatron.ietf.org; Tue, 11 Sep 2007 06:15:01 -0400 Received: from Stefano by activinnovation.ch with ASMTP id E4AD5B0A for ; Tue, 11 Sep 2007 12:15:02 +0200 Received: from Stefano ([138.160.173.104]) by activinnovation.ch with ESMTP id 20F25DBAA6A0 for ; Tue, 11 Sep 2007 12:15:02 +0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 11 Sep 2007 12:14:40 +0200 To: ccamp-archive@megatron.ietf.org From: "Amzad Ka" Subject: saimouni Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Hi bro Amzad My wife complains about my small cock ALL THE TIME! fsadf Rogachevsky http://mamulaat.com/ From zqshowed@nwinsure.com Tue Sep 11 10:54:36 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV78O-0002sN-6p; Tue, 11 Sep 2007 10:54:36 -0400 Received: from gfq62.internetdsl.tpnet.pl ([83.12.146.62]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IV78M-00053o-EU; Tue, 11 Sep 2007 10:54:36 -0400 Received: from komputerdom1 ([88.195.244.139]:28257 "HELO komputerdom1" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 3e920c53nwinsure.com with ESMTP id h1PBBICP475333 (ORCPT ); Tue, 11 Sep 2007 16:54:51 +0200 Message-ID: <001301c7f494$782d99a0$02043fc4@komputerdom1> From: spring is To: ccamp-archive@ietf.org Subject: tterrorism Date: Tue, 11 Sep 2007 16:54:51 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C7F494.782D99A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.1409 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.181 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C7F494.782D99A0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable will inevitably be affected by the immense amount of information possibilities it provides, are virtually endless. There are lots The incre= ases in technology have made communicating in the ------=_NextPart_000_0010_01C7F494.782D99A0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable

file standards, reproduction rights, appropriation, modification,

Are you wanting a bigger p e n _i s?

As se -e -n on TV

Over 722,000 Men around the world are already satisfied
Gain 2+ Inches In Leng _th
Increase Your P _en -is Wi _dth (Girth) By up _to 26%
100% Safe To Take, With NO Side Effects
No Pum ps! No Surg ery! No Ex ercises!
*3 FREE Bottles

are real there is no problem. We will never create V.R. so
------=_NextPart_000_0010_01C7F494.782D99A0-- From doalpine@advansoftusa.com Tue Sep 11 11:04:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV7Hl-00021R-Fk; Tue, 11 Sep 2007 11:04:17 -0400 Received: from dwb63.neoplus.adsl.tpnet.pl ([83.22.61.63]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IV7HZ-0005C3-8I; Tue, 11 Sep 2007 11:04:17 -0400 Received: from user121209f863 ([135.162.236.234]:13907 "HELO user121209f863" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 3f3d1653advansoftusa.com with ESMTP id b3KCATTI247291 (ORCPT ); Tue, 11 Sep 2007 16:45:33 +0200 Message-ID: <000f01c7f493$2d7a7b40$06b9459c@user121209f863> From: Lester V. Billings To: ccamp-archive@ietf.org Subject: do dues Date: Tue, 11 Sep 2007 16:45:33 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C7F493.2D7A7B40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2963 X-Mimeole: Produced By Microsoft MimeOLE V6.00.3790.181 X-Spam-Score: 2.1 (++) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C7F493.2D7A7B40 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Even these computer scientists are becoming artists. This is why by technology always - modern techno conveniences such as the association. = The dream to achieve machine intelligence that is ------=_NextPart_000_000C_01C7F493.2D7A7B40 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable

model is feasible. A viewer can circle the display sphere and
=

Are you wanting a bigger p e n _i s?

As se -e -n on TV

Over 709,000 Men around the world are already satisfied
Gain 3+ Inches In Leng _th
Increase Your P _en -is Wi _dth (Girth) By up _to 24%
100% Safe To Take, With NO Side Effects
No Pum ps! No Surg ery! No Ex ercises!
*3 FREE Bottles

be perfected in the next ten years are generally the same people
= ------=_NextPart_000_000C_01C7F493.2D7A7B40-- From Lasekesp@brightscreen.nl Tue Sep 11 12:34:29 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV8h3-0007dB-PC for ccamp-archive@megatron.ietf.org; Tue, 11 Sep 2007 12:34:29 -0400 Received: from [88.251.226.10] (helo=[88.244.118.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IV8h2-0002c3-EH for ccamp-archive@megatron.ietf.org; Tue, 11 Sep 2007 12:34:29 -0400 Received: from asd-5c50c1c8543 by brightscreen.nl with ASMTP id 62289A02 for ; Tue, 11 Sep 2007 19:34:18 +0300 Received: from asd-5c50c1c8543 ([140.108.58.171]) by brightscreen.nl with ESMTP id 336CBE008E27 for ; Tue, 11 Sep 2007 19:34:18 +0300 Message-ID: <000601c7f491$92e33eb0$3676f458@asd5c50c1c8543> From: "khai Lasek" To: Subject: gaminess Date: Tue, 11 Sep 2007 19:34:07 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C7F4AA.B83076B0" 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_0005_01C7F4AA.B83076B0 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable http://mylpas.com/ Good evening ccamp-archive Girls actually use to laugh at me! khai Lasek ------=_NextPart_000_0005_01C7F4AA.B83076B0 Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable
Good evening ccamp-archive
Girls actually use to laugh at = me!
khai Lasek
------=_NextPart_000_0005_01C7F4AA.B83076B0-- From khjlekdubkl@bostik.com Tue Sep 11 21:12:19 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVGmB-00046p-Sp; Tue, 11 Sep 2007 21:12:19 -0400 Received: from [125.106.55.216] (helo=[125.106.55.216]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVGm8-0006Tn-Fs; Tue, 11 Sep 2007 21:12:19 -0400 Received: from [125.106.55.216] by mail02.hou.totalfinaelf.net; Wed, 12 Sep 2007 09:15:07 +0800 From: "Renee Driscoll" To: Subject: fw: Inv update Date: Wed, 12 Sep 2007 09:15:07 +0800 Message-ID: <32c7ffa4$32c7ffa4$d8376a7d@khjlekdubkl> 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.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Importance: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d EXTREME RED HOT ALERT! Buy Wednesday September 12th 2007 WW Energy Inc Symbol : WWNG This will EXPLODED TODAY, and will again TOMORROW! Yesterday we told you this stock would sky rocket, and today it did! Moving over 4.1 million shares, and up 100%. The stock doubled, and is going to double again tomorrow! There is an odour in the air a huge press release is coming out tomorroW! Current: $.02 Expected: $.54 WWNG WAS ONE OF THE HOTTEST STOCKS TRADED, AND IS EXPECTED TO DO BETTER TOMORROW! Check 07/10/07. 2 months ago. This stock traded milions and milions of shares, over 7 million on the 2nd day. It's doing it AGAIN! TOMORROW IS THE 2ND DAY! Get in on the action Wednesday September 12th 2007! WWNG is the winner for this week! Company info: WW Energy, Inc., through its subsidiaries, provides services to the oil and gas industry. The company engages in the acquisition, exploration, exploitation, and development of leases, and oil and gas related assets. It has exploitation projects in Texas, Utah, and New Mexico. The company also engages in transporting fresh production water for oil drilling and exploration, and waste water for disposal. In addition, it provides services for heavy hauling of drilling and well equipment used in oil and gas production and exploration industry. The company also operates in Colorado and Arizona. WW Energy was founded in 1999 and is based in Farmington, New Mexico. From owner-ccamp@ops.ietf.org Wed Sep 12 02:05:00 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVLLQ-0007G6-4N for ccamp-archive@ietf.org; Wed, 12 Sep 2007 02:05:00 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVLLP-00027R-II for ccamp-archive@ietf.org; Wed, 12 Sep 2007 02:04:59 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IVLBr-0008Gl-HE for ccamp-data@psg.com; Wed, 12 Sep 2007 05:55:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [80.86.78.228] (helo=fw.testbed.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IVLBo-0008F1-M1 for ccamp@ops.ietf.org; Wed, 12 Sep 2007 05:55:06 +0000 Received: from MailerDaemon by fw.testbed.se with local-bsmtp (Exim 4.63) (envelope-from ) id 1IVLBl-0006Ne-DR for ccamp@ops.ietf.org; Wed, 12 Sep 2007 07:55:01 +0200 Received: from gw.imc.kth.se ([193.10.152.67]:4964 helo=[172.16.2.200]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1IVLBh-0006ND-5D; Wed, 12 Sep 2007 07:54:57 +0200 Message-ID: <46E77F28.4030702@pi.se> Date: Wed, 12 Sep 2007 07:54:48 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Adrian Farrel CC: PAPADIMITRIOU Dimitri , "Zafar Ali (zali)" , "Attila Takacs (IJ/ETH)" , ccamp@ops.ietf.org, gels , Ross Callon Subject: Re: Closing the GELS Mailing List References: <53CCFDD6E346CB43994852666C210E9101FB483B@esealmw116.eemea.ericsson.se> <014f01c7eb1f$3272db10$0300a8c0@your029b8cecfe> <46D7DDC6.8000205@pi.se> <020501c7f068$270d0c20$0302a8c0@your029b8cecfe> <53CCFDD6E346CB43994852666C210E9102067D40@esealmw116.eemea.ericsson.se> <8144761F31F48D43AD53D09F5350E380012B22ED@FRVELSMBS22.ad2.ad.alcatel.com> <8144761F31F48D43AD53D09F5350E380012B24AF@FRVELSMBS22.ad2.ad.alcatel.com> <039601c7f12d$69406a40$0302a8c0@your029b8cecfe> In-Reply-To: <039601c7f12d$69406a40$0302a8c0@your029b8cecfe> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-cff-SpamScore: 0(/) X-cff-SpamReport: ----- ----- 1.5 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) [SPF failed: Please see http://spf.pobox.com/why.html?sender=loa%40pi.se&ip=193.10.152.67&receiver=fw.testbed.se] -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP X-cff-LastScanner: footer Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Adrian Farrel wrote: > I think this thread is a representation in miniature of the issues > involved... > > - All the emails in this thread have been copied to both mailing lists > - All the participants in the thread are subscribed to both mailing lists > > No, it doesn't cost to have both lists active. well - it does for me, since the gels-list is not on one of the ietf-servers, and tends to be hit by quite a bit of spam and the IETF spam filters can't be applied; I have to sift through quite a bit of debris, floatsam and junk to try to find any nuggets in the stream if I've to do that for things that the wg chairs say could go to the ccamp list anyway I'd rather do something else. Adrian, when can I close the list? /Loa > No, it doesn't cost to have all of the threads on CCAMP. > > Please note that we should not discuss the data plane. If you don't > understand (or don't like, or don't want to use) the data plane you > should have your discussions in private or at the IEEE. > > Dimitri said... > >>> - Label allocation and swapping rules >> is that not a forwarding component discussion ? > > It is certainly informed by the forwarding component (i.e. the > definition of the data plane), but the rules we need to define are the > rules for the control plane. I.e. (and for example, only) if the > forwarding plane defines that the label allocated on the upstream > interface must be numerically one greater than the label allocated on > the downstream interface, this rule must be referenced in the control > plane specification. This is important since it is a constraint placed > on the normal per-interface operation of GMPLS. That makes it CCAMP work. > >> beside the fact that there is an assumption on what >> label means and how it is represented in data plane > > This is also something we would expect to describe within CCAMP although > "what is a label" would come to us from the data plane specification. > > Thanks, > Adrian > > > > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com From edjchemistry@mail2uk.com Wed Sep 12 05:53:05 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVOu9-0000s9-B5; Wed, 12 Sep 2007 05:53:05 -0400 Received: from 193-34-1-1.chelmnet.pl ([193.34.1.1]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IVOu8-0006pY-OY; Wed, 12 Sep 2007 05:53:05 -0400 Received: from xfxpkopay2rzfp ([204.169.211.50]:19351 "HELO xfxpkopay2rzfp" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 10122c1mail2uk.com with ESMTP id E841538012696 (ORCPT ); Wed, 12 Sep 2007 11:53:16 +0200 Message-ID: <001601c7f533$81527330$069e7af4@xfxpkopay2rzfp> From: Adela Waldron To: ccamp-archive@ietf.org Subject: stopic Date: Wed, 12 Sep 2007 11:53:16 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C7F533.81527330" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2462.2969 X-Spam-Score: 2.1 (++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C7F533.81527330 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable fairly narrow constraints on the type of data exchanged. There contacts and to to relay ideas is anyone's speculation. The jobs, compensat= ing for the lost occupations that were replaced by = ------=_NextPart_000_0013_01C7F533.81527330 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

musical, and visual arts, are happening already. Technology has

Are you wanting a bigger p e n _i s?

As se -e -n on TV

Over 780,000 Men around the world are already satisfied
Gain 4+ Inches In Leng _th
Increase Your P _en -is Wi _dth (Girth) By up _to 26%
100% Safe To Take, With NO Side Effects
No Pum ps! No Surg ery! No Ex ercises!
*3 FREE Bottles

VR is used along these lines, society will benefit with fewer use ------=_NextPart_000_0013_01C7F533.81527330-- From lisagreen@threelightsnews.com Wed Sep 12 07:27:10 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVQNC-0000jg-Gz; Wed, 12 Sep 2007 07:27:10 -0400 Received: from [125.133.121.50] (helo=[125.133.121.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVQNC-0000bQ-06; Wed, 12 Sep 2007 07:27:10 -0400 Received: from [125.133.121.50] by mail.threelightsnews.com; Wed, 12 Sep 2007 20:27:12 +0900 Message-ID: <01c7f52f$dcf39f10$3279857d@lisagreen> From: "Lane Brantley" To: Subject: 50mg x 30 pills $3.00 per pill Date: Wed, 12 Sep 2007 20:27:12 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252" Content-Transfer-Encoding: 7bit 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: 1.9 (+) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 US $ 69.95 Viagra 100mg x 10 pills http://bandour.com From rlymjqdx@bookpassage.com Wed Sep 12 08:16:35 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVR91-0004Xh-A1; Wed, 12 Sep 2007 08:16:35 -0400 Received: from [219.145.195.144] (helo=[219.145.195.144]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVR90-0001bz-Ec; Wed, 12 Sep 2007 08:16:34 -0400 Received: from [219.145.195.144] by mail.adventusweb.net; Wed, 12 Sep 2007 20:17:01 +0800 Message-ID: <3302ffa4$3302ffa4$90c391db@rlymjqdx> From: "Leopoldo Bonilla" To: Subject: Leopoldo has sent you a message Date: Wed, 12 Sep 2007 20:17:01 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Spam-Score: 1.8 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Hot News Tomorrow On WWNG! Yesterday we told you this stock would sky rocket, and today it did! Moving over 4.1 million shares, and up 100%. The stock doubled, and is going to double again tomorrow! There is an odour in the air a huge press release is coming out tomorrow! ww Energy Inc. Symbol : wwng Current: $.02 Expected: $.54 Wednesdays's news on WWNG will blow you away. Huge returns resulted from last months Big news release. Set your buy for open and beat the news. Get WWNG Wednesday. Morn. From scruggsbg@163.net Wed Sep 12 11:42:09 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVULx-0003aJ-QO; Wed, 12 Sep 2007 11:42:09 -0400 Received: from [87.117.253.66] (helo=bellatlantic.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVULw-0007iS-63; Wed, 12 Sep 2007 11:42:08 -0400 MIME-Version: 1.0 Message-ID: <1189611046.3804@163.net> Subject: SOLD OUT - LAST CHANCE- Rolex. Rolex Rolex. All Rolexes are here 1ov Date: Wed, 12 Sep 2007 15:30:46 +0000 To: capwap-archive@ietf.org, ccamp-archive@ietf.org, cfrg@ietf.org, cfrg-admin@ietf.org From: "Robt Scruggs" Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit X-Spam-Score: 4.7 (++++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Dear capwap-archive@ietf.org http://manuswjuu.com What is Prestige Replica store? At Prestige 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 Prestige Replica Shop! http://manuswjuu.com Thanks Rebeca Moore capwap-archive@ietf.org wrote: > SOLD OUT - LAST CHANCE- !Do you want rolex or other brander watch under 250? 6f73gw2q1v- out me now http://manuswjuu.com/remove/ From kloose@kingsolomons.com Wed Sep 12 14:09:57 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVWez-0005oI-Dp; Wed, 12 Sep 2007 14:09:57 -0400 Received: from ns.netfort.net ([194.126.211.1]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IVWey-0003Yt-Pb; Wed, 12 Sep 2007 14:09:57 -0400 Received: from f0k3xj9u6o7m0dw ([81.205.131.89]:19802 "HELO f0k3xj9u6o7m0dw" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 1d37ec2kingsolomons.com with ESMTP id 20735D11298C63 (ORCPT ); Wed, 12 Sep 2007 22:09:56 +0400 Message-ID: <001701c7f589$a6f75460$002ad02c@f0k3xj9u6o7m0dw> From: Julio Page To: ccamp-archive@ietf.org Subject: you were taking, the amount of medicine you were using, and journal Date: Wed, 12 Sep 2007 22:09:56 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C7F589.A6F75460" 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.181 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C7F589.A6F75460 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable our fellow Americans to refrain from any form of military or and remote control of space station docking. Visual artists were expected t= o explore and communicat with other users in this ------=_NextPart_000_0014_01C7F589.A6F75460 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable

see a three dimensional object from all directions while it moves

Are you wanting a bigger p e n _i s?

As se -e -n on TV

Over 744,000 Men around the world are already satisfied
Gain 4+ Inches In Leng _th
Increase Your P _en -is Wi _dth (Girth) By up _to 21%
100% Safe To Take, With NO Side Effects
No Pum ps! No Surg ery! No Ex ercises!
*3 FREE Bottles

painters who had enough self-esteem in their own interpretations, ------=_NextPart_000_0014_01C7F589.A6F75460-- From gecuba.com@tasselcreations.com Wed Sep 12 15:34:55 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVXzD-0002yO-O6 for ccamp-archive@ietf.org; Wed, 12 Sep 2007 15:34:55 -0400 Received: from [89.4.239.151] (helo=qkljdd) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IVXyd-0005yQ-QE for ccamp-archive@ietf.org; Wed, 12 Sep 2007 15:34:55 -0400 Message-ID: <000601c7f573$56397a00$0100007f@akwvwin> From: "Emmanuel Bennett" To: Subject: Why be an average guy any longer Date: Wed, 12 Sep 2007 22:34:02 +0300 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_002C_01C7F573.56397A00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 This is a multi-part message in MIME format. ------=_NextPart_000_002C_01C7F573.56397A00 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0026_01C7F573.56397A00" ------=_NextPart_001_0026_01C7F573.56397A00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See attach. http://www.lainwad.net/ ----- You promised not to leave the He really hadnt meant to shout Johanna trailed her fingers do Tis the truth you make me forg ------=_NextPart_001_0026_01C7F573.56397A00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi

------=_NextPart_001_0026_01C7F573.56397A00-- ------=_NextPart_000_002C_01C7F573.56397A00 Content-Type: image/jpeg; name="img91.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAADwAA/+4AIUFkb2JlAGTAAAAAAQMA EAMCAwYAAAlBAAAWBQAALsL/2wCEABMPDxcRFyUWFiUvJB0kLywkIyMkLDoyMjIyMjpDPT09PT09 Q0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0MBFBcXHhoeJBgYJDMkHiQzQjMpKTNCQ0I+Mj5C Q0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ//CABEIAJQCqAMBIgACEQEDEQH/ xADCAAACAwEBAQAAAAAAAAAAAAAABAIDBQEGBwEBAQEBAQEAAAAAAAAAAAAAAAEDAgQFEAABBAIB AwMDBAMBAAAAAAABAAIDBBEFEhAhEyAxFEAiBjBBMhVQIzNCEQACAQIDBAYGCQIEBQUBAAABAhEA AyExEkFRYRMQcYEiMgQgkaGxwUIw8NHhUmJyIxRQM/GCkrJAwuKTJKLSY3ODFRIAAQMDBAICAwAA AAAAAAAAEQAQASBQIUAxcRIwUUECYYGR/9oADAMBAAIRAxEAAAD2oAY+x5o+dneUckEZTulr1PQ6 WW3nWN3KX1NuRr6+cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADnQyoWL+D1wy6 jj1ZGpjaG2fqNvD3fV4QDrgAAAPF+08aeJicO97El7PE9pltdKueeoi7gWej0g9HlwIM8mlnc5yy dfFpd7I0UbJlVpySlx2/JeWyzPqjcV5OxJu1Qqaz2pXEXK7HFCYmxRQvpJU0s3DMrs1xReXTM6Vj 5l2GgZkl0TJE1hRVdUyrE0THkawhQaxmhpCVBqEJygAgls43k9Ec5zO8/rxGFmt77LUSd9nywAAA ADx/sPIng+kl7WzGX1d7UsfQlsLuVm17DHXDgGmHDoV9mAAEZBDsgrLAqVfDJ0LerXPonIzCqUwr 7MI96EOWBFVwMm2+Ngu3wz5uRFGLmTOtcJUKdDtlC70RTl95nyfsEYt8VGOsGTLQsSu0JQhSM50l ctFkr8/5/wBLLdLfRkz6rwvofR5PQFN2uIAAAeH9x80XC7GKT0czd579Rp5rfm9feU29S5rN29ce gaYAABEkLrroGRA2jMvHI5V5ocSTNoSgmhzKsNHuI8OmfQuuotjG7FMNi7zDS7pXY5QT267MSO7W ZKWy4I80unnLduRlU6TR5y3cDy93oVaZwXdOMKzZXMme2GD6CFh2uxPm9lKvjRa1ZrjrLs8f6jz+ u9J1vbzYenTo0szVn9c+lMk1z2ALyfI/rnyAUAO7WM/xp7d1CeG7yjOf3VPYeV9Vr5wDrMhPBLa2 uqtLvFtvxrktbx7hl/G6aiPKzQKuJU0rNbOSTH1WuEl6HDzjmr563RhU5NOa2P1n6MByKN55Cyui zT8x6nKKOsW1jPTaTC9Xi7MvlZ6NlmdbpKqjJ+9GrqbuegAphCzjri16fHbmXsecaef9umzO7e2I XGTMJS05OjmdxggJ6oDTJL537/zmevlldNDrmu6vie2c8r67L0XFkub1xXvXOiV2b+enNk6UZ9ao wpdfagx2ohazVHKmZWJxc5KuMzpSp0ER7onJmSZ3Xq1ope65zddFd1pL06h6ECcgBw6FXFc+zfMZ I9MZ6xsQ8/E9J3CkbnfO+hU6EAAc6qQo6t5vQ3TDhppNw14hHqXHTqkK89NGKTnfK2cxXrzcdHHp MHd8YSqZux38zm+izdMlkPT43XKevjtWfRL/AA/s8tbiznNr0vN+k1zxuSo0zT7pZFX0m4KbUyQA AAAAAAAAAAAAAAVaBJ0AAAAAAhMK+WhDsgr5bEj2a4u9KgvITAAiqwlz1mVVd+f9KrQU2NM2eT56 fJTm2qYeiquRluuxzS3yiu2pv5rSR1x6HxPt/DZ9N2Uyy2lmaCyQYT9Zpz8+T9743ri57P1eb6q7 Lbz75rIP7ZYOpU/pwU3CQmAAAAU01rWM8y3qZmjXGrTQoaVMkDSM+8ZMe6tCcM+NKWXonaZ5tMtZ /TVQaz4bpWnY7BWs9JkavnJW3cyytjJ2s2HsTRzD0GLpJFO3lapICWKL+dz0nn73M9sD0NF5bzh3 nHoEaruLBdlTqLV3A8Plzu8b7LF47x502ef0wTcVsa3cPYsd89v5ffMc6evn2RlbyY0M7R9XmAOu QAAAAAAhywIkg5yQc5IOckEF2wotkHDoR70IkggTAhMI8mEFXQ5yQQJgc6ECYQ7IIyAAAVa4Z87l 51ZKiyWyJCu871OAFartPReXZRpnBzblBOvPyDy+qOwGueLshx07QFV8DiwsCHXA9nlALyAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdAOAFALTMOepVBYSCudCORCznAHQE//9oACAECAAEF APQUXprjn66X+WMkjAb2b6nlEYTPf6DCwsLCwsLCwsLCwsdZ2FD3Pf1j2BGXYTTj6Hv07+rPTKz1 e4FrUCSmnHqf7ArBTW9/ocrKysrKysr2WVlFEor9i1NZhDuhkLIx1d0ygc/R9kFlZRWVlZ6n3JTx 9rRgE4AQCx9qc7uPYpw6A4+kwsdMLCPoc9qackpxwi9qaQV7D/y846NKBRGURhYTDkfVOOERlRg5 wnlxWExvT9pOgK90HJxXJMGB6u3Tt07LAXZdunZDC7Lsgu3QII9CiwFNZxKwsIDq8ZCAQKyj26N9 vq8foO9imewX7HoPb/B//9oACAEDAAEFAPQEGItGPrmezcNBJJf/AC6jrG1Dundgshdl2Q9+mAsB f+vddl7L2PY9M9MrPTKysrKysrPWFya3v7A9/QOmO5BAGQnt7foE5/S7foY9DAQ5oOZCE5vbqOjP c91hPcR6MLH6GFhFpHXCx0x0wsL3WFjqF+7wWN5InCIBXE56t6AkJ/XK9kUeg6/tkIhAoHsR6CsL CCwsLHUIKEZkmeHPAyT0/wDSa3s73CaR0cMgjHXBRC7Lsuy7enHQnPpz0ys+lrHItIAJBAygxyc0 hfv/AO4x3TgiEDhA5WVIPq2jJAwpiOOVGGhZUjgAFn7o+hC/YtTQsJ57n1d/T3/QPUo9WoSEJ7+Q 6ZRKz2TDgoohAZWF+7/5fV59WejfdP8Acoe/R3v/AIP/2gAIAQEAAQUA6/k1gQ0EehWMIBRQvlNf XvCbrS8VLclB1aQywrCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsIhSd5m/ytSMc0uGLjwHRTCVaUjhhYWFj0fmxAojpnKAQaMwwGw+hqWQtbXC EYA3tPlW/GrBnof5uUYsSt5C5XkEm3gMFZoc4UHOc3Ru5xev86bhOOCTlBZwmZJ0+s+Kxje2EVt3 Yo6CDwa9WY68l+nfFQPv2qwm2M5sm8+SOG9KG1ZXzRbFsDr/AMivSrP2VqBhnbFfbeuSM/upHVpN hOHHZ2IZhfsWXUb3yVvA1wEkFS0y/cmZZ2Et2i3YSxMjuWI5a01htjX3TaZuI2yzObHTtHclrYyS 363YRokqR7YxuHslrwsBbVHA6tnFnr/OvY+6xgL8fqCWZvBo+XWag5rk7sru2ZYYDkKSsJb+ypF7 HNglEETmXZoXmdzOMer83xr5Ed649tils43PpT1XzTQ7IxxRxS/Hm51LVq38mxDBFVWtiAdt4jKp aLHw19gYIoo5TRmZJXkivOnkoRuEuuY5kuyY508MAo2nxzufA7m2xe8Bm2LXRmd4kuXW1Wx7Xkx2 ydx+dKANqQ07B8SbPObVixM21SvSiOPdMe67dbVa3b8my7UxubsX2FLem5vv/HfT2IsPs25Y5Jtk 5k0mycJ33+MVjbCJ8MrZWdZYxI2RronumDZNjIXGNwD67cy0G4b6/wA5H2lMbydMOJC0dVscN7ds plly0+OrBHGtjHJYM9Bli30c3Kx2Ma8aAx1c3KDMINwvGvGvErevEzoteWytj7BmERkNbhOYhGvG vGuCLURkcF401uFbpieRms4RGiS61VM4+HK9s9OSMSa98obrXKeiJ3R1ZvNPWe+RtH/XFRliVmsZ wKcjlLTk8nw5YzJr3lS6/mq0MrHW6L5nW6Mlg2Ne+dS6+V7ZKcvOFvFvo2LQmt++7G0p0bi/Ww+S XX7p8zq0/lHq/OCPG/3gGX3McqcXlloxgsn18UxOvE6DeJcwZqkNP0HEfQXZ3QCfY1oHzXoIEy7X kjh2Faw5uxq+R92vHIcAYBWQRHM17zNEBLM1jXWoYlXvMfXbPE5kMsc7cKWVsIFhjpDgLiE+RjHc QgMdHyNYnTuKMkzxNh72v5Nne7l8eSZcSwRwsbZq2fGYrLJB6fziXMz/AHhxzkOXaZmZKpwi0Fod xWS5OHFtWIj9XKEjSUXtCz1c9rQ17Xemxfjhf/ZtQ3UIMNqKcddr/CG3DUNKN0clgHyPtR2rbHg1 qna1tHxh1YMlT2sifrTF578Z+RC981eOaGGSIlkbgHVQxrmmeSE2IAyOCvXnnruhIrzthfmGRzDn pNIIxwygrVnwsrVhXZtTFAqevbGHxfIdLNC1a6s3HxcER+NQ2nMTHh46/lsnPZOOegWhaCY2cV5X ARW4yX2GNTnulYxoa30ue1idertU+1jYPLsJTNNsoBV+RMwVXp1MvmGnrp2uiaIKUUz2a1jEdW0u rtnfJNrGPVrVQwpleRjXwXQI5Lr34shCZwkbJE4RRGZj4g57L1iN0E7ZmojKMYK4KzAZWRU5GyCI IMTmgjxosyKdhtlpbkCNGMFGLKvWPhRO2Nhji3kgxWZ2VUWByMeUY8powicL/s/2TzhtRvyJ7lgV orllznahkstXYBxEFQQx0nCexH9ye7kJJiXULRB67d5dd6M99I4c4SU1oUkIkD4AXN3pnQzjrLK2 JgmsbGOOhriYzWa7YMtTMrWLBjNiwtdYssh+ZaUs1h9gSzFEzgR2nwzDbxOXzrBUdqWO2/awltjZ Vp46uwnkiO08asbSs6c7WJyt0BaMgfWkiste5sjZmsDiC2WM0rws+i3ZkhczYunUGw5mrY+RFG9l wRsmnp0H/wBsYIGxUDWhrVXmGGQP7ROZbbZjdPW/rYWXqdOPYsknllp7LWV4RXaGM62X8GRsDGyH tflMUdaAV4t9I0MjqutWMsqxVoixs8wiZTgDY3/cp3tYJZi5QPId12fe3hBN7Gm7hLXk5MheQ8Tl o2E80keqqeFe/o2diKe1BSMz5IapXlZWebBkbVtOiYb3EwWXQJuwe4y2DI6K5K0tu5JsOa9t9rk6 2FNbII2LJE241UbYgaLrCPlR4iuyxCG4JxarsnbLC+FR2Ryj8DBJYcE2wIn9bdF0stWiYHXabhDE 0ND9ZNC52rL4m0PHYbqpGx2KAsQS6yedRDs7VzQF2s5Qmnmy7WzROOrb4b1I2o64c1vWy7m9SH7b J8tpfkw+7Ta8V4nkTSuOFc/3Pjdwaxpa2ZocZnhV3cn9NlPLFFPqRXdajDRxR92uwdXY5RlmSwni 1iAwoJetucV4dJUIZeucF5eLZLAYHWHOAZOCyieccBI+K1hbU5rwucixyMEjTJFNGQyyViynOmKb PMUObT8iRidYeEJjj5EgH9hNmxYfM2KR+YLAsDysc+c5jHUhcQiFLI2BrJ2SP4hHAXELICIaE6Zr Hk/cMIYKwEGhYQGOrzxEQyrD3tQeeFY87ZKu0W3DZlLI2NbWZ3aIB5HMBT3KZz8PYM1mjzdNjdjj FtgnWwi4hncluFyytTtXV3V7DJ01qaFhZwIX82rcvDlasNrMleQuUkrmxQMPOKRstghRTukXx7zw NZdKZq7jV/XXUNZaAfqrTgzWWo06tecjVutBrXHIU7rQKt0o0rxQq3ADRnCFS6m17YRhtqepZ5sJ AbKANZRlfL6twxj6z68Eijtshe8R+OaXya8U4BYEkfjiMr2GSNw8LYTE6r5GnPqncXunteF0t/kn 3IRHrHh7iU92VO0cbz35s2RIH7Lxo7eNV5hO2zya9nc1j/vWx2Dnud3RY5bJpAfGY5bcJBI4kHDq WydVdWmZYYGrHSKyIpFaHl2FyfyyyvJTAXN8rIV5+DKmpM7Y4mRD6OXX15TFqqsR9ZGQGYRjBRjy mtwi1OjBXjXBGMEMoCNzBgeh7uIiGVPKXOkZkGPCoWI4WNcHBrMGR7Wq3OJnvc0rth7crXzyQPut 7tHEVR/tdnGcpjcp0Yxt4OUV6HMHxvkQPqmVo+4Q4cqV2bTy1rLLDAMjitpG4tV//Tcuwsin/rHc HNOWxOetbrPiH/Ctka8qO7XlfhSXIInySsiHWb+Bk8cLzxQc4gdzQrtbFxATzhtirK9TVp2p7y05 cQyN0zxUbVFl3Jp9qYzI/wDiz3jdhF2VPGJY60Xno/jk3JXqRqzbah8SZoKo2QFG2bSup2W2IypW +Ry2zzZmqUYq3SSrFK6OFkXqt2mVIodg2R7Noxxk2zGGW7FFJXu+Z9m2K6OzjbFHsBI6vsHNgO0i ELtnxLdpG+E7SNkX9qOX9nGYjtI2xRbEPfq7b7UE9m5ydunmpSs2Hv2F0U4mbOWGSezbLzunmnXt WnF22caTScTW7oUu5eYaNid5sMfJHqGCCWxCLEWxhhamOytjWjqw2RzoNOesn8Wubwta5rwKkzE9 3jNV3KHKKb2Cc0FPhY9ANjc88muRC19fiCMiMpvdBSy8BBIGWKdd0FmMtnZa1jZYYqxbLZoSQDVT PMdGJtYPsBo14EyPtToGKT9HdZ+I6Oa7JDRcF8aXwyVpuVGCWKbZ1HTOFJ5gmhkfYNewxkFOZkTz LDYiqvmrCk90Xif8t+vk8XwnuhfE91rVskii+HKySvWswVKVR7bO0qOtwRwPkk+JI2WtWtQValR4 tR1iNjH7R0ZWKKvYiq62o+Kce1Su+KaS1O5lT5dUCctnM16FRVHVqrR1cMjxjPiYnNYjXY4V4/HG VlEL3XusJyf9rOKDDyrt4tVqPxWGnCCsN+2qRIxrz5oMNTV+R0eS19hluJtF1GxFjFhhzqf+P6cs TZWhiLAg1cVwCwuC4osCDArOvgsGOEMHBcVxXALiuKLMoRheNYRYiwIRhGMFV6MdZNGAWZQjC8fQ hcAF414wDwygzCAx6LERBBBQYuJTRgEItysEehw7PHIgYJGDCctW9rs4BB2FMcienJSkhIkMRyGF bd7saiF7JbPdN+2SxgLTn/VlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZ6ZW VlZWVlZWVlZWVlZWVlHupK7XKSJ0aEr8skyjIF5kJcrmFyCyj3RZhFhC45UHZq33/DpJ7bTx/BiV flhmVd8WKvh4n/o7/rbzjW5+P3Xdd13Xdd13Xdd13Xdd13Xdd13Xdd13Xdd13Xdd13Xdd13Xdd13 Xdd13Xdd13Xdd13Xdd13Xdd13Xdd13Xdd13Tco5z3XdTpuMswnYx2TcY6lN9jhNxyZ7f/9oACAEC AgY/AKcWCeVyuFFYiw94/bD34MrC66+YbCz4T615ldvmaDZQgon5qFiByvdGEbKXAwxQrMbNza4s 32piyf/aAAgBAwIGPwCnNgjhip5r7TQJeVn2/wCXCnRdf43FYQhZR18S0wsRt4Rr+sLr25fKHjPj Gg+pUjao6DGiIwtgjDbLMIMXNETrcsTlg80id2Hq1zZIaKZsn//aAAgBAQEGPwDpecdXd+NR6M1h Un3dGk75x4fXHfSXGzZVYxxH9ccdXu6DiJoz1iiJmrLZrAtt1ijGWo/QKNpuKPYT0T6ARaxEnoim urmneq2W1SupZbbjs4DLsjZ/XMciKgUCttQNwJYmlK4NOJqS8cKcfMCjL2H7KD/iLN6z9BYMnHWI 2YR9vurD0IGZoM+LnPh6F8/kNWEmZQP/AK+97JjoceYjTy1jUYxq4tublvWEsLOZOYnd9dtC55i2 vL+blkyvXX8fy6K3dDamJiKv2L6AOltidJwZY2VZ8v5ZF1G2H75wjd10r3EKMc1NKPMxo5XzGMdR q5e8oFIBWQDvIFC/etryjEhWOpQfZV26x7otA1z7dpeXmFLd8j3UL6oCzXOWFnhS+XRFa+RqfHuK KSxftr32jWpMRTfxUXQp067hPeI3RTI66LqGGXPtFWA/hN1dU7ttKfKt3NLG8qmVgDPr+u2udatL y81Vm7zD3VccIqqGKtiZAGmKt2tAa847qg4aYzJpbfmLYhsntyQDxmvML5dVI1klnJjqwo6l0ujF HXiK8ujiVLNI9VWh5UwXJDoDIjfTIyf+QG0C2PmnI9VDVGqMY/44OMCDnRoECTRWRIPqqNtSDj99 AbvoPL9dz/l6Z6Oa2SZddd4gVBuLPXUqZ6qxo2LRkORbVRizkn2D31PQ5uIGXQsFlkTSNbWRbM6F wkbYjbQSzadnOYdnAHXjTQCFFtVB2YV5ghSQbBUGMzu66tJ5m02gINLqDqVt3Cl5868fF4onCaFx 0Zk5WnBdWOo1dFlGBlcNET3hThQSYXAfqFXUAI1WlAOyRFC29t+ao06AuZ6931xpAykN/IDER9cK PmNJa26hW0iSpHwqwEVggfxMIk8Oqja8wjmCdLoWgjsOdNdFs2w2C6mJYjjJwqwNOoc1dWE4cae3 aVU1DYIoWrtt+aoC6QucbjV8MpDs5OmP01a80FLKECOBmONKllCV+d3BUDq41fkEA3MJ21fJBANz CdteXIBIDNPDCmhP27glWCzpO0dVf/0AplWhbcY6MvXQbfjVxSslFVlE+LUYj14bcxRZVJXlrcJD QRqOAw7aI1GP5AXP5eWMOqlmNTHSuttK9pp20qxtldfLfUNJ+YYYxtGFK9u3qV35ds6o1YE6sssP VjTqbY5qFcA3dhvm1RlnOFXNSqz2zbEW3kHW0ZwMRupxfQBlUONDapkxGQxmraXVCDRcMK2oHw54 DEfGlRQOWbbse9G1cctnXt4VY5yjQ6qofXLTpmSI2wdp40p7mhyFEXAXE4AlfvkUuWpzpXU2le00 Qqq9wMidx5U68jqj14UbZ5YdQNYe7pxOMLIxw2mKH8ZA3dV21tpjVkMAccOqrhdItiwH064YeLcM 8IzwieFXWYyItBFZoEsDtOXE0bR0FgNU231qR7IrzAYTbS2rCH0n5soG3rwimsoqnTpwZ9LNP4RG MddNZVVOkgEM+lzO1RGI7avXdP8AaLCJz0ieynVeXFvBtdwKxMT3R9sY0txcmAYdR9AqdtFWoAiT srFTEHZWmMONaRtIofQeXPG5/wAvQFG2tO7o72E51ybNvU0Yk0t7zNkclsmGMdYo6ABO6uUCRb+c jb9d1eUu2LYtKt2IgCQo1yY/THoR9ILqMUuKIDLu3HfXOuubjgQpOAHUPp7d2Y0HEfiGB94Bq5aD f3DMxkNg7KLas7ou5fl0x99KVOl0OpSRI3EEbjRW447xGoKukafwjHbtONW0ssQou6k7s6BpbP8A LPVExuos7A3Cyse73IWYXTOWM5500sO/y8FSAOW2rDH658KZmMak0YbIMzS3rzhiqsoCrGcY5nHC luowEKyMCJwaDhjnhVm2W/tadnihSvZnSoHHLU4dzvQMgTPwmlZTpdDqUkSNxBG40DccE61furA7 uzP2zTXLTKNcag6asRhIxGytVm4AxUK+tZmNuBGPsogXJDWuU5YSfmxz/NlTENDHQVMZFPfNFrjA k4AIukD3n21cKsAt1AjSsnCYIx40wLKUbY6aiv6TP+BooXBtn8aamXD5Wn4Z1ctrcC27kk92WkiM 5y7Jp2suFVzLBk1EHKVx99Bc4EeiGGdattZ418aLbFBg8aCI0QcQRXHb6dgbdT/CjQGWNYcaVaip uLNKLjFlXwhjgOygBsqd9afV/QUKx3riIZ3MYNaLjwwzwJjrjLtocxwNQldsjhGdG8rjQviJwjrn GhbttLGe7BBw6xXK1jVOnIxO7VlPbXJZu+SBpgnPKpNTU7Ka2M1Ck7u9TMWXSphjIgHjRhlDaWZd RgYbereaXmuqlsu9n1Ut+8VQGczhnFc0Ouj8UiN2da7bBl3qZ6GZgdKqXLbMPb7KNvIhVeTlDEj4 Vj0KjZuYXsBPuHoSa7g9dYED2/ZRsBi13STwXd661QZ2jcd1QRJrHupXLtYA0AoxCY+sZ0G34EVg fSs29ylvWfuqaXVgJE0YMicKLbuiejAVJmRiK5h2jD6aAR0YkehLEAcawIPo6ILNtCxh1yRXgb2f bUOrrxIw9hNTbYN1H0LX/wB1r/dV5PMHSxdmg/MpyjfhhXllcQy2rmB2Yj4YVeaJVbtl3A2gKJ+2 rZsGSEuDXGGzDs+NDy73mBgIbAtrqnhhPGZ4zV/f+1j/AJatrcCHxEG80JhHrO7tq3bYApz7ndEh Y5ZOAOz3jhT2yAPLC8utflANsH/TqidlXv48cvuRp8ORy4dVfxvk8yUc/wCTxesBavXLmdqy1gdY B1H3U/8AKjvpb0ahMqFxA7dleXcsLaBXAZ11ANq9mG2rxDB1e5byTQs6lmMTPGikDSRBFC8ZP8b9 kj8U6h7f2zTWmGojyzk/qnVP+rGsFVrYsppGa+J5q1/Lg2xbhOZ4dUmc8JiIq07nTa/fW2zYDSSu nPgMOFW7twDTz7vebiDGfGI6ZrU2J91Gv2xNxjptrx+6ozY4u21jRuBgLhzSfFXNu95jjwFELkM2 rRYUuQcWHh9dNqM3iZufCOG6tK9pqRs21DZVI9C4PwhR/wCkUOkiprAE1pMq25hFYMKHMJFo6tZX MCKCjICPSliAONd66g63FDkq10kwugYE/qyrE2rO5WOpqJXTdA3IwP30LjXNQbEaNKr7iazI/wA7 n41yvMXC6sNVuSRl4hgRwzmsoI2rhRMuYH42opcBnSrqSZlSPgfhXdZh1M321q1N/qb/AN1XLJvM rW2/ChlTlmKNy6eYwGb/AGTp9lc+AApGoKCMDhODbM5EZbqi28D9RP8Au1VKXQTuZRHsAo27rBGG I0IDqG8aj692G+p5zYf/AAj4USxGrUZPX7jumlXACSMeqjpIKqcGzY9f1xpQym3PzRBmMY7cKGIu ADvKY9h39dal7Qcx0z0aVYo2BDDh765t65zGAKr3dIE54Y41O3og9JdAQAxXH8voY0HC6iSEVcsT SWRZBvMCzLrwABjPpSR43W2sb2rGsax6dR8Kn2/d0cTTeY+RP27f/Maa4dgw69lFmJLNiTVtbkiB 7NnspfJ2MC/iIzC/aftoWUgKBVy6PAqqk7yKL7NlTkm/aai3NaW2+heLCG5jyP8AN6BQ7cjUP6+j HMVOA3kCv4/lLRI2E4+ysc/QLuYUCSaN1H/j2NjZsw37NNd+7zD+a5UeU8uLmwOYCnqJkn1RUFFQ L3wy3PCRt8OPVhSstlRImTciePhOdf20P/6/9FSlkMpZiv7gGBJ4V/YH/dH2VZY2grLrgczMQJ2d VY6B2k/AUe8rSMF0FfbqPupTdtN3LQRineiT91ftpcc8EPxru+XaPzOop3ey0siyqkMcCcaZW1KY PjUimshiS4K9xS2dIbdhiNOZZVGGFRftPb/NGpfWKs3VaVXWGwOGodVRZV7p/Ihj1mBS3F/bcjER M8GrlXNhB05yN6miUxaMgSppgQe/Gk6ZZozEzhiI9tFEAL4oyoNMDad3DOtSg24gL3sh1RjRVhpu LmvxHoAIqxEl7j6V6sjjVsWUBa4rN3mwGkgbAZFIrrpLG4pxmHQ4j3kHhlQuxAbEDhsPaMaN/wAx ZvXWYnSy+FROS47PfRN0sl2yxa09zAwMRq9xpvMX/CF5a2wcpHebrOyr9xZDHWuewGjcLtbZ1XmX ZJY9XXwq1c8rau2zzFDXHkBgdmJxondXPv2b124xJDqe6v6cdlWm8yG5i3RblpBKE7ePGltgHTo1 +I5hqbzHmJZyzBO8RoAyikRnOtb4t69uBzqyLakaryKe8cmzoIuSgAdnoGgo2dBK+KIX9RwFLaHy iKVGOB1EDeRlSIokk/X1UWPhUes1zLn9x8Tw4UztkBlQQiI7zDicY7K07BnUvjUDuruFIOPoXpxP Mf8A3H0FIqDnRUGAM67wpl8sMSMz8KUKCFBDsTm5G/cBu9FPLuxKJJe2oJLtsWKN7zK93K3YMFUA 4ZSfZRS1atkqYY6BC+zE8PXQFvKIKDhkRs7KOzOVNKskrAzJlfurFjvpyZ5bHUoHyz8DwyrKO2lx IcBtLA5ZevqrS7atp2FZ9hHVWBn2Ub6GTgpTYRPvmT7KwJ6j0I6QHDbdogys8THaBRUyDtU/X3Vu oWySyZb9L7Vw2RiKBBMEVBOB30wXS1tXZVUYMBOHCI9lECVZfEp+uPZRDQTGB2jqrTcENGDDbxoI 8oBGK+I9UVoW6+8d5oHXFK11SVOCjUBOfe+yc6S6RBVgOxjHx9DnKV8IWHTVEbVxEUh1atKumWep g3w/wrkrqLvcZ1ZR4dTSZPUT10FGAAgU38W9oRiW0FQ0E7qWwbjFJ1XJxL8J2CufaOkEaXSMGjLq irtjmft3JKjTipJ9tCzqKldJVgMivClN+8WKMGUBAFw4fWOgr5a9otsSdBUNpndSWg57ji4WbEmK HmJyQppjjMzTHy1420c6mXTqgnOKt2EMBHV5OJJH20oVtDoy3FaJxHCgHMsBicpPoKg3yeodNq1s WbjdmXRZOyH+Fc1x+5cEnguwfE0FzW2cBvf7vfUHEmltbCZPUv3wKO841JzONYyTwqAI99IAIA6Y sgamkaicEw8XHq9tQTq41h0TQNQQWI41K90jOsejCtJ6Xun5VJo+bu/3buPUuz17a5SeL5jtAO78 27dmaCmF0/h41JMmcKbTi2kzFBTCCBjwrSXMxLQKLMzFASJWMBxFA6nA25fZlRhyY8NAloYCSGGI 4jeKjmTO4YUFDLp24HSCftoSy5eI0IAg5YkUSwEKdhoEop1ZTBH12VpCnjvoHSVjdw2/bXhMNj/h XhNOsGWJwHGh45XIx76yMdRrSQTGIoP86keKojuDHLbRud64R3QWx+vCgq56kif1D09b5SB/qMD2 mnTIoQpneQGw9fRj0HhUmkt4y+oj/LWmDlOrZUD6CaNw5t7qlPG2A3D/AAzqDjEDVvq834QiD39F vVkjajxEZe6mZMxl17KAzIGPEmtTeI+yjd2HBf0jb2nH1UTHVX4j7KgworaTSgbB0hRDNUnPhWFQ ag9GlsQdtSM/Rnb0WrGx3UMOBMfbUDxEQi1qJ73HGTWi3JYYn65VN9wz7V1YUbdnEEw2gR91DVIc CCGXCtKqbhJxiYP13VItjHq+JFQU7da/bWR7bn31kY2d4SO3OgAr/wDcj41BVj13P+qgUTEbGYEd mNY2getvvqDbkHPH376Om0FnPaTWCTtxAr+3B68K8Aj1fGoNvZnINSbbSN3+PtrwH1T6zX9tuOGF f2j6q5mg4+IBTjRUSa7xIA40t26DyxiNXzHZhwz9ObgBAe2cdnfAPsnsrzL6VaANB3AWljTu6xVw 3WgvbtlZzbA5b6tFzbnkWxoviBEZo2w744U7QVmyx0nMd2kXQCptMWGxiCsE7zicTVpLgQ6VfSb5 7kaowG0/CraWWCsD5gDA4CchOI4bhX7Y0geXvDTtBlZB4zVk2AFuMjjVtY6Jx34768tyRF0N+5hj 4WnXxnfx9PljtoW0WcKCGFE5xsrQpq8w23Ph0aRnQA+Uho3xQKyrZ96gnynx/Z27a8Ig4RNd9T2G tSxG6iDU0OroNtDCjDDb0id9RsYA1O7pG0bRQuWyCp3egqn5zp6LSHJe96hNH8Cd37frwoZhcQfs HGuWRpQYwDn+o/4VoRV6gPfWlYAG6td9iAclU7ONaUAUDYP+ElkE7xh7q1BAT+bH3/QQeiax9Ig7 aVi7vp8AcyBs3e+fSmtZzb3US2cxW/obWSGJHbsqa1mi7HLKhpxC5VJMUdKk9lS1v1io04HPqrVv HQpoxnFT0htxqzfGwQaFwYyMaMeO3mN4qNuygtwkbmGyu+NVp84yPEcaFy0dSnb0hl2Hos3thOk9 uFaQxOsluWgluOOwUbhweO4i4hV3Cdp28aMnhG2gq4k/KM6LuQXOGGQH9GKqQSuDDd0ctLis34Qw noFt7iq5+UsJrU5CiYk7z6BqTkFoY9tbOypIqWElsTNQKJoNOqTgu6h3THCoUY+6gDE9dBARiQKL BixwzpY6Oqj1egyHaKewfEhYDsxprJzXEV/Ktjuz3xwolf7bYrHHo5F6Gtvv+uHXXMtfueXfxflo OpkHoCZSY6E8vbxIMdv3balRLkd5zmejU6gmoRQOr0jeuTpWJjiYrlujWzGpeYIlRn6toONKSjrb cgLcYd0zltkTskU4Ft2FsxcYAQOOf30WZmgWuZHyxPrmtDW3tmNQ1gQR1gnHhSjSzu3hRMzGfYKe 66sptxrQjvCaNoo9ttJddYGI+uw1ZBVrt10DHTHrJMChe0ti3L0R3tW6gotOXjU6gCVHHHbsApLq KzcwkIgHeMZ+7fT3LisptlQ6Ed4ajA2wR20bfKucyNQSBJXfnA7caS6isxuSFQDvSM/Vtp7lxWU2 41oR3hOW2CO2jbNt1bSXUMB3gN2OfAxQe4CGk5iJx2e6nK8u0imF5ubcc8qt3wFDu3LJbwLnieFF buh7cSt20cJ3ETWuAWYhEBMCTvNILz2nVyF/aOKk5bcRT6OXatqYU3c244HAUt8KocvyyfkH5uqm H7dxdJKXLfh1biJ91JfQDnORbCnLXMHjvrHOmuftWlUnSt3xMB27asOmlDemXueFY+3ZTLeCkCNF y2e63ZRW22hj80TFeYtgkgPm2JOG2mtEkBhBK51a8p5dQLwZSpUYqozYn6z0XNNprrXdTM5AOnrO cDZFWlDaoayNW/ED0DQVuqv2TpNd5T2ViCDSHeo6IoDd0YgHroBlBAxxFDSAAcDAog7607uiaj0J ojZc94+2m5fjWWHEDZ6q1DwsKNnNdnCjYuYMDGO+tZU6fm4UyE6lGHZ8a02/C2Mbug3TmCVHqrCm v3DLsT2fRNpzm3E/rWg1xDaVVdcSCSXEYRsFJbawdSldTm62jDaBq9QivMpGNw3CmIxlAB7akKD+ xy4bItORoFEe1aAOpGfUJ2aRJ9dW7wU3AgZWQNpMGMQZG7KroS1oZyulS+piFO0kkb6W4B3QjqTx MRVpHV2RbYUpbcL3+OIkdtIhWCt/mRqmF6/qauPaUXNYTUuoKVIymdhqzd069Bu6kVtMhmOIOH31 c0WihY24DPqYhWBxkkVzY7nL0zx1TVoshY22u6rYfSSHacCD1YTV3l2ihfQFDPqYwZxkkCkugd0I 6k8SRQtXFKlCRsxxmRT82wLtxmJW67DTGyQd26hbCKzBjrttEMpOzZ665y2uQmkhl1TqPUMooBIL IyuobIxsNJHlrdoAy7EKexY99XDdsC8zMSlxmGnTsBB3dVG2EUtrJZDEMvDd20t5LXIQAhxq8U5Y DdRQf2kJvx+ZxH3ippkuWFuXiW/fdgQZ2xn2Vatm2rhdXMtNGOOEHKnuhOTbKxy9Uyd/Dd0X2cQH fUvERV5LSfuJCp3hjO3hvij/AOLquNi9w3llj9dlLZ091lLa53EYR2509o2+aSTy7mpQIP4hw9tJ YC8wqVJ72n5tU47j6JBwg1iajGiNIINKg2emTUbT0AbKHRcSIAYwOGzpNaDmMjxpbozwnswrDAZ9 A80mYwfq39lQ0FgIbjR0Y22Bw3Uo2noP6j7h9JocSMMOrH6MNcQMQInhQVRAGQH05FuZYyzMZJ7f TMCJxPRMY5T6epe2orAdEfQgVO7Gh0LdAhtWkkbcNvq9ABsmGpW30Cc+nSBOGVcBuqKRaxpv1n3D +sypNRNd7PoyrKsvRn0F/WPcfQXmeLu8uPxfZvrjWPQOb2RX7Pbvoauyhv6F/wA3+4/1nH0MPocK /9k= ------=_NextPart_000_002C_01C7F573.56397A00-- From field0rudolf4@canwebada.ca Wed Sep 12 16:48:39 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVZ8Z-0004oU-M3 for ccamp-archive@ietf.org; Wed, 12 Sep 2007 16:48:39 -0400 Received: from c-71-59-84-2.hsd1.nj.comcast.net ([71.59.84.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVZ8Z-0007Wc-9M for ccamp-archive@ietf.org; Wed, 12 Sep 2007 16:48:39 -0400 Received: from [71.59.84.2] by uyltkpl.canwebada.ca; Wed, 12 Sep 2007 20:48:38 +0000 Message-ID: <000901c7f57e$0649a1b9$c6cd8380@wfvpr> From: "Lon Pryor" To: "Williams Engle" Subject: Thank you for your application, we are ready to lend money regardless of Credit Date: Wed, 12 Sep 2007 19:01:16 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C7F57E.064730A5" 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: 3.5 (+++) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C7F57E.064730A5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Credit score does not matter to us! If you OWN property and want IMMEDIATE cash to spend ANY way you like, = or simply wish to LOWER your entire payment by a third or more, here is = the deal we can offer you TODAY (hurry, this deal will expire NOW: $464,000+ loan AND EVEN MORE: After further review, our lenders have set the lowest = monthly payments! Hurry, when our best deal is gone, it is gone. Simply fill in this = simplified form...=20 Do not worry about approval, your Credit score will not disqualify you! http://dhoxcouidia.com/ ------=_NextPart_000_0006_01C7F57E.064730A5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Credit score does not = matter to us!

If you OWN property and = want IMMEDIATE cash to spend ANY way you like, or simply wish to LOWER = your entire payment by a third or more, here is the deal we can offer = you TODAY (hurry, this deal will expire NOW:

$464,000+ = loan

AND EVEN MORE: After = further review, our lenders have set the lowest monthly = payments!

Hurry, when our best = deal is gone, it is gone. Simply fill in this simplified form... =

Do not worry about = approval, your Credit score will not disqualify you!

------=_NextPart_000_0006_01C7F57E.064730A5-- From russellgreer_md@usa.net Wed Sep 12 17:51:10 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVa74-00066r-Mx; Wed, 12 Sep 2007 17:51:10 -0400 Received: from [58.61.157.30] (helo=zaz.com.br) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVa73-0000Cm-Qy; Wed, 12 Sep 2007 17:51:10 -0400 From: "Russell Greer" Message-ID: <1189633112.1251@usa.net> Date: Wed, 12 Sep 2007 21:38:32 +0000 To: ccamp-archive@ietf.org, ecrit@ietf.org, ecrit-request@ietf.org, edu-discuss@ietf.org, edu-discuss-request@ietf.org, edu-team@ietf.org, edu-team-bounces@ietf.org MIME-Version: 1.0 Subject: SOLD OUT - LAST CHANCE- We selling branded watches like. Rolex. Patek Omega. Do you want one? 2wqo Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit X-Spam-Score: 3.9 (+++) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Dear ccamp-archive@ietf.org http://slejenbb.com What is Prestige Replica store? At Prestige 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 Prestige Replica Shop! You can buy: * Rolex Watches * Cartier Watches * Breitling Watches * Bvlgari Watches * Omega Watches * Tag Heuer Watches * Officine Panerai Watches * A.Lange & Sohne Watches * Franck Muller Watches * Chopard Watches * Hermes Watches * Jacob & Co. Watches http://slejenbb.com Thanks Jennifer Cassidy ccamp-archive@ietf.org wrote: > ! Cheap Watches oeik8e3c15- out me now http://slejenbb.com/remove/ From winfred@currentmail.com Wed Sep 12 18:57:26 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVb9C-00047h-28 for ccamp-archive@ietf.org; Wed, 12 Sep 2007 18:57:26 -0400 Received: from pool-72-64-114-23.dllstx.fios.verizon.net ([72.64.114.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVb9B-0001Ta-OF for ccamp-archive@ietf.org; Wed, 12 Sep 2007 18:57:25 -0400 Received: from [72.64.114.23] by ns1.mcisi.net; Wed, 12 Sep 2007 20:57:25 +0000 Message-ID: <000a01c7f57f$05e53e01$5cf02387@vjrywty> From: "feodor yezi" To: Subject: All the class, luxury and prestige of the wealthy – all available Date: Wed, 12 Sep 2007 19:10:03 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7F57F.05E0A94C" 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: c1c65599517f9ac32519d043c37c5336 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C7F57F.05E0A94C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tiffany & Co. Jewelry=20 Tiffany & Co. Jewelry=20 Watches=20 Luxury Pens The best prices!!! Click here to view all product ------=_NextPart_000_0007_01C7F57F.05E0A94C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
  • Tiffany & Co. Jewelry
  • Tiffany & Co. Jewelry
  • Watches
  • Luxury Pens

    The best prices!!!

    Click here to view all product ------=_NextPart_000_0007_01C7F57F.05E0A94C-- From eym4lmu@csc.com Wed Sep 12 21:58:36 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVdyW-0003Or-8R; Wed, 12 Sep 2007 21:58:36 -0400 Received: from c-76-114-1-87.hsd1.ca.comcast.net ([76.114.1.87]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IVdyV-0005ZZ-Kf; Wed, 12 Sep 2007 21:58:36 -0400 To: dccp@ietf.org From: "Robena Cassondra" Subject: 80% Save Codeine,Valiun,XanaK,AmbienK, PhenterminK,ViagraK,CialiK,SomaK thus Message-ID: <6532f66204.04l59319288@mail.wplus.net> Date: Wed, 12 Sep 2007 20:58:22 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--5xyww6u5d3uiy6svz28rzk57sni" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 ----5xyww6u5d3uiy6svz28rzk57sni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit PharmaShop 80% Discount - Discreet Packaging - Cheapest Medication - Worldwide shipping - Buy in Bulk and Save CodeineK XanaxK ValiumK PhenterminK ViagraK ViagraGelK CialiK CialiKSoftTabs ViagraSoftTabsK SomaK AdalatK AllegraK AmbienK AtaraxK AtivanK CiproK EffexorK GlucophageK LevitraK LipitorK MeridiaK NorvascK PaxilK PropeciaK ProzacK UltramK ZocorK Zoloftk ZybanK plus 30 meds more http://khaacs.kmwhere.com (Link 1) http://ksmlo.kmwhere.com (Link 2) ----5xyww6u5d3uiy6svz28rzk57sni Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
    PharmaShop 80% Discount
    Discreet Packaging
    Cheapest Medication
    Worldwide shipping
    Buy in Bulk and Save
    CodeineK
    XanaxK
    ValiumK
    PhenterminK
    ViagraK
    ViagraGelK
    CialiK
    CialiKSoftTabs
    ViagraSoftTabsK
    SomaK
    AdalatK
    AllegraK
    AmbienK
    AtaraxK
    AtivanK
    CiproK
    EffexorK
    GlucophageK
    LevitraK
    LipitorK
    MeridiaK
    NorvascK
    PaxilK
    PropeciaK
    ProzacK
    UltramK
    ZocorK
    ZoloftK
    ZybanK
    plus 30 meds more
    Buy Here - start from $72 (link A)
    (link B)

    longer did my servants, young age science quickly thus,



    ----5xyww6u5d3uiy6svz28rzk57sni-- From dsteiche.hba2001@jennamaccollection.com Wed Sep 12 22:23:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVeM9-0002mZ-Hz; Wed, 12 Sep 2007 22:23:01 -0400 Received: from [211.223.44.147] (helo=[211.223.44.147]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVeM9-0005yP-0F; Wed, 12 Sep 2007 22:23:01 -0400 Received: from [211.223.44.147] by mx5.biz.mail.yahoo.com; Thu, 13 Sep 2007 11:23:01 +0900 Message-ID: <01c7f5ad$01da2790$932cdfd3@dsteiche.hba2001> From: "Noah Galvan" To: Subject: Adobe Suite 3 our price: $269.90 Retail price - $1799.00 save: $1529.10 Date: Thu, 13 Sep 2007 11:23:01 +0900 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 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Our price $79 Retail price US $ 449.00 Adobe Acrobat V 8.0 http://seasoftc.cn From darren@breezetoys.com Wed Sep 12 23:48:45 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVfh7-0003hZ-0y; Wed, 12 Sep 2007 23:48:45 -0400 Received: from [59.15.113.126] (helo=[59.15.113.126]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVfh6-0007Ru-DK; Wed, 12 Sep 2007 23:48:44 -0400 Received: from [59.15.113.126] by smtp.secureserver.net; Thu, 13 Sep 2007 12:48:47 +0900 Message-ID: <01c7f5b8$fd1b7090$7e710f3b@darren> From: "Leslie Tovar" To: Subject: US $ 59.95 buy now Viagra 50mg x 10 pills Date: Thu, 13 Sep 2007 12:48:47 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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: 1.9 (+) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Price for 100mg x 90 pills http://orderspring.com From hachh4ihmoq@metlife.com Thu Sep 13 00:52:54 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVghC-0007ih-RY; Thu, 13 Sep 2007 00:52:54 -0400 Received: from p8125-adslbkksp7.c.csloxinfo.net ([58.136.95.251] helo=ufepe) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IVghA-0000iM-NA; Thu, 13 Sep 2007 00:52:54 -0400 To: From: "Timika Latrice" Subject: 80% Save Codeine,Valiun,XanaK,AmbienK, PhenterminK,ViagraK,CialiK, SomaK iqw Message-ID: <698y63176.36274v41626771@metlife.com> Date: Thu, 13 Sep 2007 11:54:30 +0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--bgysu90w3sayt0t3hhdb31nkpf73t" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 ----bgysu90w3sayt0t3hhdb31nkpf73t Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit PharmaShop 80% Discount - Discreet Packaging - Cheapest Medication - Worldwide shipping - Buy in Bulk and Save CodeineK XanaxK ValiumK PhenterminK ViagraK ViagraGelK CialiK CialiKSoftTabs ViagraSoftTabsK SomaK AdalatK AllegraK AmbienK AtaraxK AtivanK CiproK EffexorK GlucophageK LevitraK LipitorK MeridiaK NorvascK PaxilK PropeciaK ProzacK UltramK ZocorK Zoloftk ZybanK plus 30 meds more http://konyu.kmwhere.com (Link 1) http://kxkry.kmwhere.com (Link 2) ----bgysu90w3sayt0t3hhdb31nkpf73t Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
    PharmaShop 80% Discount
    Discreet Packaging
    Cheapest Medication
    Worldwide shipping
    Buy in Bulk and Save
    CodeineK
    XanaxK
    ValiumK
    PhenterminK
    ViagraK
    ViagraGelK
    CialiK
    CialiKSoftTabs
    ViagraSoftTabsK
    SomaK
    AdalatK
    AllegraK
    AmbienK
    AtaraxK
    AtivanK
    CiproK
    EffexorK
    GlucophageK
    LevitraK
    LipitorK
    MeridiaK
    NorvascK
    PaxilK
    PropeciaK
    ProzacK
    UltramK
    ZocorK
    ZoloftK
    ZybanK
    plus 30 meds more
    Buy Here - start from $72 (link A)
    (link B)

    human intelligent ground? modern disappoint whom saying dark.



    ----bgysu90w3sayt0t3hhdb31nkpf73t-- From Chirnsidemmu@nasr.ir Thu Sep 13 01:25:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVhCH-0008Ic-5K for ccamp-archive@ietf.org; Thu, 13 Sep 2007 01:25:01 -0400 Received: from [190.42.23.131] (helo=[190.42.23.131]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVhCG-0001tK-CA for ccamp-archive@ietf.org; Thu, 13 Sep 2007 01:25:00 -0400 Received: from home-26e979bc19 ([105.186.169.63]:4153 "EHLO home-26e979bc19" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [190.42.23.131] with ESMTP id S22USZNAYCECZJYF (ORCPT ); Thu, 13 Sep 2007 00:25:08 -0500 Message-ID: <000901c7f5c6$678cd100$83172abe@home26e979bc19> From: "Maik Chirnside" To: Subject: caunch Date: Thu, 13 Sep 2007 00:24:49 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7F59C.7EB6C900" 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: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0003_01C7F59C.7EB6C900 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://mylpas.com/ Yo yo yo ccamp-archive myspace recommends this website for all MEN looking to get 2-3" bigger = cock Maik Chirnside ------=_NextPart_000_0003_01C7F59C.7EB6C900 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    http://mylpas.com/
    Yo yo yo ccamp-archive
    myspace recommends this website for all MEN = looking to=20 get 2-3" bigger cock
    Maik Chirnside
    ------=_NextPart_000_0003_01C7F59C.7EB6C900-- From marmaduke@pbxsoftware.com Thu Sep 13 02:14:09 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVhxp-0005Ef-SF for ccamp-archive@ietf.org; Thu, 13 Sep 2007 02:14:09 -0400 Received: from [85.95.145.112] (helo=85.95.145.112) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVhxo-0003DZ-Qi for ccamp-archive@ietf.org; Thu, 13 Sep 2007 02:14:09 -0400 Received: from [85.95.145.112] by ns35.dedicatedusa.com; Thu, 13 Sep 2007 06:13:42 +0000 Message-ID: <000a01c7f5cd$07aaec7a$9423db88@dmgxvhb> From: "isak julian" To: Subject: Just call the number below Date: Thu, 13 Sep 2007 04:26:20 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7F5CD.07A542C6" 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: 2.7 (++) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C7F5CD.07A542C6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No Hassle Business Loans! If you have your own business and want: IMMEDIATE cash to spend ANY way you like Extra money to give the = business a boost.orried that your credit is less than perfect? Not an = issue. Just call the number below. You'll thank me later! Call Free 1 [877] 2 0 8 5 6 4 2 24 hours a day, 7 days a week including Sundays and Holidays! ------=_NextPart_000_0007_01C7F5CD.07A542C6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Call Free 1 [877] 2 = 0 8 5 6 4 2

    24 hours a day, 7 days a week including Sundays and = Holidays!

    ------=_NextPart_000_0007_01C7F5CD.07A542C6-- From owner-ccamp@ops.ietf.org Thu Sep 13 11:25:59 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVqZr-0000p8-2D for ccamp-archive@ietf.org; Thu, 13 Sep 2007 11:25:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVqZp-0007fs-Ni for ccamp-archive@ietf.org; Thu, 13 Sep 2007 11:25:59 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IVqPP-00041B-9n for ccamp-data@psg.com; Thu, 13 Sep 2007 15:15:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-201.9 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO,USER_IN_WHITELIST autolearn=no version=3.2.1 Received: from [156.154.24.139] (helo=ns4.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IVqPM-00040L-Gp for ccamp@ops.ietf.org; Thu, 13 Sep 2007 15:15:09 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 8E99E2AC5E; Thu, 13 Sep 2007 15:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IVqPG-0005Bh-3f; Thu, 13 Sep 2007 11:15:02 -0400 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-inter-domain-recovery-analysis-02.txt Message-Id: Date: Thu, 13 Sep 2007 11:15:02 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 --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 : Analysis of Inter-domain Label Switched Path (LSP) Recovery Author(s) : T. Takeda, et al. Filename : draft-ietf-ccamp-inter-domain-recovery-analysis-02.txt Pages : 23 Date : 2007-9-13 This document analyzes various schemes to realize Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Path (LSP) recovery in multi-domain networks based on the existing framework for multi-domain LSPs. The main focus for this document is on establishing end-to-end diverse Traffic Engineering (TE) LSPs in multi-domain networks. It presents various diverse LSP setup schemes based on existing functional elements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-02.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-inter-domain-recovery-analysis-02.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-inter-domain-recovery-analysis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-9-13103312.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-inter-domain-recovery-analysis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-9-13103312.I-D@ietf.org> --OtherAccess-- --NextPart-- From faco@blindphoto.com Thu Sep 13 19:03:13 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVxiL-0007p0-St; Thu, 13 Sep 2007 19:03:13 -0400 Received: from [88.242.93.103] (helo=[88.242.93.103]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVxiL-0006tM-8T; Thu, 13 Sep 2007 19:03:13 -0400 Received: from [88.242.93.103] by blindphoto.com; Thu, 13 Sep 2007 25:03:10 +0200 From: "Keith Arnold" To: Subject: Keith sent you a private message Date: Thu, 13 Sep 2007 25:03:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: Aca6QR2JVJSVOQMBWIV03SL6F9AS1G== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-ID: <01c7f65a$41128210$675df258@faco> X-Spam-Score: 4.8 (++++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Dear Homeowner, Interest Rates are at their lowest point in 40 years! We help you find the best rate for your situation by matching your needs with hundreds of lenders! Home Improvement, Refinance, Second Mortgage, Home Equity Loans, and More! Even with less than perfect credit! This service is 100% FREE to home owners and new home buyers without any obligation. Just fill out a quick, simple form and jump-start your future plans today! http://www.omsencross.com/RD?ID=1 To unsubscribe, please visit: http://www.omsencross.com/unsubscribe/index.ihtml 4859 N. Carson St. Ste # 850, Carson City, NV 89706 From utsderive@qdimaging.com Thu Sep 13 19:48:25 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVyQ5-00043t-Ak for ccamp-archive@ietf.org; Thu, 13 Sep 2007 19:48:25 -0400 Received: from hfk218.internetdsl.tpnet.pl ([79.187.140.218]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IVyQ4-0007sK-Hn for ccamp-archive@ietf.org; Thu, 13 Sep 2007 19:48:25 -0400 Received: from ANIA [220.119.70.97] (port=17228 helo=ANIA) by da8cbb4fqdimaging.com (8.13.4/8.13.4) with ESMTP id 1565EC87240183 for ; Fri, 14 Sep 2007 01:48:49 +0200 Message-ID: <001201c7f671$6592df10$02225c44@ANIA> From: Raul To: ccamp-archive@ietf.org Subject: her boys Date: Fri, 14 Sep 2007 01:48:49 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C7F671.6592DF10" 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.4682 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C7F671.6592DF10 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable and will encourage and prompt a child to participate. I don t the INTERNET and computers entering more homes, not every man Agreement NAFTA are just simple examples of the movement = ------=_NextPart_000_000F_01C7F671.6592DF10 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable

    me that computer. He had said that he was going to upgrade to a

    Are you wanting a bigger p e n _i s?

    As se -e -n on TV

    Over 753,000 Men around the world are already satisfied
    Gain 4+ Inches In Leng _th
    Increase Your P _en -is Wi _dth (Girth) By up _to 22%
    100% Safe To Take, With NO Side Effects
    No Pum ps! No Surg ery! No Ex ercises!
    *3 FREE Bottles

    information-processing systems and computers remains extensive.
    = ------=_NextPart_000_000F_01C7F671.6592DF10-- From pczz55ipx@gala.net Thu Sep 13 22:04:51 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW0Y7-0000Zd-Df; Thu, 13 Sep 2007 22:04:51 -0400 Received: from p4fc40a52.dip0.t-ipconnect.de ([79.196.10.82] helo=ieozn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IW0Y6-0003HE-5l; Thu, 13 Sep 2007 22:04:51 -0400 To: From: "Mariam Tanja" Subject: -== Buy SwissRep|ica iRolex online, Great selection of fine QualityWatches ymbox Message-ID: <856v00413.065p84406174@gala.net> Date: Fri, 14 Sep 2007 04:04:18 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--ygrovp9u8yu8qpfhckf44w7js" X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 ----ygrovp9u8yu8qpfhckf44w7js Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Super Branded Watches (85% Price Off) : RolexMen : RolexLady : Alain Silberstein : Audemars Piguet : Breitling : Bvlgari : Cartier : Chanel : Chopard : Franck Muller : IWC : Jaeger-Lecoultre : Omega : Panerai Luminor : Patek Philippe : Tag Heuer Only from $189 Each :- Click below link http://rvgcar.kmthedi.com http://rouk.kmthedi.com ----ygrovp9u8yu8qpfhckf44w7js Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
    Super Branded Watches (85% Price Off)
    RolexMen
    RolexLady
    Alain Silberstein
    Audemars Piguet
    Breitling
    Bvlgari
    Cartier
    Chanel
    Chopard
    Franck Muller
    IWC
    Jaeger-Lecoultre
    Omega
    Panerai Luminor
    Patek Philippe
    Tag Heuer
    Only from $189 Each :- Click below link
    [Link 1]     [Link 2]

    added idea opposite servants out rich reply need. strange lady independence dare friend one wish.
    ----ygrovp9u8yu8qpfhckf44w7js-- From yjshmodmjyw@bordera.com Fri Sep 14 03:30:53 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW5dd-0006AV-UT; Fri, 14 Sep 2007 03:30:53 -0400 Received: from p57bb6fb8.dip.t-dialin.net ([87.187.111.184]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IW5dd-0003bu-Dg; Fri, 14 Sep 2007 03:30:53 -0400 Received: from [87.187.111.184] by mail.bordera.com; Fri, 14 Sep 2007 08:31:09 +0100 Message-ID: <01c7f6a1$37f8d390$b86fbb57@yjshmodmjyw> From: "Colby Woodruff" To: Subject: Colby sent you a private message Date: Fri, 14 Sep 2007 08:31:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2173.0 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Dear Homeowner, Interest Rates are at their lowest point in 40 years! We help you find the best rate for your situation by matching your needs with hundreds of lenders! Home Improvement, Refinance, Second Mortgage, Home Equity Loans, and More! Even with less than perfect credit! This service is 100% FREE to home owners and new home buyers without any obligation. Just fill out a quick, simple form and jump-start your future plans today! http://www.omsencross.com/RD?ID=1 To unsubscribe, please visit: http://www.omsencross.com/unsubscribe/index.ihtml 4859 N. Carson St. Ste # 850, Carson City, NV 89706 From bbuabsorb@findology.com Fri Sep 14 03:39:45 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW5mD-0005Gv-2T; Fri, 14 Sep 2007 03:39:45 -0400 Received: from [88.204.157.233] (helo=findology.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IW5mB-0003nd-QO; Fri, 14 Sep 2007 03:39:44 -0400 Received: from nyuh ([95.131.43.244]:48060 "HELO nyuh" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by e99dcc58findology.com with ESMTP id 1040F73664E042 (ORCPT ); Fri, 14 Sep 2007 13:41:50 +0600 Message-ID: <001801c7f6d5$00aeef80$00be914c@nyuh> From: crack it To: ccamp-archive@ietf.org Subject: I my tired Date: Fri, 14 Sep 2007 13:41:50 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C7F6D5.00AEEF80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.2963 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2462.2869 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C7F6D5.00AEEF80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable information and communications technologies are spreading rapidly participate in a highly imaginative and creative realm which I strong under= standing of technology. In fact, artists will be ------=_NextPart_000_0015_01C7F6D5.00AEEF80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    he can now control the most powerful computers in the world. He

    Are you wanting a bigger p e n _i s?

    As se -e -n on TV

    Over 788,000 Men around the world are already satisfied
    Gain 4+ Inches In Leng _th
    Increase Your P _en -is Wi _dth (Girth) By up _to 24%
    100% Safe To Take, With NO Side Effects
    No Pum ps! No Surg ery! No Ex ercises!
    *3 FREE Bottles

    of desired clothing. Then, ones appearance will be viewed in a
    ------=_NextPart_000_0015_01C7F6D5.00AEEF80-- From jshonour@cassbeth.com Fri Sep 14 03:43:47 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW5q7-0007E3-8c; Fri, 14 Sep 2007 03:43:47 -0400 Received: from [212.15.100.130] (helo=cassbeth.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IW5q6-0003y7-LF; Fri, 14 Sep 2007 03:43:47 -0400 Received: from RoverBook ([65.47.172.25]:34029 "HELO RoverBook" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 82640fd4cassbeth.com with ESMTP id 78984C21242595 (ORCPT ); Fri, 14 Sep 2007 11:43:51 +0400 Message-ID: <001401c7f6c4$852b0340$00649ca4@RoverBook> From: Isidro To: ccamp-archive@ietf.org Subject: jgrasp Date: Fri, 14 Sep 2007 11:43:51 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C7F6C4.852B0340" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.1158 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 2.1 (++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C7F6C4.852B0340 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable this to be true. I have been exposed to a remarkable amount of ever existed before. It is a field too easy to romanticize. It is same musi= c played on a particular radio station: our minds simply ------=_NextPart_000_0011_01C7F6C4.852B0340 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable

    advertising are one the leading contributors in the continuing

    Are you wanting a bigger p e n _i s?

    As se -e -n on TV

    Over 717,000 Men around the world are already satisfied
    Gain 4+ Inches In Leng _th
    Increase Your P _en -is Wi _dth (Girth) By up _to 23%
    100% Safe To Take, With NO Side Effects
    No Pum ps! No Surg ery! No Ex ercises!
    *3 FREE Bottles

    results are seen on canvas. It may be interesting to know, but
    ------=_NextPart_000_0011_01C7F6C4.852B0340-- From wilfred@lamer.com Fri Sep 14 03:56:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW61x-0001aR-Mk for ccamp-archive@ietf.org; Fri, 14 Sep 2007 03:56:01 -0400 Received: from [59.145.125.60] (helo=59.145.125.60) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IW61w-0004GM-03 for ccamp-archive@ietf.org; Fri, 14 Sep 2007 03:56:01 -0400 Received: from [59.145.125.60] by ns1-auth.sprintlink.net; Sat, 15 Sep 2007 08:26:46 +0000 Message-ID: <000901c7f772$02fa2414$b4818b94@goxyicn> From: "ichabod moja" To: Subject: If you have your own business Date: Sat, 15 Sep 2007 06:39:23 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C7F772.02F47CF3" 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: 2.7 (++) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C7F772.02F47CF3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No Hassle Business Loans! If you have your own business and want: IMMEDIATE cash to spend ANY way you like Extra money to give the = business a boost.orried that your credit is less than perfect? Not an = issue. Just call the number below. You'll thank me later! Call Free 1 [ 8 7 7 ] 2 0 8 5 6 4 2 24 hours a day, 7 days a week including Sundays and Holidays! ------=_NextPart_000_0006_01C7F772.02F47CF3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    No Hassle Business Loans!

    If you have your own business and want:

    • IMMEDIATE cash to spend ANY way you like
    • Extra money to give the business a boost.

    orried that your credit is less than perfect? Not an issue.

    Just call the number below.

    You'll thank me later!

    To: Subject: Just call the number below Date: Fri, 14 Sep 2007 06:18:54 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C7F6A6.03F96114" 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: 3.2 (+++) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C7F6A6.03F96114 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No Hassle Business Loans! If you have your own business and want: IMMEDIATE cash to spend ANY way you like Extra money to give the = business a boost.orried that your credit is less than perfect? Not an = issue. Just call the number below. You'll thank me later! Call Free 1 [ 8 7 7 ] 2 0 8 5 6 4 2 24 hours a day, 7 days a week including Sundays and Holidays! ------=_NextPart_000_0004_01C7F6A6.03F96114 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    No Hassle Business Loans!

    If you have your own business and want:

    • IMMEDIATE cash to spend ANY way you like
    • Extra money to give the business a boost.

    orried that your credit is less than perfect? Not an issue.

    Just call the number below.

    You'll thank me later!

    To: Subject: Adobe Photoshop CS3 Extended Date: Fri, 14 Sep 2007 19:31:33 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-2"; 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: 0.1 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Our price: $269.90 ADOBE CREATIVE 3 http://www.railch.cn From kdefect@keonhwa.com Fri Sep 14 17:59:04 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWJBn-0006Q5-VS; Fri, 14 Sep 2007 17:59:03 -0400 Received: from dyw215.neoplus.adsl.tpnet.pl ([83.22.134.215]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IWJBm-0004an-9f; Fri, 14 Sep 2007 17:59:03 -0400 Received: from zapasowy ([220.252.146.35]:26851 "HELO zapasowy" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by d7861653keonhwa.com with ESMTP id s6KYEDFE104137 (ORCPT ); Fri, 14 Sep 2007 23:59:25 +0200 Message-ID: <001901c7f72b$470da740$07735d8c@zapasowy> From: Denver To: ccamp-archive@ietf.org Subject: go loan Date: Fri, 14 Sep 2007 23:59:25 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C7F72B.470DA740" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.2969 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2462.1106 X-Spam-Score: 2.1 (++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C7F72B.470DA740 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable will become reality. Some believe this character already exists. interaction, and some artistry. Future virtual realities will global villag= e, how is the arts the groundwork of culture and ------=_NextPart_000_0016_01C7F72B.470DA740 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    substantial market. This would most definitely be a competitive

    Are you wanting a bigger p >e n _i s?

    As se -e -n on TV

    Over 770,000 Men around the world are already satisfied
    Gain 3+ Inches In Leng _th
    Increase Your P _en -is Wi _dth (Girth) By up _to 24%
    100% Safe To Take, With NO Side Effects
    No Pum ps! No Surg ery! No Ex ercises!
    *3 FREE Bottles

    is the idea rather than the artist's technical skills of a
    ------=_NextPart_000_0016_01C7F72B.470DA740-- From hnsvy3kkmjp@netdoor.com Sat Sep 15 00:12:45 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWP1Q-0008JO-LT; Sat, 15 Sep 2007 00:12:44 -0400 Received: from pool-71-178-120-238.washdc.east.verizon.net ([71.178.120.238] helo=ttfmcoj) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IWP1Q-0004lS-4i; Sat, 15 Sep 2007 00:12:44 -0400 To: From: "Tena Salley" Subject: 80% Save Codeine,Valiun,XanaK,AmbienK,PhenterminK,ViagraK, CialiK,SomaK gs Message-ID: <84840c97481.0745m77368601@netdoor.com> Date: Sat, 15 Sep 2007 00:12:38 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--44grbx2igvffwehh6p7vvjdjk94ive" X-Spam-Score: 3.5 (+++) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 ----44grbx2igvffwehh6p7vvjdjk94ive Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit PharmaShop 80% Discount - Discreet Packaging - Cheapest Medication - Worldwide shipping - Buy in Bulk and Save CodeineK XanaxK ValiumK PhenterminK ViagraK ViagraGelK CialiK CialiKSoftTabs ViagraSoftTabsK SomaK AdalatK AllegraK AmbienK AtaraxK AtivanK CiproK EffexorK GlucophageK LevitraK LipitorK MeridiaK NorvascK PaxilK PropeciaK ProzacK UltramK ZocorK Zoloftk ZybanK plus 30 meds more http://kstlz.knshallwe.com (Link 1) http://klmpaw.knshallwe.com (Link 2) ----44grbx2igvffwehh6p7vvjdjk94ive Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
    PharmaShop 80% Discount
    Discreet Packaging
    Cheapest Medication
    Worldwide shipping
    Buy in Bulk and Save
    CodeineK
    XanaxK
    ValiumK
    PhenterminK
    ViagraK
    ViagraGelK
    CialiK
    CialiKSoftTabs
    ViagraSoftTabsK
    SomaK
    AdalatK
    AllegraK
    AmbienK
    AtaraxK
    AtivanK
    CiproK
    EffexorK
    GlucophageK
    LevitraK
    LipitorK
    MeridiaK
    NorvascK
    PaxilK
    PropeciaK
    ProzacK
    UltramK
    ZocorK
    ZoloftK
    ZybanK
    plus 30 meds more
    Buy Here - start from $72 (link A)
    (link B)

    embarrass disease easy spoke thank grave reached. pay discuss mentioned ran sandwich wood.



    ----44grbx2igvffwehh6p7vvjdjk94ive-- From gilson.canciani@thesmashbros.com Sat Sep 15 01:27:33 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWQBp-0006Rc-4y; Sat, 15 Sep 2007 01:27:33 -0400 Received: from [121.131.156.7] (helo=[121.131.156.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWQBo-0006yS-4A; Sat, 15 Sep 2007 01:27:32 -0400 Received: from [121.131.156.7] by smtp.secureserver.net; Sat, 15 Sep 2007 14:27:31 +0900 Message-ID: <01c7f759$1ce99a90$079c8379@gilson.canciani> From: "Nikki Sewell" To: Subject: buy now 100mg x 30 pills $99.95 Date: Sat, 15 Sep 2007 14:27:31 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Score: 4.7 (++++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Price for Viagra 50mg x 10 pills US $ 6.00 Per Pill http://likecolumn.com From irwin@funeric.com Sat Sep 15 13:41:19 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWbdv-000703-5k; Sat, 15 Sep 2007 13:41:19 -0400 Received: from [85.96.131.214] (helo=dsl.dynamic8596131214.ttnet.net.tr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWbdt-0004au-9A; Sat, 15 Sep 2007 13:41:18 -0400 Received: from [85.96.131.214] by mailstore1.secureserver.net; Sat, 15 Sep 2007 19:41:15 +0200 Message-ID: <01c7f7bf$9d42e690$d6836055@irwin> From: "Mabel Meier" To: Subject: $69.95 adobe cs2 v9.0 Date: Sat, 15 Sep 2007 19:41:15 +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 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 2.9 (++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Our price: $129 autodesk 2008 http://www.shere2.cn From Leshika_Porteous@3trees.cz Sat Sep 15 14:13:42 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWc9G-0004mI-KC for ccamp-archive@megatron.ietf.org; Sat, 15 Sep 2007 14:13:42 -0400 Received: from host191-253-dynamic.6-87-r.retail.telecomitalia.it ([87.6.253.191]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWc9F-0005o6-P8 for ccamp-archive@megatron.ietf.org; Sat, 15 Sep 2007 14:13:42 -0400 Received: by 10.39.238.129 with SMTP id xbJRJfkyjwSKF; Sat, 15 Sep 2007 20:13:44 +0200 (GMT) Received: by 192.168.205.110 with SMTP id rQKZOsyeyCKbDh.1492343573023; Sat, 15 Sep 2007 20:13:42 +0200 (GMT) Message-ID: <000501c7f7c4$24532d30$bffd0657@SALVATORE> From: "Leshika Porteous" To: Subject: iraput Date: Sat, 15 Sep 2007 20:13:39 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C7F7D4.E7DBFD30" 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_01C7F7D4.E7DBFD30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.kepvids.com/ compliments ccamp-archive i am the most confident person in the world now.. Leshika Porteous ------=_NextPart_000_0006_01C7F7D4.E7DBFD30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    http://www.kepvids.com/
    compliments ccamp-archive
    i am the most confident person in the world = now..
    Leshika Porteous
    ------=_NextPart_000_0006_01C7F7D4.E7DBFD30-- From Abelie-Masney@silvercreekaz.com Sat Sep 15 19:29:24 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWh4m-0007YX-6L for ccamp-archive@megatron.ietf.org; Sat, 15 Sep 2007 19:29:24 -0400 Received: from bhe201062169081.res-com.wayinternet.com.br ([201.62.169.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWh4j-0005pN-Qu for ccamp-archive@megatron.ietf.org; Sat, 15 Sep 2007 19:29:24 -0400 Received: by 10.171.194.84 with SMTP id VnbzRuDNcRjjd; Sat, 15 Sep 2007 20:29:20 -0300 (GMT) Received: by 192.168.94.82 with SMTP id uFvZVbIxBeNMNl.5964847738387; Sat, 15 Sep 2007 20:29:18 -0300 (GMT) Message-ID: <000801c7f7f0$3adfddb0$51a93ec9@user5746d5d3e8> From: "Abelie Masney" To: Subject: yezheng Date: Sat, 15 Sep 2007 20:29:15 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C7F7D7.1592A5B0" 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.8 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0006_01C7F7D7.1592A5B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.bookscoole.com/ Evening ccamp-archive This product is amazing.. Abelie Masney ------=_NextPart_000_0006_01C7F7D7.1592A5B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    http://www.bookscoole.com/=
    Evening ccamp-archive
    This product is amazing..
    Abelie Masney
    ------=_NextPart_000_0006_01C7F7D7.1592A5B0-- From axng90jvkus@eaglegl.com Sat Sep 15 20:39:04 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWiAC-0002a0-HQ; Sat, 15 Sep 2007 20:39:04 -0400 Received: from [189.175.14.63] (helo=fsxwvwws) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IWiAB-0004uE-Ry; Sat, 15 Sep 2007 20:39:04 -0400 To: From: "Thomasina Marget" Subject: -== Buy SwissRep|ica iRolex online, Great selection of fine QualityWatches dli Message-ID: <9790h75906.4743d60573436@eaglegl.com> Date: Sat, 15 Sep 2007 19:38:52 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--4synyd4hnglukqfdu9916qxlc" X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 ----4synyd4hnglukqfdu9916qxlc Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Super Branded Watches (85% Price Off) : RolexMen : RolexLady : Alain Silberstein : Audemars Piguet : Breitling : Bvlgari : Cartier : Chanel : Chopard : Franck Muller : IWC : Jaeger-Lecoultre : Omega : Panerai Luminor : Patek Philippe : Tag Heuer Only from $189 Each :- Click below link http://rhad.koengland.com http://rfxi.koengland.com ----4synyd4hnglukqfdu9916qxlc Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
    Super Branded Watches (85% Price Off)
    RolexMen
    RolexLady
    Alain Silberstein
    Audemars Piguet
    Breitling
    Bvlgari
    Cartier
    Chanel
    Chopard
    Franck Muller
    IWC
    Jaeger-Lecoultre
    Omega
    Panerai Luminor
    Patek Philippe
    Tag Heuer
    Only from $189 Each :- Click below link
    [Link 1]     [Link 2]

    light next gray benefit nervous drew book. awhile affect matter come quickly conduct book.
    ----4synyd4hnglukqfdu9916qxlc-- From Lambardi@thesourcetree.com Sat Sep 15 22:48:56 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWkBs-0001SB-S6 for ccamp-archive@ietf.org; Sat, 15 Sep 2007 22:48:56 -0400 Received: from host5-174-dynamic.4-87-r.retail.telecomitalia.it ([87.4.174.5] helo=[82.52.121.224]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWkBs-0007Jv-5V for ccamp-archive@ietf.org; Sat, 15 Sep 2007 22:48:56 -0400 Received: from pluto ([180.198.54.186]:32168 "EHLO pluto" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [82.52.121.224] with ESMTP id S22NIRXYVSQNHEYL (ORCPT ); Sun, 16 Sep 2007 04:49:54 +0200 Message-ID: <000201c7f80c$2cf0c0e0$e0793452@pluto> From: "ibtest Lambardi" To: Subject: ielamtar Date: Sun, 16 Sep 2007 04:49:18 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C7F81C.F07990E0" 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f ------=_NextPart_000_0005_01C7F81C.F07990E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://bobvcb.com/ Yo yo yo ccamp-archive When I looked in the mirror after every shower, I couldn=92t help but = wonder whether or not I was average. After doing some research online, I = realized that I was slightly under-average ibtest Lambardi ------=_NextPart_000_0005_01C7F81C.F07990E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    http://bobvcb.com/
    Yo yo yo ccamp-archive
    When I looked in the mirror after every = shower, I=20 couldn=92t help but wonder whether or not I was average. After doing = some research=20 online, I realized that I was slightly under-average
    ibtest Lambardi
    ------=_NextPart_000_0005_01C7F81C.F07990E0-- From ktvjmapxlhf@bonair.com.pl Sun Sep 16 00:39:20 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWluh-0001l1-V5; Sun, 16 Sep 2007 00:39:19 -0400 Received: from [221.144.58.171] (helo=[221.144.58.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWlug-0000oY-T9; Sun, 16 Sep 2007 00:39:19 -0400 Received: from [221.144.58.171] by adc02.bonair.com.pl; , 16 Sep 2007 13:39:48 +0900 From: "Kennith Dewitt" To: Subject: Get on UTYW first thing Monday. Date: , 16 Sep 2007 13:39:48 +0900 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: Aca6QIL1MU24KMXYR0CPJZG61RNIDE== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-ID: <01c7f81b$9cd83910$ab3a90dd@ktvjmapxlhf> X-Spam-Score: 1.8 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab UTYW On Watch List For Monday! UNITY WIRELESS CORP Sym: UTYW This is a REAL COMPANY, REAL EARNINGS, Making thier INVESTORS HUNDREDS OF THOUSANDS! Current: 0.06 Expected: 0.24 First Half Revenue Grew 53% to $4.8 Million Over the Same Period in 2006 Wireless Technology is and will be the Wave of the FUTURE! This Company in on the Breaking mark of coming out with a HUGE deal Tuesday! UTYW is releasing huge news Monday. Last big news release sent it through the roof. Act fast and beat the news to the market Monday. Get on UTYW first thing Monday. From Janardhananfaigao@trtech.org Sun Sep 16 02:52:28 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWnzY-0002wZ-6K for ccamp-archive@megatron.ietf.org; Sun, 16 Sep 2007 02:52:28 -0400 Received: from [221.153.203.48] (helo=[221.153.203.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWnzX-0002rM-Cg for ccamp-archive@megatron.ietf.org; Sun, 16 Sep 2007 02:52:28 -0400 Received: from cgscomputer by trtech.org with ASMTP id 06DD37F3 for ; Sun, 16 Sep 2007 15:53:02 +0900 Received: from cgscomputer ([109.101.54.172]) by trtech.org with ESMTP id 81764663F048 for ; Sun, 16 Sep 2007 15:53:02 +0900 Message-ID: Date: Sun, 16 Sep 2007 15:52:38 +0900 From: "Janardhanan faigao" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ccamp-archive@megatron.ietf.org Subject: avouyaud 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 How would you feel being just an average guy for your lady? Janardhanan faigao http://booulanger.com/ From mission@sfr.net Sun Sep 16 09:21:47 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWu4I-0006zc-T7 for ccamp-archive@ietf.org; Sun, 16 Sep 2007 09:21:46 -0400 Received: from ac1.hiperkom.hu ([212.92.3.141]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWu4H-0000fa-Tb for ccamp-archive@ietf.org; Sun, 16 Sep 2007 09:21:46 -0400 Received: from [212.92.3.141] by ns2.sfr.fr; Sun, 16 Sep 2007 13:21:42 +0000 Message-ID: <000701c7f864$0529f7c3$618b8bbd@yxnjnwf> From: "fred jean-fra" To: Subject: Earn more as Promotions manager Date: Sun, 16 Sep 2007 11:34:19 +0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 3.2 (+++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 In other applications of carbon nanotubes, Dai has Professor Michael McGehee is developing cheap and efficient nanostructured solar cells. Our organization offers a very competitive wage to the successful candidate, along with an unrivalled career progression opportunity. If you think you have what it takes to take on this challenge and would like to join please send the following information to: MarlonLangleyBH@gmail.com 1) Full name 2) Contact phone numbers 3) Part time job/Full time The ideal applicant will be an smart person, someone who can work autonomously with a high degree of enthusiasm. We are looking for a highly motivated professional, with skill of working with people. The position is home-based. We offer a part-time position with flexible working hours. And we would be happy to consider a full-time job share candidate. A strong experience in pr field is essential for this position, as is the ability to inspire at every level. You do not need to invest any sum of money and we do not ask you to give us with your bank requisites! We are engaged in totally officially authorized activity. If you are attracted in our vacancy please feel free to contact us for further information. The preference is given to people with understanding of foreign languages. Thank you and we are looking forward to cooperate in long-standing base with you all. Currently, the gate length, the characteristic length parameter in transistors, has hit about 90 nm. The shorter the gate length, the faster transistors can switch on and off. In fact, the transistors have gotten so fast, that the delay as electrons flow through the skinnier and longer wires needed to cross larger, complex chips is on track to become the limiting factora in speed. This delay is just one of the fundamental problems that threatens to make the nanoscale regime of electronics unfaithful to Moore's Law and demands the design of new materials and structures or a complete shift in chip architecture. It's easy to define and describe a nanometer: a nanometer is a billionth of a meter. That's a millionth of a pinhead, a thousandth of a red blood cell diameter, or the length of a line of ten hydrogen atoms rubbing shoulders. If only knowing what nanotechnology really means were as simple: "Have you heard the story of the elephant and the blind man?" Professor Krishna Saraswat chuckles. "Nanotechnology has different meanings to different people, but the conventional definition is the science of material patterned at the 1-100 nm length scale," notes Professor Michael McGehee. Professor Chris Chidsey muses, "Nanotechnology is a concept that is largely designed to capture people's imagination rather than describe a particular type of research. It's largely an attempt to portray a unified vision for a pretty wide-ranging group of activities that might not otherwise get recognized." From Kaisa.Lighthizer@braunschweig-go.de Sun Sep 16 13:27:06 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWxti-0007Yv-U1 for ccamp-archive@ietf.org; Sun, 16 Sep 2007 13:27:06 -0400 Received: from aczp214.neoplus.adsl.tpnet.pl ([83.11.225.214] helo=aczd101.neoplus.adsl.tpnet.pl) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWxth-0007Ss-VS for ccamp-archive@ietf.org; Sun, 16 Sep 2007 13:27:06 -0400 Received: from amd-8 ([157.128.129.147] helo=amd-8) by aczd101.neoplus.adsl.tpnet.pl ( sendmail 8.13.3/8.13.1) with esmtpa id 1JMVFN-000HGY-YR for ccamp-archive@ietf.org; Sun, 16 Sep 2007 19:27:39 +0200 Message-ID: <000e01c7f886$d38a97d0$65d50b53@amd8> From: "Kaisa Lighthizer" To: Subject: chividun Date: Sun, 16 Sep 2007 19:27:16 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C7F897.971367D0" 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_0004_01C7F897.971367D0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable http://cuatheme.com/ compliments ccamp-archive Ejaculate further - Fire off like a cannon! Kaisa Lighthizer ------=_NextPart_000_0004_01C7F897.971367D0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
    http://cuatheme.com/
    compliments ccamp-archive
    Ejaculate further - Fire off like a = cannon!
    Kaisa Lighthizer
    ------=_NextPart_000_0004_01C7F897.971367D0-- From baruch@webworker.com Sun Sep 16 14:06:43 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWyW3-0002xC-Po for ccamp-archive@ietf.org; Sun, 16 Sep 2007 14:06:43 -0400 Received: from [201.245.31.113] (helo=201.245.31.113) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWyW3-0000ac-2I for ccamp-archive@ietf.org; Sun, 16 Sep 2007 14:06:43 -0400 Received: from [201.245.31.113] by ns1.nameserver-g.com; Sun, 16 Sep 2007 18:06:33 +0000 Message-ID: <000601c7f88c$02d8b47e$a02edfa7@ftfnrtin> From: "hiralal marina" To: Subject: All the class, luxury and prestige of the wealthy - all available Date: Sun, 16 Sep 2007 16:19:11 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7F88C.02D3980E" 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.7 (++++) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C7F88C.02D3980E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Luxury Pens=20 Tiffany & Co. Jewelry=20 Luxury Pens=20 Tiffany & Co. Jewelry The best prices!!! Click here to view all product ------=_NextPart_000_0003_01C7F88C.02D3980E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
  • Luxury Pens
  • Tiffany & Co. Jewelry
  • Luxury Pens
  • Tiffany & Co. Jewelry

    The best prices!!!

    Click here to view all product ------=_NextPart_000_0003_01C7F88C.02D3980E-- From Sampaio@dandjmail.com Sun Sep 16 15:48:23 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IX06R-00043Y-1U for ccamp-archive@megatron.ietf.org; Sun, 16 Sep 2007 15:48:23 -0400 Received: from [212.2.176.144] (helo=A-78-196.cust.iol.ie) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IX06M-0002ek-UC for ccamp-archive@megatron.ietf.org; Sun, 16 Sep 2007 15:48:23 -0400 Received: from PC1804 by dandjmail.com with ASMTP id E6F0E127 for ; Mon, 17 Sep 2007 03:48:46 +0800 Received: from PC1804 ([164.120.100.180]) by dandjmail.com with ESMTP id 415A7D2B2834 for ; Mon, 17 Sep 2007 03:48:46 +0800 Message-ID: <000601c7f89a$872a0b00$c44e7dc2@PC1804> From: "Chenfei Sampaio" To: Subject: szkarlat Date: Mon, 17 Sep 2007 03:48:17 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C7F8DD.954FBC00" 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.1 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0004_01C7F8DD.954FBC00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://crqsf.com/ greeting ccamp-archive A Bigger penis means much more enjoyment! Chenfei Sampaio ------=_NextPart_000_0004_01C7F8DD.954FBC00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    http://crqsf.com/
    greeting ccamp-archive
    A Bigger penis means much more = enjoyment!
    Chenfei Sampaio
    ------=_NextPart_000_0004_01C7F8DD.954FBC00-- From Kaka@vts.co.uk Sun Sep 16 16:45:40 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IX0zs-0001To-4g for ccamp-archive@megatron.ietf.org; Sun, 16 Sep 2007 16:45:40 -0400 Received: from p54880eb0.dip0.t-ipconnect.de ([84.136.14.176]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IX0zp-0004iE-TN for ccamp-archive@megatron.ietf.org; Sun, 16 Sep 2007 16:45:39 -0400 Received: from pentium4-buero ([108.139.184.153]:11908 "EHLO pentium4-buero" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by p54880EB0.dip0.t-ipconnect.de with ESMTP id S22DAAJZTHBXIGBI (ORCPT ); Sun, 16 Sep 2007 22:45:49 +0200 Message-ID: <000301c7f8a2$83910c20$b00e8854@pentium4buero> From: "Zach Kaka" To: Subject: bestuur Date: Sun, 16 Sep 2007 22:45:27 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7F8B3.4719DC20" 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.4 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0003_01C7F8B3.4719DC20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://cybertwn.com/ Evening ccamp-archive Do you want to have an average to small penis all of your life? No, you = don't Zach Kaka ------=_NextPart_000_0003_01C7F8B3.4719DC20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    http://cybertwn.com/
    Evening ccamp-archive
    Do you want to have an average to small penis = all of=20 your life? No, you don't
    Zach Kaka
    ------=_NextPart_000_0003_01C7F8B3.4719DC20-- From rvexh3wuw@carrefour.com Sun Sep 16 20:08:43 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IX4AN-0003bP-9A; Sun, 16 Sep 2007 20:08:43 -0400 Received: from [125.244.26.3] (helo=iunwnt) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IX4AM-0000wt-AI; Sun, 16 Sep 2007 20:08:42 -0400 To: From: "Freida Tijuana" Subject: CrazyDiscount: Codeine,PhenterminK,XanaK,AmbienK,Valiun,CialiK,ViagraK,SomaK mp Message-ID: <994r69083.2020k95242713@carrefour.com> Date: Mon, 17 Sep 2007 09:08:20 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--x8gjf96lydrp366svdmumb6x742nspn" X-Spam-Score: 2.1 (++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 ----x8gjf96lydrp366svdmumb6x742nspn Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit PharmaShop 80% Discount - Discreet Packaging - Cheapest Medication - Worldwide shipping - Buy in Bulk and Save CodeineK XanaxK ValiumK PhenterminK ViagraK ViagraGelK CialiK CialiKSoftTabs ViagraSoftTabsK SomaK AdalatK AllegraK AmbienK AtaraxK AtivanK CiproK EffexorK GlucophageK LevitraK LipitorK MeridiaK NorvascK PaxilK PropeciaK ProzacK UltramK ZocorK Zoloftk ZybanK plus 30 meds more http://kiju.kqinlast.com (Link 1) http://kblvpr.kqinlast.com (Link 2) ----x8gjf96lydrp366svdmumb6x742nspn Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
    PharmaShop 80% Discount
    Discreet Packaging
    Cheapest Medication
    Worldwide shipping
    Buy in Bulk and Save
    CodeineK
    XanaxK
    ValiumK
    PhenterminK
    ViagraK
    ViagraGelK
    CialiK
    CialiKSoftTabs
    ViagraSoftTabsK
    SomaK
    AdalatK
    AllegraK
    AmbienK
    AtaraxK
    AtivanK
    CiproK
    EffexorK
    GlucophageK
    LevitraK
    LipitorK
    MeridiaK
    NorvascK
    PaxilK
    PropeciaK
    ProzacK
    UltramK
    ZocorK
    ZoloftK
    ZybanK
    plus 30 meds more
    Buy Here - start from $72 (link A)
    (link B)

    companion corner repeated arm however deal. least disappoint longer was gotten given deal.



    ----x8gjf96lydrp366svdmumb6x742nspn-- From ojdave@informatti.com Mon Sep 17 00:35:36 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IX8Ke-0003CY-I8; Mon, 17 Sep 2007 00:35:36 -0400 Received: from [221.164.249.48] (helo=[221.164.249.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IX8Ke-0007lO-1M; Mon, 17 Sep 2007 00:35:36 -0400 Received: from [221.164.249.48] by mail.informatti.com; Mon, 17 Sep 2007 13:35:55 +0900 Message-ID: <01c7f8e4$3c60fe90$30f9a4dd@ojdave> From: "Karen Pierce" To: Subject: adobe acrobat V 8.0 Retail price $449 Our price US $ 79.95 You save - US $ 369.05 Date: Mon, 17 Sep 2007 13:35:55 +0900 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 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 X-Spam-Score: 4.1 (++++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 $269.90 adobe suite 3 http://www.puzzi.cn From amy.wolfe@mach5nyc.com Mon Sep 17 04:16:55 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXBmp-0003R3-Q0; Mon, 17 Sep 2007 04:16:55 -0400 Received: from [121.181.121.48] (helo=[121.181.121.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXBmS-0005gX-8d; Mon, 17 Sep 2007 04:16:32 -0400 Received: from [121.181.121.48] by q1.netfirms.com; Mon, 17 Sep 2007 17:16:53 +0900 Message-ID: <01c7f903$1ac33f90$3079b579@amy.wolfe> From: "Mamie Mack" To: Subject: 100mg x 30 pills $3.33 per pill price Date: Mon, 17 Sep 2007 17:16:53 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 7bit 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.8 (+++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Viagra 50mg x 10 pills $6.00 per pill price http://seefollow.com From muccfa@bootsandcans.com Mon Sep 17 08:09:10 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXFPa-0001D8-Ow; Mon, 17 Sep 2007 08:09:10 -0400 Received: from [81.215.159.6] (helo=dsl.dynamic812151596.ttnet.net.tr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXFPa-0004Y7-6Y; Mon, 17 Sep 2007 08:09:10 -0400 Received: from [81.215.159.6] by bootsandcans.com; Mon, 17 Sep 2007 14:10:40 +0200 Message-ID: <01c7f923$c3819710$069fd751@muccfa> From: "Ruby Stevens" To: Subject: Get UTYW Mon. Morn. Date: Mon, 17 Sep 2007 14:10:40 +0200 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Score: 2.2 (++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Second Chance On UTYW! UNITY WIRELESS CORP Sym: UTYW This is a REAL COMPANY, REAL EARNINGS, Making thier INVESTORS HUNDREDS OF THOUSANDS! Current: 0.06 Expected: 0.24 First Half Revenue Grew 53% to $4.8 Million Over the Same Period in 2006 Wireless Technology is and will be the Wave of the FUTURE! This Company in on the Breaking mark of coming out with a HUGE deal Tuesday! Company info: Unity Wireless is a leading ISO 9001:2000 certified developer of integrated RF (radio frequency) subsystem solutions for wireless communications networks. Integrated RF subsystems are an integral part of the base station and repeater infrastructure that comprise the backbone of wireless communications networks around the world. From analog cellular to 3G mobile and fixed wireless applications from 450 MHz to 3.5 GHz, Unity Wireless delivers RF subsystem solutions for the networks of today and tomorrow. The Company's integrated subsystems, single-carrier and multi-carrier power amplifier products deliver world-class efficiency and performance with field-proven quality and reliability in thousands of base stations and repeaters around the world. Keep your eye on UTYW news Monday. From guenter@tvheaven.com Mon Sep 17 12:31:27 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXJVP-0002yr-Tj for ccamp-archive@ietf.org; Mon, 17 Sep 2007 12:31:27 -0400 Received: from [195.135.236.10] (helo=host10.236.m9com.ru) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXJVP-0002VH-8n for ccamp-archive@ietf.org; Mon, 17 Sep 2007 12:31:27 -0400 Received: from [195.135.236.10] by ns1.freeservers.com; Mon, 17 Sep 2007 16:31:22 +0000 Message-ID: <000601c7f948$06e27d72$fd9f4b89@jtrmves> From: "egbert radcliff" To: Subject: Just call the number below Date: Mon, 17 Sep 2007 14:43:59 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7F948.06DF0ACE" 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: 1.2 (+) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C7F948.06DF0ACE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No Hassle Business Loans! If you have your own business and want: IMMEDIATE cash to spend ANY way you like Extra money to give the = business a boost.orried that your credit is less than perfect? Not an = issue. Just call the number below. You'll thank me later! Call Free 1 [ 8 7 7 ] 2 0 8 5 6 4 2 24 hours a day, 7 days a week including Sundays and Holidays! ------=_NextPart_000_0003_01C7F948.06DF0ACE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    No Hassle Business Loans!

    If you have your own business and want:

    • IMMEDIATE cash to spend ANY way you like
    • Extra money to give the business a boost.

    orried that your credit is less than perfect? Not an issue.

    Just call the number below.

    You'll thank me later!

    To: Subject: odnotib Date: Tue, 18 Sep 2007 02:22:29 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7F99A.C30B5C90" 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.6 (++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 ------=_NextPart_000_0007_01C7F99A.C30B5C90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.fssaps.com/ Evening ccamp-archive The added width to your penis fills and presses her from side to side to = give your partner the most exhilarating sensations Alh Domingues ------=_NextPart_000_0007_01C7F99A.C30B5C90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    http://www.fssaps.com/
    Evening ccamp-archive
    The added width to your penis fills and = presses her from=20 side to side to give your partner the most exhilarating = sensations
    Alh Domingues
    ------=_NextPart_000_0007_01C7F99A.C30B5C90-- From xi@mercury-spb.com Mon Sep 17 15:06:36 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXLvY-00056X-7D for ccamp-archive@ietf.org; Mon, 17 Sep 2007 15:06:36 -0400 Received: from [65.207.66.101] (helo=65.207.66.101) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXLvX-0006ES-0q for ccamp-archive@ietf.org; Mon, 17 Sep 2007 15:06:36 -0400 Received: from [65.207.66.101] by ns.mercury-spb.com; Mon, 17 Sep 2007 19:06:22 +0000 Message-ID: <000501c7f95d$05fb4c6d$d22ba8b4@tahcdhb> From: "gannon dieter" To: Subject: If you have your own business Date: Mon, 17 Sep 2007 17:18:59 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C7F95D.05F8FA84" 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: 2.7 (++) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C7F95D.05F8FA84 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No Hassle Business Loans! If you have your own business and want: IMMEDIATE cash to spend ANY way you like Extra money to give the = business a boost.orried that your credit is less than perfect? Not an = issue. Just call the number below. You'll thank me later! Call Free 1 [ 8 7 7 ] 2 0 8 5 6 4 2 24 hours a day, 7 days a week including Sundays and Holidays! ------=_NextPart_000_0002_01C7F95D.05F8FA84 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    No Hassle Business Loans!

    If you have your own business and want:

    • IMMEDIATE cash to spend ANY way you like
    • Extra money to give the business a boost.

    orried that your credit is less than perfect? Not an issue.

    Just call the number below.

    You'll thank me later!

    TLS-CIPHER: TLS-PEER-CN1: ) by [88.248.2.172] with ESMTP id S22ZODAPZWFVEEJB (ORCPT ); Mon, 17 Sep 2007 22:19:47 +0300 Message-ID: <000701c7f95f$a7e15400$ac02f858@IBMalim> From: "Brandis sasa" To: Subject: tight Date: Mon, 17 Sep 2007 22:19:23 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C7F978.CD2E8C00" 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.3 (+++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f ------=_NextPart_000_0006_01C7F978.CD2E8C00 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable http://curruy.com/ Good evening ccamp-archive When I looked in the mirror after every shower, I couldn=92t help but = wonder whether or not I was average. After doing some research online, I = realized that I was under-average =3D ( Brandis sasa ------=_NextPart_000_0006_01C7F978.CD2E8C00 Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable

    http://curruy.com/
    Good evening ccamp-archive
    When I looked in the mirror after every = shower, I=20 couldn=92t help but wonder whether or not I was average. After doing = some research=20 online, I realized that I was under-average =3D (
    Brandis sasa
    ------=_NextPart_000_0006_01C7F978.CD2E8C00-- From gopinath@rocketmail.com Mon Sep 17 16:47:04 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXNUm-0002tk-6F for ccamp-archive@ietf.org; Mon, 17 Sep 2007 16:47:04 -0400 Received: from 20151037114.user.veloxzone.com.br ([201.51.37.114]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXNUl-0003qp-HF for ccamp-archive@ietf.org; Mon, 17 Sep 2007 16:47:04 -0400 Received: from [201.51.37.114] by ns3.yahoo.com; Mon, 17 Sep 2007 20:46:20 +0000 Message-ID: <000701c7f96b$038abcd5$1445b791@mdhbuj> From: "garrett gerardo" To: Subject: Work from home no enter fee Date: Mon, 17 Sep 2007 18:58:57 +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.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 1.6 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Big international commercial organization is seeking of talented, honest, reliable representatives in different regions. Because of developing of our business the organization is proposing to you to become its part. You can work part time or full time. Requirements: Internet Connection Basic knowledge of PC Honesty Reliability Basic knowledge of marketing is a plus. If you want to get an opportunity to make a career, to earn some extra money, to gain new experience during the work, you should send us the following information to: DeonCainEO@gmail.com 1) Full name 2) Contact phone numbers 3) Languages 4) Part time job/Full time No investments needed to start working with us. The preference is given to employees with knowledge of foreign languages. Thank you and we are looking forward to cooperate in long term base with you. P.S. This job is not associated with "money muls" To study single molecules, Block has pioneered the use of optical tweezers, tiny laser-based "tractor beams" that produce miniscule piconewton forces to drag around molecules and allow measurements of displacements on the order of a nanometer. "You can stop and stall molecules, w follow their motion. Recently, we've studied the backtracking of RNA polymerase: when it makes a mistake, it can actually back up by five bases, scoop off the wrong thing and start again," says Block. While biological nanotechnology "hasn't even arrived at its infancy yet," says Block, "biological nanoscience is a very exciting place to be right now, because the techniques now exist to truly study proteins, and we're learning so much about them." From seaver@yourbestmedsource.com Mon Sep 17 17:38:59 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXOJ1-0002fM-IW for ccamp-archive@ietf.org; Mon, 17 Sep 2007 17:38:59 -0400 Received: from [78.113.57.230] (helo=[78.113.57.230]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXOIx-0004vd-Ty for ccamp-archive@ietf.org; Mon, 17 Sep 2007 17:38:56 -0400 Received: from jph-dell50 ([132.126.7.115] helo=jph-dell50) by [78.113.57.230] ( sendmail 8.13.3/8.13.1) with esmtpa id 1mHEcl-000IEB-Wo for ccamp-archive@ietf.org; Mon, 17 Sep 2007 23:39:44 +0200 Message-ID: <000c01c7f973$37b78dc0$e639714e@jphdell50> From: "Rayjay seaver" To: Subject: onazzori Date: Mon, 17 Sep 2007 23:39:25 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C7F983.FB405DC0" 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_0004_01C7F983.FB405DC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://fyjiao.com/ Good night ccamp-archive recommended by pornstars since 1999, this is there advantage Rayjay seaver ------=_NextPart_000_0004_01C7F983.FB405DC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    http://fyjiao.com/
    Good night ccamp-archive
    recommended by pornstars since 1999, this is = there advantage
    Rayjay seaver
    ------=_NextPart_000_0004_01C7F983.FB405DC0-- From DorotheacytoplasmThacker@seedmagazine.com Mon Sep 17 20:05:48 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXQb6-0003Ve-4b for ccamp-archive@ietf.org; Mon, 17 Sep 2007 20:05:48 -0400 Received: from cpe-065-184-062-094.ec.res.rr.com ([65.184.62.94] helo=stuarts.ec.rr.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IXQb3-0001MN-Mu for ccamp-archive@ietf.org; Mon, 17 Sep 2007 20:05:45 -0400 Message-ID: <9d0801c7f987$ac414b90$5e3eb841@Stuarts> From: "Dorothea Guidry" To: Subject: Fw: Thanks, we are ready to lend your company some cash Date: Mon, 17 Sep 2007 20:03:33 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_9D04_01C7F987.AC414B90" 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.5 (++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe This is a multi-part message in MIME format. ------=_NextPart_000_9D04_01C7F987.AC414B90 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 require IMMEDIATE money to spend ANY = way you like or need Extra money to give your company a boost or require = A low interest loan - NO STRINGS ATTACHED, here is our best deal we can = offer you NOW (hurry, this offer will expire THIS EVENING): $64,000+ loan Hurry, when the deal is gone, it is gone. Simply Call Us... Do not worry about approval, your credit history will not disqualify you! Call Us Free on 877-482-4954 ------=_NextPart_000_9D04_01C7F987.AC414B90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20
    Your credit does not matter to=20 us!
    =20
     
    If you have your own business and = require=20 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 best deal we can offer you NOW (hurry, this offer will expire THIS=20 EVENING):
    =20
     
    $64,000+ loan
     
    Hurry, when the deal is gone, it = is gone.=20 Simply Call Us...
    =20
     
    Do not worry about approval, your = credit history will not disqualify you!
    =20
     
    Call Us Free on = 877-482-4954
    ------=_NextPart_000_9D04_01C7F987.AC414B90-- From webmaster@mymagicads.com Mon Sep 17 21:45:30 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXS9a-0002PH-B5 for ccamp-archive@ietf.org; Mon, 17 Sep 2007 21:45:30 -0400 Received: from p6029-ipad208kobeminato.hyogo.ocn.ne.jp ([60.44.77.29]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXS9U-0003Q1-Lf for ccamp-archive@ietf.org; Mon, 17 Sep 2007 21:45:25 -0400 Received: from [60.44.77.29] by mymagicads.com; Tue, 18 Sep 2007 10:50:00 +0900 Message-ID: <01c7f996$39264b10$1d4d2c3c@webmaster> From: "Cheryl Reyna" To: Subject: Urgent healthcare info Date: Tue, 18 Sep 2007 10:50:00 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Spam-Score: 2.0 (++) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 All mens all over the world trust the quality of the brand-name goods that we supply them with! Now it is your turn to see how reliable they can be - and enjoy their indubitable effectiveness! http://adlam.hairnew.com/?535194160396 From norman.Mirza@CANDIESINC.COM Tue Sep 18 00:47:50 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXV02-0007Kz-JJ for ccamp-archive@megatron.ietf.org; Tue, 18 Sep 2007 00:47:50 -0400 Received: from dyn-83-157-227-157.ppp.tiscali.fr ([83.157.227.157] helo=[83.157.239.101]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXUzy-0007aj-2W for ccamp-archive@megatron.ietf.org; Tue, 18 Sep 2007 00:47:46 -0400 Received: from lsdbot-iii ([121.102.115.76] helo=lsdbot-iii) by dyn-91-168-89-219.ppp.tiscali.fr ( sendmail 8.13.3/8.13.1) with esmtpa id 1ermgr-000TGO-Zl for ccamp-archive@megatron.ietf.org; Tue, 18 Sep 2007 06:52:39 +0200 Message-ID: <000301c7f9af$a92c8a50$db59a85b@lsdbotiii> From: "norman Mirza" To: Subject: wo"lbung Date: Tue, 18 Sep 2007 06:52:05 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C7F9C0.6CB55A50" 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_01C7F9C0.6CB55A50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://fvtennis.com/ Good day ccamp-archive my girl loves the new me. norman Mirza ------=_NextPart_000_0006_01C7F9C0.6CB55A50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    http://fvtennis.com/
    Good day ccamp-archive
    my girl loves the new me.
    norman Mirza
    ------=_NextPart_000_0006_01C7F9C0.6CB55A50-- From Mandic@eshauk.demon.co.uk Tue Sep 18 09:25:22 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXd4s-0005iq-SE for ccamp-archive@ietf.org; Tue, 18 Sep 2007 09:25:22 -0400 Received: from [88.238.157.97] (helo=dsl88.238-40289.ttnet.net.tr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXd4Z-0002va-UV for ccamp-archive@ietf.org; Tue, 18 Sep 2007 09:25:04 -0400 Received: by 10.119.182.97 with SMTP id CRHwSLBJPKRhB; Tue, 18 Sep 2007 16:25:01 +0300 (GMT) Received: by 192.168.185.50 with SMTP id KKdnBkDQmxyQEg.6691106559329; Tue, 18 Sep 2007 16:24:59 +0300 (GMT) Message-ID: <000401c7f9f7$4def5f80$619dee58@CeM> From: "Aleksander Mandic" To: Subject: 1539 Date: Tue, 18 Sep 2007 16:24:56 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C7FA10.733C9780" 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_01C7FA10.733C9780 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable http://datout.com/ Wassup ccamp-archive recommended by pornstars since 1999, this is there advantage Aleksander Mandic ------=_NextPart_000_0005_01C7FA10.733C9780 Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable
    http://datout.com/
    Wassup ccamp-archive
    recommended by pornstars since 1999, this is = there advantage
    Aleksander Mandic
    ------=_NextPart_000_0005_01C7FA10.733C9780-- From gilbreathfyxs@eshauk.demon.co.uk Tue Sep 18 09:27:37 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXd73-0000bi-So for ccamp-archive@megatron.ietf.org; Tue, 18 Sep 2007 09:27:37 -0400 Received: from [88.238.157.97] (helo=dsl88.238-40289.ttnet.net.tr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXd72-0006xb-8S for ccamp-archive@megatron.ietf.org; Tue, 18 Sep 2007 09:27:37 -0400 Received: by 10.17.140.197 with SMTP id cBErUBdIDvFNH; Tue, 18 Sep 2007 16:27:34 +0300 (GMT) Received: by 192.168.143.92 with SMTP id iurNpdAdWePWhO.5323770323485; Tue, 18 Sep 2007 16:27:32 +0300 (GMT) Message-ID: <000c01c7f9f7$a9156b20$619dee58@CeM> From: "adonis gilbreath" To: Subject: 0urinal Date: Tue, 18 Sep 2007 16:27:29 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C7FA10.CE62A320" 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.7 (++++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0006_01C7FA10.CE62A320 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable http://cotimvui.com/ greeting ccamp-archive I always wanted a bigger pe*nis, so did my wife! adonis gilbreath ------=_NextPart_000_0006_01C7FA10.CE62A320 Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable
    http://cotimvui.com/
    greeting ccamp-archive
    I always wanted a bigger pe*nis, so did my = wife!
    adonis gilbreath
    ------=_NextPart_000_0006_01C7FA10.CE62A320-- From Kansalmiz@COMPUCONUSA.COM Tue Sep 18 11:27:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXeyb-0004UN-5N for ccamp-archive@megatron.ietf.org; Tue, 18 Sep 2007 11:27:01 -0400 Received: from aadr123.neoplus.adsl.tpnet.pl ([83.4.95.123]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXeyW-0006aX-JE for ccamp-archive@megatron.ietf.org; Tue, 18 Sep 2007 11:26:57 -0400 Received: from sea ([125.137.174.9]:10013 "EHLO sea" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by aadr123.neoplus.adsl.tpnet.pl with ESMTP id S22VEHTZIHGFFGMK (ORCPT ); Tue, 18 Sep 2007 17:30:40 +0200 Message-ID: Date: Tue, 18 Sep 2007 17:30:25 +0200 From: "Juca Kansal" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ccamp-archive@megatron.ietf.org Subject: ripalani Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.0 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea hello ccamp-archive ladies like em big, so i enlarged mine.. Juca Kansal http://coolroam.com/ From pyv@sre.gob.mx Tue Sep 18 12:48:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXgFS-0007kr-GC for ccamp-archive@megatron.ietf.org; Tue, 18 Sep 2007 12:48:30 -0400 Received: from rrcs-24-172-181-125.central.biz.rr.com ([24.172.181.125]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IXgFG-0003z6-Hs for ccamp-archive@megatron.ietf.org; Tue, 18 Sep 2007 12:48:25 -0400 Received: from utfbr ([190.35.71.171]) by rrcs-24-172-181-125.central.biz.rr.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 Sep 2007 12:47:28 -0400 Message-ID: <001d01c7fa13$99171d60$ab4723be@utfbr> From: To: Subject: Wow, free games! Date: Tue, 18 Sep 2007 12:47:28 -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 5.50.4131.1600 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4131.1600 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 No more spending money on online games, get them all for free http://89.178.185.50/ From owner-ccamp@ops.ietf.org Tue Sep 18 13:22:58 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXgmo-0003RQ-8d for ccamp-archive@ietf.org; Tue, 18 Sep 2007 13:22:58 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXgmi-0004nr-Th for ccamp-archive@ietf.org; Tue, 18 Sep 2007 13:22:54 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IXgaT-0009q0-VH for ccamp-data@psg.com; Tue, 18 Sep 2007 17:10:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE,USER_IN_ALL_SPAM_TO autolearn=no version=3.2.1 Received: from [66.226.64.2] (helo=pro.abac.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IXgaR-0009pP-A6 for ccamp@ops.ietf.org; Tue, 18 Sep 2007 17:10:12 +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 l8IH9if6013913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Sep 2007 10:09:45 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <46F00655.9080803@grotto-networking.com> Date: Tue, 18 Sep 2007 10:09:41 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ccamp , pce@ietf.org Subject: Wavelength Switched Optical Networks -- revised draft available Content-Type: multipart/alternative; boundary="------------090308000305090504020604" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 This is a multi-part message in MIME format. --------------090308000305090504020604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello fellow, CCAMPers and PCEers, a revised draft on wavelength switched optical networks entitled: "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks" is now available at: http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-01.txt The intention is to have this document adopted as a working group draft at either CCAMP or PCE and use it to guide the various "solution" drafts that are being generated with respect to wavelength switched optical networks. *Abstract: * This memo provides a framework for applying Generalized Multi- Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of wavelength switched optical networks (WSON). In particular we provide control plane models for key wavelength switched optical network subsystems and processes. The subsystems include wavelength division multiplexed links, tunable laser transmitters, reconfigurable optical add/drop multiplexers (ROADM) and wavelength converters. Lightpath provisioning, in general, requires the routing and wavelength assignment (RWA) process. This process is reviewed and the information requirements, both static and dynamic for this process are presented, along with alternative implementation scenarios that could be realized via GMPLS/PCE and/or extended GMPLS/PCE protocols. This memo does NOT address optical impairments in any depth and focuses on topological elements and path selection constraints that are common across different WSON environments. It is expected that a variety of different techniques will be applied to optical impairments depending on the type of WSON, such as access, metro or long haul. Regards Greg B, Young L. and Wataru I. -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------090308000305090504020604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello fellow, CCAMPers and PCEers,
    a revised draft on wavelength switched optical networks entitled: "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks" is now available at: http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-01.txt

    The intention is to have this document adopted as a working group draft at either CCAMP or PCE and use it to guide the various "solution" drafts that are being generated with respect to wavelength switched optical networks.

    Abstract:
    This memo provides a framework for applying Generalized Multi- Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of wavelength switched optical networks (WSON). In particular we provide control plane models for key wavelength switched optical network subsystems and processes. The subsystems include wavelength division multiplexed links, tunable laser transmitters, reconfigurable optical add/drop multiplexers (ROADM) and wavelength converters. Lightpath provisioning, in general, requires the routing and wavelength assignment (RWA) process. This process is reviewed and the information requirements, both static and dynamic for this process are presented, along with alternative implementation scenarios that could be realized via GMPLS/PCE and/or extended GMPLS/PCE protocols. This memo does NOT address optical impairments in any depth and focuses on topological elements and path selection constraints that are common across different WSON environments. It is expected that a variety of different techniques will be applied to optical impairments depending on the type of WSON, such as access, metro or long haul.

    Regards

    Greg B, Young L. and Wataru I.
    -- 
    ===================================================
    Dr Greg Bernstein, Grotto Networking (510) 573-2237
    
    
    --------------090308000305090504020604-- From laurynmefu@zilber.com Tue Sep 18 20:01:38 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXn0c-0004QC-LC for ccamp-archive@megatron.ietf.org; Tue, 18 Sep 2007 20:01:38 -0400 Received: from c-75-70-195-72.hsd1.co.comcast.net ([75.70.195.72]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IXn0R-0008VX-Cb for ccamp-archive@megatron.ietf.org; Tue, 18 Sep 2007 20:01:33 -0400 Received: from [183.80.198.160] (helo=fnbp) by c-75-70-195-72.hsd1.co.comcast.net with smtp (Exim 4.62 (FreeBSD)) id 1Jn1C-0007V5-PB; Tue, 18 Sep 2007 18:02:14 -0600 Message-ID: <002301c7fa50$23ebeba0$a0c650b7@fnbp> From: To: Subject: Stop blowing your money Date: Tue, 18 Sep 2007 18:00:51 -0600 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.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Get all your pharmaceuticals for wholesale prices http://tsewzeh.otherblock.cn/?178821140505 From cup@mynmail.com Tue Sep 18 20:40:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXncR-00034x-3P for ccamp-archive@megatron.ietf.org; Tue, 18 Sep 2007 20:40:43 -0400 Received: from [125.187.32.133] (helo=m10.mailyes.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXncK-0000y2-Gv for ccamp-archive@megatron.ietf.org; Tue, 18 Sep 2007 20:40:43 -0400 Received: (qmail 1492 invoked by uid 0); 19 Sep 2007 09:08:25 +0900 Message-ID: <20070919000825.1491.qmail@m10.mailyes.net> To: ccamp-archive Subject: =?ISO-2022-JP?B?GyRCJDkkMCRLOCskRCQrJGsbKEI=?= =?ISO-2022-JP?B?GyRCISM1VTFnPXdALRsoQg==?= From: freemail Reply-to: delivery_rt Date: 2007-09-19 09:00:02 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: GOOD Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20070918180343_cbur Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 2.8 (++) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 $B"#(3"#(3"#(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B(2"#(6"#(B $B"#(6"#!!!!!!!!;I7c$K52$($F$$$k=w@-$,5^A}Cf$G$9(B $B(2"#!!!!!!!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1(B $B"#(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B!!!!!!!!!!(Bhttp://black-6969.org.uk/pc/index2.php?u9psp4 $B(.(.(3(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B(2"!(4B`6~$JF|>o$K>/$7$G$b5$;}$A$h$/$F3Z$7$$;~4V$r(B $B(1(0(5(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B http://black-6969.org.uk/pc/index2.php?u9psp4 $B?M:J$,=P2q$$$r5a$a$k$N$O2?8N$G$7$g$&!)(B $B!&IaCJ$N@83h$G;I7c$,$J$$!#(B $B!&IW0J30$N?M$H$7$F$_$?$$!#(B $B!&4m$J$$4X78$r4uK>!#(B $BIaCJ2H$K$$$k?M:J$OB`6~$JF|>o$KK0$-$F$$$^$9!#(B $B>/$7$G$b5$;}$A$h$/$F3Z$7$$;I7c$r5a$a$F$$$^$9!#(B $B?M:J$H=P2q$$$?$$>l9g$O$3$3$,%]%$%s%H$G$9!#(B $B!V0lHU8B$j!"3d$j@Z$j$N4X78$G2q$($J$$$G$9$+!)!W(B http://black-6969.org.uk/pc/index2.php?u9psp4 $B$J$k$Y$/Aa$a$K2q$&$3$H$,%]%$%s%H$G$9!#(B $B?M:J$,%"%/%;%9$7$F$/$k;~4VBS(B $B!a(B $BC6Fa$K8+$D$+$i$:$K9TF0=PMh$k;~4V(B $B$@$+$i$G$9!#(B $B$?$@$7!"6/0z2a$.$k$N$bLdBj$J$N$G!"@aEY$"$k9TF0$r(B^^; http://black-6969.org.uk/pc/index2.php?u9psp4 $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!($(B $B:G9bJv=P2q$$%5%$%H!*!X$46a=j=P2q$$!Y(B URL $B!'(B http://black-6969.org.uk/pc/index2.php?u9psp4 $B$3$N%a!<%k$K=q$+$l$?FbMF$NL5CG7G:\!"L5CGJ#@=$r6X$8$^$9!#(B Copyright (C) 2007 gokinjo All Rights Reserved. $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(%(B $B"(G[?.Dd;_$O$3$A$i$+$i(B notmail@gmail.com From cup@mynmail.com Tue Sep 18 21:17:00 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXoBY-00055U-7J for ccamp-archive@ietf.org; Tue, 18 Sep 2007 21:17:00 -0400 Received: from [125.187.32.133] (helo=m10.mailyes.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXoBW-0001sg-LL for ccamp-archive@ietf.org; Tue, 18 Sep 2007 21:17:00 -0400 Received: (qmail 26558 invoked by uid 0); 19 Sep 2007 09:03:14 +0900 Message-ID: <20070919000314.26557.qmail@m10.mailyes.net> To: ccamp-archive Subject: =?ISO-2022-JP?B?GyRCJDkkMCRLOCskRCQrJGsbKEI=?= =?ISO-2022-JP?B?GyRCISM1VTFnPXdALRsoQg==?= From: freemail Reply-to: delivery_rt Date: 2007-09-19 09:00:02 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: GOOD Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20070918180343_cbur Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 2.8 (++) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 $B"#(3"#(3"#(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B(2"#(6"#(B $B"#(6"#!!!!!!!!;I7c$K52$($F$$$k=w@-$,5^A}Cf$G$9(B $B(2"#!!!!!!!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1(B $B"#(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B!!!!!!!!!!(Bhttp://black-6969.org.uk/pc/index2.php?u9psp4 $B(.(.(3(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B(2"!(4B`6~$JF|>o$K>/$7$G$b5$;}$A$h$/$F3Z$7$$;~4V$r(B $B(1(0(5(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B http://black-6969.org.uk/pc/index2.php?u9psp4 $B?M:J$,=P2q$$$r5a$a$k$N$O2?8N$G$7$g$&!)(B $B!&IaCJ$N@83h$G;I7c$,$J$$!#(B $B!&IW0J30$N?M$H$7$F$_$?$$!#(B $B!&4m$J$$4X78$r4uK>!#(B $BIaCJ2H$K$$$k?M:J$OB`6~$JF|>o$KK0$-$F$$$^$9!#(B $B>/$7$G$b5$;}$A$h$/$F3Z$7$$;I7c$r5a$a$F$$$^$9!#(B $B?M:J$H=P2q$$$?$$>l9g$O$3$3$,%]%$%s%H$G$9!#(B $B!V0lHU8B$j!"3d$j@Z$j$N4X78$G2q$($J$$$G$9$+!)!W(B http://black-6969.org.uk/pc/index2.php?u9psp4 $B$J$k$Y$/Aa$a$K2q$&$3$H$,%]%$%s%H$G$9!#(B $B?M:J$,%"%/%;%9$7$F$/$k;~4VBS(B $B!a(B $BC6Fa$K8+$D$+$i$:$K9TF0=PMh$k;~4V(B $B$@$+$i$G$9!#(B $B$?$@$7!"6/0z2a$.$k$N$bLdBj$J$N$G!"@aEY$"$k9TF0$r(B^^; http://black-6969.org.uk/pc/index2.php?u9psp4 $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!($(B $B:G9bJv=P2q$$%5%$%H!*!X$46a=j=P2q$$!Y(B URL $B!'(B http://black-6969.org.uk/pc/index2.php?u9psp4 $B$3$N%a!<%k$K=q$+$l$?FbMF$NL5CG7G:\!"L5CGJ#@=$r6X$8$^$9!#(B Copyright (C) 2007 gokinjo All Rights Reserved. $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(%(B $B"(G[?.Dd;_$O$3$A$i$+$i(B notmail@gmail.com From iudoa48rtx@repsolypf.com Tue Sep 18 21:39:47 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXoXb-00017W-NC; Tue, 18 Sep 2007 21:39:47 -0400 Received: from [212.80.67.131] (helo=yjkr) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IXoXW-0007Hx-8H; Tue, 18 Sep 2007 21:39:42 -0400 To: From: "Theo Latonya" Subject: Buy 2007 Rolex Replica :: Now Special Offer, Only On This Site! irnq Message-ID: <77069j74675.648j04585669@repsolypf.com> Date: Wed, 19 Sep 2007 03:39:33 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--0u6x5zide27a64mzqog2lqzn0ssfy" X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 ----0u6x5zide27a64mzqog2lqzn0ssfy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Super Branded Watches (85% Price Off) : RolexMen : RolexLady : Alain Silberstein : Audemars Piguet : Breitling : Bvlgari : Cartier : Chanel : Chopard : Franck Muller : IWC : Jaeger-Lecoultre : Omega : Panerai Luminor : Patek Philippe : Tag Heuer Only from $189 Each :- Click below link http://rvgk.kucamera.com http://rdvzz.kucamera.com ----0u6x5zide27a64mzqog2lqzn0ssfy Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
    Super Branded Watches (85% Price Off)
    RolexMen
    RolexLady
    Alain Silberstein
    Audemars Piguet
    Breitling
    Bvlgari
    Cartier
    Chanel
    Chopard
    Franck Muller
    IWC
    Jaeger-Lecoultre
    Omega
    Panerai Luminor
    Patek Philippe
    Tag Heuer
    Only from $189 Each :- Click below link
    [Link 1]     [Link 2]

    embarrass words commit rich king longer arms dare. proud perhaps supposedto years out cold cold.
    ----0u6x5zide27a64mzqog2lqzn0ssfy-- From subhojit-Milner@jsfp.org.cn Tue Sep 18 23:46:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXqWQ-0001OC-Vz for ccamp-archive@ietf.org; Tue, 18 Sep 2007 23:46:42 -0400 Received: from h460ce829.area2.spcsdns.net ([70.12.232.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXqWH-0004lz-5v for ccamp-archive@ietf.org; Tue, 18 Sep 2007 23:46:39 -0400 Received: from TOSHIBA ([178.135.35.138] helo=TOSHIBA) by h460c8095.area2.spcsdns.net ( sendmail 8.13.3/8.13.1) with esmtpa id 1ysREI-000NFO-yX for ccamp-archive@ietf.org; Tue, 18 Sep 2007 22:46:18 -0500 Message-ID: Date: Tue, 18 Sep 2007 22:45:49 -0500 From: "subhojit Milner" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: nterions Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.7 (+) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Hi there ccamp-archive Adding inches to your cock.. subhojit Milner http://www.ctient.com/ From ads36fcr@usinternet.com Wed Sep 19 00:13:48 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXqwe-0003mW-8n for ccamp-archive@ietf.org; Wed, 19 Sep 2007 00:13:48 -0400 Received: from vpn.kcmsd.k12.mo.us ([169.142.1.1] helo=qjkgexso) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IXqwI-0002D4-LP for ccamp-archive@ietf.org; Wed, 19 Sep 2007 00:13:26 -0400 To: From: "Dayna Thanh" Subject: CrazyDiscount: Codeine,PhenterminK,XanaK, AmbienK,Valiun,CialiK,ViagraK,SomaK qfxy Message-ID: <8790s69927.448y60413047@usinternet.com> Date: Tue, 18 Sep 2007 23:13:29 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--9bh4mam6unm0ho1r1wnz49ht1ipjeqgk" X-Spam-Score: 2.2 (++) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c ----9bh4mam6unm0ho1r1wnz49ht1ipjeqgk Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit PharmaShop 80% Discount - Discreet Packaging - Cheapest Medication - Worldwide shipping - Buy in Bulk and Save CodeineK XanaxK ValiumK PhenterminK ViagraK ViagraGelK CialiK CialiKSoftTabs ViagraSoftTabsK SomaK AdalatK AllegraK AmbienK AtaraxK AtivanK CiproK EffexorK GlucophageK LevitraK LipitorK MeridiaK NorvascK PaxilK PropeciaK ProzacK UltramK ZocorK Zoloftk ZybanK plus 30 meds more http://knzs.kuallegedly.com (Link 1) http://kall.kuallegedly.com (Link 2) ----9bh4mam6unm0ho1r1wnz49ht1ipjeqgk Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
    PharmaShop 80% Discount
    Discreet Packaging
    Cheapest Medication
    Worldwide shipping
    Buy in Bulk and Save
    CodeineK
    XanaxK
    ValiumK
    PhenterminK
    ViagraK
    ViagraGelK
    CialiK
    CialiKSoftTabs
    ViagraSoftTabsK
    SomaK
    AdalatK
    AllegraK
    AmbienK
    AtaraxK
    AtivanK
    CiproK
    EffexorK
    GlucophageK
    LevitraK
    LipitorK
    MeridiaK
    NorvascK
    PaxilK
    PropeciaK
    ProzacK
    UltramK
    ZocorK
    ZoloftK
    ZybanK
    plus 30 meds more
    Buy Here - start from $72 (link A)
    (link B)

    ticket human black progress glass difficult how? burst window find leader,



    ----9bh4mam6unm0ho1r1wnz49ht1ipjeqgk-- From ethrough@preti.com Wed Sep 19 01:20:58 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXrze-0002FD-O6 for ccamp-archive@ietf.org; Wed, 19 Sep 2007 01:20:58 -0400 Received: from [62.5.149.41] (helo=preti.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IXrzF-00044g-14 for ccamp-archive@ietf.org; Wed, 19 Sep 2007 01:20:33 -0400 Received: (qmail 34012 invoked from network); Wed, 19 Sep 2007 09:27:23 +0400 Received: from unknown (HELO MesnyankinSA) (ethrough@preti.com@69.198.228.45) by 2995053epreti.com with SMTP; Wed, 19 Sep 2007 09:27:23 +0400 Message-ID: <001701c7fa9f$48bc1be0$00d8f104@MesnyankinSA> From: since do To: ccamp-archive@ietf.org Subject: To it tower Date: Wed, 19 Sep 2007 09:27:23 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C7FA9F.48BC1BE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.1158 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2720.2963 X-Spam-Score: 2.1 (++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C7FA9F.48BC1BE0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable unattainable. The cause of this disastrous situation cannot be painter may = not believe the brush tool of the paint program could a family, individual, etc. could have access to more information ------=_NextPart_000_0014_01C7FA9F.48BC1BE0 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable

    follows my instructions and quickly produces the exact drawing I

    Are you wanting a bigger p >e n _i s?

    As se -e -n on TV

    Over 764,000 Men around the world are already satisfied
    Gain 2+ Inches In Leng _th
    Increase Your P _en -is Wi _dth (Girth) By up _to 25%
    100% Safe To Take, With NO Side Effects
    No Pum ps! No Surg ery! No Ex ercises!
    *3 FREE Bottles

    conservatives. There must be an interest in developing both
    ------=_NextPart_000_0014_01C7FA9F.48BC1BE0-- From LindsaygauntletRitchie@nononsenseselfdefense.com Wed Sep 19 03:06:59 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXteF-0001kw-4t for ccamp-archive@ietf.org; Wed, 19 Sep 2007 03:06:59 -0400 Received: from [124.29.194.112] (helo=farooq) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IXtdr-0006Yj-V9 for ccamp-archive@ietf.org; Wed, 19 Sep 2007 03:06:36 -0400 Message-ID: <0ce701c7fa8b$9ef409a0$1701a8c0@Farooq> From: "Cora Dobson" To: Subject: Fwd: Thank you, we are accepting your company application Date: Wed, 19 Sep 2007 12:03:55 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0CE3_01C7FA8B.9EF409A0" 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.2 (+++) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da This is a multi-part message in MIME format. ------=_NextPart_000_0CE3_01C7FA8B.9EF409A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your your credit report doesn't matter to us! If you have your own business and require IMMEDIATE money to spend ANY = way you like or require Extra money to give your business a boost or = require A low interest loan - NO STRINGS ATTACHED, here is our best deal = we can offer you TODAY (hurry, this offer will expire THIS NIGHT): $27,000+ loan Hurry, when best deal is gone, it is gone. Simply Call Us... Do not worry about approval, your credit history will not disqualify you! Call Us Free on 877-482-4954 ------=_NextPart_000_0CE3_01C7FA8B.9EF409A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20
    Your your credit report doesn't = matter to=20 us!
    =20
     
    If you have your own business and = require IMMEDIATE money to spend ANY way you like or require Extra money to give = your=20 business a boost or require A low interest loan - NO STRINGS ATTACHED, = here is=20 our best deal we can offer you TODAY (hurry, this offer will expire THIS = NIGHT):
    =20
     
    $27,000+ loan
     
    Hurry, when best deal is gone, it = is gone.=20 Simply Call Us...
    =20
     
    Do not worry about approval, your = credit history=20 will not disqualify you!
    =20
     
    Call Us Free on = 877-482-4954
    ------=_NextPart_000_0CE3_01C7FA8B.9EF409A0-- From michael.arpey@frabelle.net Wed Sep 19 03:19:22 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXtqE-0005ng-5k for ccamp-archive@ietf.org; Wed, 19 Sep 2007 03:19:22 -0400 Received: from static-68-161-232-21.ny325.east.verizon.net ([68.161.232.21]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IXtpy-0006st-4s for ccamp-archive@ietf.org; Wed, 19 Sep 2007 03:19:06 -0400 Received: (qmail 12828 invoked from network); Wed, 19 Sep 2007 03:20:05 -0400 Received: from unknown (HELO ujfl) (98.49.117.210) by static-68-161-232-21.ny325.east.verizon.net with SMTP; Wed, 19 Sep 2007 03:20:05 -0400 Message-ID: <002501c7fa8d$80af3fd0$d2753162@ujfl> From: To: Subject: New free game software has over 1000 games Date: Wed, 19 Sep 2007 03:20:05 -0400 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 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 One Thousand games Online.......Free. Check it out http://68.81.170.228/ From balon@omldc-rnd.ru Wed Sep 19 03:19:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXtqj-0006Sh-FX for ccamp-archive@megatron.ietf.org; Wed, 19 Sep 2007 03:19:53 -0400 Received: from static-68-161-232-21.ny325.east.verizon.net ([68.161.232.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IXtqZ-00013S-85 for ccamp-archive@megatron.ietf.org; Wed, 19 Sep 2007 03:19:49 -0400 Received: (qmail 4124 invoked from network); Wed, 19 Sep 2007 03:20:14 -0400 Received: from unknown (HELO gwgot) (140.48.95.239) by static-68-161-232-21.ny325.east.verizon.net with SMTP; Wed, 19 Sep 2007 03:20:14 -0400 Message-ID: <000701c7fa8d$85af0100$ef5f308c@gwgot> From: To: Subject: Check this out Date: Wed, 19 Sep 2007 03:20:14 -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.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 1000 plus games for free... Check it out http://75.23.95.180/ From uli@mac.com Wed Sep 19 04:19:28 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXumO-0001jp-L6 for ccamp-archive@ietf.org; Wed, 19 Sep 2007 04:19:28 -0400 Received: from [88.80.106.150] (helo=88.80.106.150) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXumO-0000ED-0a for ccamp-archive@ietf.org; Wed, 19 Sep 2007 04:19:28 -0400 Received: from [88.80.106.150] by nserver3.apple.com; Wed, 19 Sep 2007 08:23:40 +0000 Message-ID: <000901c7fa96$01c2face$6bfd868d@vyvtoyh> From: "clark patel" To: Subject: You'll thank me later! Date: Wed, 19 Sep 2007 06:36:18 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C7FA96.01BFB195" 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: 2.7 (++) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C7FA96.01BFB195 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No Hassle Business Loans! If you have your own business and want: IMMEDIATE cash to spend ANY way you like Extra money to give the = business a boost.orried that your credit is less than perfect? Not an = issue. Just call the number below. You'll thank me later! Call Free 1 [ 8 7 7 ] 2 0 8 _ 5 6 _ 4 2 24 hours a day, 7 days a week including Sundays and Holidays! ------=_NextPart_000_0006_01C7FA96.01BFB195 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    No Hassle = Business Loans!

    If you have your own business and want:

    • IMMEDIATE cash to spend ANY way you like
    • Extra money to give the business a boost.

    orried that your credit is less than perfect? Not an = issue.

    Just call the number below.

    You'll thank me later!

    Call = Free 1 [ 8 7 7 ] 2 0 8 = _ 5 6 _ 4 2

    24 hours a day, 7 days a week including = Sundays and Holidays!

    ------=_NextPart_000_0006_01C7FA96.01BFB195-- From Schuttler@alasercenter.com Wed Sep 19 06:14:18 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXwZW-00049t-Jw for ccamp-archive@megatron.ietf.org; Wed, 19 Sep 2007 06:14:18 -0400 Received: from host127-100-static.119-81-b.business.telecomitalia.it ([81.119.100.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXwZQ-0005kX-0H for ccamp-archive@megatron.ietf.org; Wed, 19 Sep 2007 06:14:18 -0400 Received: from SEGRETARIO ([143.104.128.99]:24018 "EHLO SEGRETARIO" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [81.119.100.127] with ESMTP id S22FLNAHECYGZUTO (ORCPT ); Wed, 19 Sep 2007 12:03:07 +0200 Message-ID: <000901c7faa4$3d7d7080$7f647751@SEGRETARIO> From: "abul Schuttler" To: Subject: n{myttev Date: Wed, 19 Sep 2007 12:02:51 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C7FAB5.01064080" 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: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0004_01C7FAB5.01064080 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.majna.com/ compliments ccamp-archive I had been looking all over the place for the best penis enlargement = supplements and now I finally found them abul Schuttler ------=_NextPart_000_0004_01C7FAB5.01064080 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    http://www.majna.com/
    compliments ccamp-archive
    I had been looking all over the place for the = best penis=20 enlargement supplements and now I finally found them
    abul Schuttler
    ------=_NextPart_000_0004_01C7FAB5.01064080-- From gzfunfolds@69gayfuck.com Wed Sep 19 07:13:47 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXxV5-0000gP-0t; Wed, 19 Sep 2007 07:13:47 -0400 Received: from [124.114.104.237] (helo=69gayfuck.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IXxUw-0004oq-Hc; Wed, 19 Sep 2007 07:13:41 -0400 Received: from Chenzh ([32.185.111.23]) by 124.114.104.237 (9.1.4/5.7.5) with SMTP id e9e8b5f0284ebb; Wed, 19 Sep 2007 19:13:49 +0800 Message-ID: <001401c7faf1$357c4f30$07fd44bc@Chenzh> From: "Lucille Beard" To: "ccamp-archive" Subject: WonderCum has been developed to give you, the consumer, the ultimate semen enhancement product. Date: Wed, 19 Sep 2007 19:10:49 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1251"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.1081 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2969 X-Spam-Score: 2.1 (++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Aid in overcoming male sexual problems especially poor sperm count and quality by promoting spermatogenesis. http://morpyus.com From dan@stswithuns.com Wed Sep 19 07:29:41 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXxkT-0000TX-Ub for ccamp-archive@ietf.org; Wed, 19 Sep 2007 07:29:41 -0400 Received: from [200.150.17.97] (helo=200150010057.static.corp.wayinternet.com.br) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXxkT-0005DD-1U for ccamp-archive@ietf.org; Wed, 19 Sep 2007 07:29:41 -0400 Received: from [200.150.10.57] by dns02e.hants.gov.uk; Wed, 19 Sep 2007 11:30:12 +0000 Message-ID: <000701c7fab0$04457009$bc15c5b1@cwimde> From: "jeffie goliath" To: Subject: High-paid positions in a large successful company are waiting for talented candidates. (no signup fees) Date: Wed, 19 Sep 2007 09:42:49 +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.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 0.7 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Big international commercial organization is seeking of talented, honest, reliable representatives in different regions. Because of developing of our business the organization is proposing to you to become its part. You can work part time or full time. Requirements: Internet Connection Basic knowledge of PC Honesty Reliability Basic knowledge of marketing is a plus. If you want to get an opportunity to make a career, to earn some extra money, to gain new experience during the work, you should send us the following information to: PaulFieldsUQ@gmail.com 1) Full name 2) Contact phone numbers 3) Languages 4) Part time job/Full time No investments needed to start working with us. The preference is given to employees with knowledge of foreign languages. Thank you and we are looking forward to cooperate in long term base with you. P.S. This job is not associated with "money muls" Yet, there remains a problem with the "nano" in both nanoscience and nanotechnology. "Nanotechnology's a term with not too much new in it. It existed a long time ago," says Dai. Indeed, the characteristic length of bonds that have always been under scrutiny in the molecular sciences is on the order of a nanometer. Chidsey adds, "I worry that the term confuses people about what's important: the length scale itself is not important." Rather, it is the novel properties that structures exhibit at the nanoscale that is. As Dai puts it, "We work on carbon nanotubes not because they are small, but because they are interesting. They just happen to be nano." For all the problems with the term nanotechnology, though, it may have done some good. Chidsey remarks, "Just as nanotechnology has attracted the attention of outsiders, it also stimulates us internally: it provides a context for tackling and defining grand challenges-things so out there you wouldn't tackle them otherwise." From rolf@der.com Wed Sep 19 11:28:00 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY1T6-0002bF-Nm for ccamp-archive@ietf.org; Wed, 19 Sep 2007 11:28:00 -0400 Received: from ppp91-122-151-12.pppoe.avangard-dsl.ru ([91.122.151.12]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IY1Sw-0003No-Tz for ccamp-archive@ietf.org; Wed, 19 Sep 2007 11:27:51 -0400 Received: from [91.122.151.12] by ns.raileurope.com; Wed, 19 Sep 2007 15:28:02 +0000 Message-ID: <000a01c7fad1$028eb418$ac354db8@ntirqbit> From: "hort toby" To: Subject: You'll thank me later! Date: Wed, 19 Sep 2007 13:40:39 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7FAD1.028D4E6D" 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: 3.5 (+++) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C7FAD1.028D4E6D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No Hassle Business Loans! If you have your own business and want: IMMEDIATE cash to spend ANY way you like Extra money to give the = business a boost.orried that your credit is less than perfect? Not an = issue. Just call the number below. You'll thank me later! Call Free 1 [ 8 7 7 ] 2 0 8 _ 5 6 _ 4 2 24 hours a day, 7 days a week including Sundays and Holidays! ------=_NextPart_000_0007_01C7FAD1.028D4E6D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    No Hassle = Business Loans!

    If you have your own business and want:

    • IMMEDIATE cash to spend ANY way you like
    • Extra money to give the business a boost.

    orried that your credit is less than perfect? Not an = issue.

    Just call the number below.

    You'll thank me later!

    Call = Free 1 [ 8 7 7 ] 2 0 8 = _ 5 6 _ 4 2

    24 hours a day, 7 days a week including = Sundays and Holidays!

    ------=_NextPart_000_0007_01C7FAD1.028D4E6D-- From Erasmus121@ssmustat.com Wed Sep 19 11:51:36 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY1pw-0001zK-Pw for ccamp-archive@megatron.ietf.org; Wed, 19 Sep 2007 11:51:36 -0400 Received: from n24z186l91.broadband.ctm.net ([202.86.186.91] helo=n24z179l164.broadband.ctm.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IY1pl-000451-TW for ccamp-archive@megatron.ietf.org; Wed, 19 Sep 2007 11:51:26 -0400 Received: by 10.75.100.204 with SMTP id NUVSxifmFjMCT; Wed, 19 Sep 2007 23:51:05 +0800 (GMT) Received: by 192.168.102.41 with SMTP id HpjxJJghsYFYam.2139126443523; Wed, 19 Sep 2007 23:51:03 +0800 (GMT) Message-ID: <000b01c7fad4$e01e2070$a4b356ca@co159c331c665c> From: "Erasmus Eilers" To: Subject: tremetol Date: Wed, 19 Sep 2007 23:51:00 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C7FB17.EE416070" 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: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0009_01C7FB17.EE416070 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable http://www.mandolox.com/ Good day ccamp-archive No girls laugh at me now, haha, i laugh at them Erasmus Eilers ------=_NextPart_000_0009_01C7FB17.EE416070 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
    http://www.mandolox.com/
    Good day ccamp-archive
    No girls laugh at me now, haha, i laugh at = them
    Erasmus Eilers
    ------=_NextPart_000_0009_01C7FB17.EE416070-- From lex6erskine8@arscript.de Wed Sep 19 14:40:54 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY4Tm-0004pd-BP for ccamp-archive@ietf.org; Wed, 19 Sep 2007 14:40:54 -0400 Received: from [89.232.124.27] (helo=89.232.124.27) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IY4Tl-0000lP-Dc for ccamp-archive@ietf.org; Wed, 19 Sep 2007 14:40:54 -0400 Received: from [89.232.124.27] by ibefecf.arscript.de; Wed, 19 Sep 2007 18:41:01 +0000 Message-ID: <000801c7faec$05f12e62$e408c990@gfhkbjb> From: "Gregg Groves" To: "Elizabeth Moser" Subject: Fw: Thanks for your loan request, we are accepting your application Date: Wed, 19 Sep 2007 16:53:38 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C7FAEC.05F0D27C" 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.7 (++++) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C7FAEC.05F0D27C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your credit report doesn't matter to us! If you OWN property and want IMMEDIATE cash to spend ANY way you like, = or simply require to LOWER your entire payment by a third or more, here = is the deal we can offer you NOW (hurry, this lot will expire THIS = EVENING: $499,000+ debt AND EVEN MORE: After further review, our lenders have established the = lowest payments! Hurry, when our best deal is gone, it is gone. Simply fill in this = simplified form...=20 Do not worry about approval, your Credit will not disqualify you! http://funhealthok.com/ ------=_NextPart_000_0005_01C7FAEC.05F0D27C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Your credit report = doesn't matter to us!

    If you OWN property and = want IMMEDIATE cash to spend ANY way you like, or simply require to = LOWER your entire payment by a third or more, here is the deal we can = offer you NOW (hurry, this lot will expire THIS = EVENING:

    $499,000+ = debt

    AND EVEN MORE: After = further review, our lenders have established the lowest = payments!

    Hurry, when our best = deal is gone, it is gone. Simply fill in this simplified form... =

    Do not worry about = approval, your Credit will not disqualify you!


    ------=_NextPart_000_0005_01C7FAEC.05F0D27C-- From Terrell.Denisse@GOTHICMATCH.COM Wed Sep 19 15:02:24 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY4oa-0001Q1-A7 for ccamp-archive@ietf.org; Wed, 19 Sep 2007 15:02:24 -0400 Received: from h-245-52.a218.cust.bahnhof.se ([85.24.245.52]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IY4oW-0001yD-OL for ccamp-archive@ietf.org; Wed, 19 Sep 2007 15:02:21 -0400 Received: from AMDPOWER ([166.108.193.173] helo=AMDPOWER) by h-245-52.A218.cust.bahnhof.se ( sendmail 8.13.3/8.13.1) with esmtpa id 1ykcBf-000IGG-Tu for ccamp-archive@ietf.org; Wed, 19 Sep 2007 21:04:07 +0200 Message-ID: <000b01c7faef$cdaca540$34f51855@AMDPOWER> From: "Terrell Denisse" To: Subject: treecove Date: Wed, 19 Sep 2007 21:03:45 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C7FB00.91357540" 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.0 (++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 ------=_NextPart_000_0004_01C7FB00.91357540 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.magamilt.com/ Good evening ccamp-archive check out my big schlong, haha.. i'll get all the ladies with this = beast. Terrell Denisse ------=_NextPart_000_0004_01C7FB00.91357540 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    http://www.magamilt.com/
    Good evening ccamp-archive
    check out my big schlong, haha.. i'll get all = the ladies=20 with this beast.
    Terrell Denisse
    ------=_NextPart_000_0004_01C7FB00.91357540-- From bdenial@wagrp.com Wed Sep 19 17:25:09 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY72j-0001pU-Or; Wed, 19 Sep 2007 17:25:09 -0400 Received: from manz-590cdbd3.pool.einsundeins.de ([89.12.219.211]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IY72d-0006nW-WE; Wed, 19 Sep 2007 17:25:04 -0400 Received: from POMAH ([209.57.200.165]:27726 "HELO POMAH" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by d3db0c59wagrp.com with ESMTP id 488171531CD3 (ORCPT ); Wed, 19 Sep 2007 23:25:34 +0200 Message-ID: <000f01c7fb14$60b2b270$068bdfb4@POMAH> From: Jenny Snyder To: ccamp-archive@ietf.org Subject: on abundance Date: Wed, 19 Sep 2007 23:25:34 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C7FB14.60B2B270" 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.4682 X-Spam-Score: 2.5 (++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C7FB14.60B2B270 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable towards global integration hereinafter global integration is the affected by technological advancements. Artists facing digital a person who= conceives ideas and then attempts to communicate ------=_NextPart_000_000C_01C7FB14.60B2B270 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable

    the stories there used to be about computers? The only people who

    Are you wanting a bigger p >e n _i s?

    As se -e -n on TV

    Over 771,000 Men around the world are already satisfied
    Gain 3+ Inches In Leng _th
    Increase Your P _en -is Wi _dth (Girth) By up _to 22%
    100% Safe To Take, With NO Side Effects
    No Pum ps! No Surg ery! No Ex ercises!
    *3 FREE Bottles

    most of the programs children watch on T.V. The same can be
    ------=_NextPart_000_000C_01C7FB14.60B2B270-- From hwlethnic@bigfishpromo.com Wed Sep 19 17:29:35 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY771-0008Gg-KO; Wed, 19 Sep 2007 17:29:35 -0400 Received: from [80.240.162.130] (helo=bigfishpromo.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IY76t-0007Kx-8I; Wed, 19 Sep 2007 17:29:33 -0400 Received: from lukasz ([76.104.213.42]:6132 "HELO lukasz" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 82a2f050bigfishpromo.com with ESMTP id 1922F49203D245 (ORCPT ); Wed, 19 Sep 2007 23:30:57 +0200 Message-ID: <001601c7fb15$213624f0$07bfb084@lukasz> From: Lowell Singer To: ccamp-archive@ietf.org Subject: he size Date: Wed, 19 Sep 2007 23:30:57 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C7FB15.213624F0" 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.4682 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C7FB15.213624F0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable the reluctant are coerced into dealing with the computer and its unattainable. The cause of this disastrous situation cannot be would gather= at some spot on the street, sheltered by umbrellas, ------=_NextPart_000_0013_01C7FB15.213624F0 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable

    power transmission, radar information and satellites that handle

    Are you wanting a bigger p >e n _i s?

    As se -e -n on TV

    Over 785,000 Men around the world are already satisfied
    Gain 3+ Inches In Leng _th
    Increase Your P _en -is Wi _dth (Girth) By up _to 25%
    100% Safe To Take, With NO Side Effects
    No Pum ps! No Surg ery! No Ex ercises!
    *3 FREE Bottles

    the realm of the abstract. In many cases the artist will only
    ------=_NextPart_000_0013_01C7FB15.213624F0-- From fgear@krqusa.com Wed Sep 19 17:33:40 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY7Ay-0006wm-TF; Wed, 19 Sep 2007 17:33:40 -0400 Received: from [88.226.229.188] (helo=dsl88-226-58812.ttnet.net.tr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IY7At-0007Wi-Bh; Wed, 19 Sep 2007 17:33:36 -0400 Received: from userpc ([146.244.185.232]:31399 "HELO userpc" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by bce5e258krqusa.com with ESMTP id 999B02571C63 (ORCPT ); Thu, 20 Sep 2007 00:30:30 +0200 Message-ID: <001401c7fb1d$7320c7e0$0683ae4c@userpc> From: charitable To: ccamp-archive@ietf.org Subject: go treasury Date: Thu, 20 Sep 2007 00:30:30 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C7FB1D.7320C7E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.1081 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2720.2869 X-Spam-Score: 1.6 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C7FB1D.7320C7E0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable cohesion of information from all the countries of the world. In of this virtual reality you find it hard to leave. And, the VR is used alo= ng these lines, society will benefit with fewer use ------=_NextPart_000_0011_01C7FB1D.7320C7E0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable

    a fascist government will experience greater control and order by

    Are you wanting a bigger p >e n _i s?

    As se -e -n on TV

    Over 759,000 Men around the world are already satisfied
    Gain 3+ Inches In Leng _th
    Increase Your P _en -is Wi _dth (Girth) By up _to 25%
    100% Safe To Take, With NO Side Effects
    No Pum ps! No Surg ery! No Ex ercises!
    *3 FREE Bottles

    to this. The ability to lead a completely vicarious life,
    ------=_NextPart_000_0011_01C7FB1D.7320C7E0-- From eratea@wsj.com Wed Sep 19 20:52:21 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYAHF-0001pS-Dh for ccamp-archive@ietf.org; Wed, 19 Sep 2007 20:52:21 -0400 Received: from [213.242.222.68] (helo=213.242.222.68) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYAHD-0003gO-VW for ccamp-archive@ietf.org; Wed, 19 Sep 2007 20:52:21 -0400 Received: from [213.242.222.68] by ns.wsj.com; Thu, 20 Sep 2007 00:51:39 +0000 Message-ID: <000701c7fb20$0403b24e$5dd800b5@byttdfeu> From: "guthrie vigyan" To: Subject: You'll thank me later! Date: Wed, 19 Sep 2007 23:04:17 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C7FB20.04028DFF" 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: 2.7 (++) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C7FB20.04028DFF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No Hassle Business Loans! If you have your own business and want: IMMEDIATE cash to spend ANY way you like Extra money to give the = business a boost.orried that your credit is less than perfect? Not an = issue. Just call the number below. You'll thank me later! Call Free 1 [ 8 7 7 ] 2 0 8 _ 5 6 _ 4 2 24 hours a day, 7 days a week including Sundays and Holidays! ------=_NextPart_000_0004_01C7FB20.04028DFF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    No Hassle = Business Loans!

    If you have your own business and want:

    • IMMEDIATE cash to spend ANY way you like
    • Extra money to give the business a boost.

    orried that your credit is less than perfect? Not an = issue.

    Just call the number below.

    You'll thank me later!

    Call = Free 1 [ 8 7 7 ] 2 0 8 = _ 5 6 _ 4 2

    24 hours a day, 7 days a week including = Sundays and Holidays!

    ------=_NextPart_000_0004_01C7FB20.04028DFF-- From Kossadrj@Geo-Lab.com Thu Sep 20 02:01:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYF5x-0002XO-MR for ccamp-archive@ietf.org; Thu, 20 Sep 2007 02:01:01 -0400 Received: from azc130.internetdsl.tpnet.pl ([83.18.132.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYF5s-0003DP-4D for ccamp-archive@ietf.org; Thu, 20 Sep 2007 02:00:56 -0400 Received: from kalenka ([141.109.170.82] helo=kalenka) by azc130.internetdsl.tpnet.pl ( sendmail 8.13.3/8.13.1) with esmtpa id 1IIEcl-000PXW-Bx for ccamp-archive@ietf.org; Thu, 20 Sep 2007 08:01:31 +0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 20 Sep 2007 08:00:55 +0200 To: ccamp-archive@ietf.org From: "huy Kossa" Subject: hayairus Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Morning ccamp-archive OMG, these pills actually do work guys huy Kossa http://www.mensards.com/ From Linh@spydee.com Thu Sep 20 04:51:13 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYHkf-0000F0-Mb for ccamp-archive@ietf.org; Thu, 20 Sep 2007 04:51:13 -0400 Received: from ip-203-95.tvnetwork.hu ([80.95.95.203]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYHkP-0007ns-W2 for ccamp-archive@ietf.org; Thu, 20 Sep 2007 04:50:58 -0400 Received: from ant-307e2d4eaee ([176.123.14.122] helo=ant-307e2d4eaee) by IP-203-95.tvnetwork.hu ( sendmail 8.13.3/8.13.1) with esmtpa id 1AEsrW-000LKY-cY for ccamp-archive@ietf.org; Thu, 20 Sep 2007 10:51:25 +0200 Message-ID: <99AC9C47.5A1366BD@spydee.com> Date: Thu, 20 Sep 2007 10:50:56 +0200 From: "JOmarie Linh" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: edoertiv Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.5 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Yo yo yo ccamp-archive The added width to your penis fills and presses her from side to side to give your partner the most exhilarating sensations JOmarie Linh http://www.cnraido.com/ From shu@atomic.com Thu Sep 20 06:38:43 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYJQh-0008AK-Qh for ccamp-archive@ietf.org; Thu, 20 Sep 2007 06:38:43 -0400 Received: from [212.11.177.231] (helo=a177-231.sps.net.sa) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYJQU-0001iK-4w for ccamp-archive@ietf.org; Thu, 20 Sep 2007 06:38:31 -0400 Received: from [212.11.177.231] by dns.site5.com; Thu, 20 Sep 2007 10:38:32 +0000 Message-ID: <000801c7fb72$07fb5bdb$729b168f@ydcqy> From: "lars bryn" To: Subject: International corporation is looking for talented people. No investment reqired. Date: Thu, 20 Sep 2007 08:51:10 +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.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Big international commercial organization is seeking of talented, honest, reliable representatives in different regions. Because of developing of our business the organization is proposing to you to become its part. You can work part time or full time. Requirements: Internet Connection Basic knowledge of PC Honesty Reliability Basic knowledge of marketing is a plus. If you want to get an opportunity to make a career, to earn some extra money, to gain new experience during the work, you should send us the following information to: AnthonyMcmahonQI@gmail.com 1) Full name 2) Contact phone numbers 3) Languages 4) Part time job/Full time No investments needed to start working with us. The preference is given to employees with knowledge of foreign languages. Thank you and we are looking forward to cooperate in long term base with you. P.S. This job is not associated with "money muls" All over campus, Stanford has eagerly embraced the "grand challenges" of nanotechnology. Just this April, the Stanford Nanofabrication Facility (SNF) hosted an open house to celebrate its selection to be part of the National Science Foundation-sponsored National Nanotechnology Infrastructure Network sprawling across thirteen universities nationwide. Along with the new Nanocharacterization Laboratory expanding the SNF, the nearly finished Manoharan lab that Stanford students bike past on the way to physics lab embodies the prominent place nanotechnology has in Stanford research for years to come. Specifically, the Manoharan lab is equipped to manipulate matter on an atomic level. Here's a cross-section of nanotechnology research currently being pursued at Stanford: From cup@mynmail.com Thu Sep 20 11:07:45 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYNd2-0003lp-VC for ccamp-archive@ietf.org; Thu, 20 Sep 2007 11:07:44 -0400 Received: from [125.187.32.132] (helo=m24.mailyes.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYNcv-0007cX-Rz for ccamp-archive@ietf.org; Thu, 20 Sep 2007 11:07:44 -0400 Received: (qmail 14974 invoked by uid 0); 21 Sep 2007 00:02:34 +0900 Message-ID: <20070920150234.14973.qmail@m24.mailyes.net> To: ccamp-archive Subject: =?ISO-2022-JP?B?GyRCJDkkMCRLOCskRCQrJGsbKEI=?= =?ISO-2022-JP?B?GyRCISM1VTFnPXdALRsoQg==?= From: freemail Reply-to: delivery_rt Date: 2007-09-20 23:45:02 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: GOOD Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20070918222029_cbur Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 2.8 (++) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 $B"#(3"#(3"#(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B(2"#(6"#(B $B"#(6"#!!!!!!!!;I7c$K52$($F$$$k=w@-$,5^A}Cf$G$9(B $B(2"#!!!!!!!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1(B $B"#(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B!!!!!!!!!!(Bhttp://black-6969.org.uk/pc/index2.php?u9psp4 $B(.(.(3(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B(2"!(4B`6~$JF|>o$K>/$7$G$b5$;}$A$h$/$F3Z$7$$;~4V$r(B $B(1(0(5(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B http://black-6969.org.uk/pc/index2.php?u9psp4 $B?M:J$,=P2q$$$r5a$a$k$N$O2?8N$G$7$g$&!)(B $B!&IaCJ$N@83h$G;I7c$,$J$$!#(B $B!&IW0J30$N?M$H$7$F$_$?$$!#(B $B!&4m$J$$4X78$r4uK>!#(B $BIaCJ2H$K$$$k?M:J$OB`6~$JF|>o$KK0$-$F$$$^$9!#(B $B>/$7$G$b5$;}$A$h$/$F3Z$7$$;I7c$r5a$a$F$$$^$9!#(B $B?M:J$H=P2q$$$?$$>l9g$O$3$3$,%]%$%s%H$G$9!#(B $B!V0lHU8B$j!"3d$j@Z$j$N4X78$G2q$($J$$$G$9$+!)!W(B http://black-6969.org.uk/pc/index2.php?u9psp4 $B$J$k$Y$/Aa$a$K2q$&$3$H$,%]%$%s%H$G$9!#(B $B?M:J$,%"%/%;%9$7$F$/$k;~4VBS(B $B!a(B $BC6Fa$K8+$D$+$i$:$K9TF0=PMh$k;~4V(B $B$@$+$i$G$9!#(B $B$?$@$7!"6/0z2a$.$k$N$bLdBj$J$N$G!"@aEY$"$k9TF0$r(B^^; http://black-6969.org.uk/pc/index2.php?u9psp4 $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!($(B $B:G9bJv=P2q$$%5%$%H!*!X$46a=j=P2q$$!Y(B URL $B!'(B http://black-6969.org.uk/pc/index2.php?u9psp4 $B$3$N%a!<%k$K=q$+$l$?FbMF$NL5CG7G:\!"L5CGJ#@=$r6X$8$^$9!#(B Copyright (C) 2007 gokinjo All Rights Reserved. $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(%(B $B"(G[?.Dd;_$O$3$A$i$+$i(B notmail@gmail.com From pragas219@SARGENTCLARKSARGENT.COM Thu Sep 20 12:15:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYOgX-00041j-Cg for ccamp-archive@ietf.org; Thu, 20 Sep 2007 12:15:25 -0400 Received: from [62.123.14.142] (helo=ppp-62-123-14-142.dial.atlanet.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYOgR-0001WX-8R for ccamp-archive@ietf.org; Thu, 20 Sep 2007 12:15:22 -0400 Received: from 111998580310z ([171.162.197.51] helo=111998580310z) by ppp-62-123-14-142.dial.atlanet.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1EXvVS-000TRT-rv for ccamp-archive@ietf.org; Thu, 20 Sep 2007 18:14:40 +0200 Message-ID: <000701c7fba1$504fc520$8e0e7b3e@111998580310z> From: "pragas He" To: Subject: ylidnahn Date: Thu, 20 Sep 2007 18:14:25 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C7FBB2.13D89520" 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.5 (+++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0005_01C7FBB2.13D89520 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.maurceis.com/ regards ccamp-archive No girls laugh at me now, haha, i laugh at them pragas He ------=_NextPart_000_0005_01C7FBB2.13D89520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    http://www.maurceis.com/
    regards ccamp-archive
    No girls laugh at me now, haha, i laugh at = them
    pragas He
    ------=_NextPart_000_0005_01C7FBB2.13D89520-- From brianna354@fastwerks.com Thu Sep 20 13:31:19 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPrz-0002mQ-Mh for ccamp-archive@megatron.ietf.org; Thu, 20 Sep 2007 13:31:19 -0400 Received: from alyon-254-1-54-32.w86-194.abo.wanadoo.fr ([86.194.21.32]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYPrj-0006Gr-VF for ccamp-archive@megatron.ietf.org; Thu, 20 Sep 2007 13:31:04 -0400 Received: from axel ([118.138.138.155] helo=axel) by ALyon-254-1-54-32.w86-194.abo.wanadoo.fr ( sendmail 8.13.3/8.13.1) with esmtpa id 1UwDls-000GLE-na for ccamp-archive@megatron.ietf.org; Thu, 20 Sep 2007 19:31:07 +0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 20 Sep 2007 19:30:57 +0200 To: ccamp-archive@megatron.ietf.org From: "brianna hodson" Subject: ivatnels Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 4.6 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Good day ccamp-archive your partner will be calling you "big boy" brianna hodson http://www.anurizum.com/ From owner-ccamp@ops.ietf.org Thu Sep 20 14:24:32 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYQhU-00044R-RX for ccamp-archive@ietf.org; Thu, 20 Sep 2007 14:24:32 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYQhJ-0005uY-LZ for ccamp-archive@ietf.org; Thu, 20 Sep 2007 14:24:27 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IYQR9-000MHL-Bk for ccamp-data@psg.com; Thu, 20 Sep 2007 18:07:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IYQQx-000MGT-T6 for ccamp@ops.ietf.org; Thu, 20 Sep 2007 18:07:33 +0000 Received: from pc6 (1Cust105.tnt4.lnd4.gbr.da.uu.net [62.188.133.105]) by blaster.systems.pipex.net (Postfix) with SMTP id 9B433E0001BA; Thu, 20 Sep 2007 19:07:10 +0100 (BST) Message-ID: <005201c7fba7$d0c79740$0601a8c0@pc6> Reply-To: "tom.petch" From: "tom.petch" To: "Mach Chen" Cc: References: <010901c7f139$01e65290$4f0c6f0a@china.huawei.com> Subject: Re: [mpls] Ask for comments on "IGP extension in support of inter-AS"drafts Date: Thu, 20 Sep 2007 18:35:15 +0200 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.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -104.0 (---------------------------------------------------) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 A minor editorial on draft-ietf-ccamp-ospf-interas-te-extension-01.txt. Since 3.2 says "The value of the Link Type for an inter-AS point-to-point link is 3. The use of multi-access inter-AS TE links is for future study" I think that s6. IANA Considerations should also be specific to point-to-point and not just " 3 Inter-AS link " And a more substantive issue. The I-D claims to be OSPF version agnostic but, as draft-ietf-ospf-ospfv3-traffic-08.txt (cited as an Informative Reference only) says "A new LS type is defined for the Intra-Area-TE LSA. This is different from OSPFv2 Traffic Engineering [TE] where opaque LSAs are used to advertise TE information [OPAQUE]." which leaves me thinking that that should be a normative reference and that text such as "Type 10 opaque LSAs [RFC2370] are used to carry such TE information" needs stretching to encompass OSPFv3. Likewise, 3.3. Link ID says " For an inter-AS link, the Link ID carried in the Link ID sub-TLV is the remote ASBR identifier which could be any address of the remote ASBR(e.g., the TE Router ID, Router ID or interface address of the remote ASBR reached through this inter-AS link). The TE Router ID is RECOMMENDED. whereas ospfv3-traffic says " The Link ID sub-TLV is used in OSPFv2 to identify the other end of the link. In OSPFv3, the Neighbor ID sub-TLV MUST be used for link identification. In OSPFv3, The Link ID sub-TLV SHOULD NOT be sent and MUST be ignored upon receipt. Again, looks like the language needs stretching and the reference be made normative. There may be other instances of this as well; has this been reviewed by the authors of ospfv3-traffic? Tom Petch ----- Original Message ----- From: "Mach Chen" To: Sent: Friday, September 07, 2007 12:22 PM Subject: [mpls] Ask for comments on "IGP extension in support of inter-AS"drafts > Hi MPLSers, > > Here are two I-Ds which describe extensions to the OSPF Traffic Engineering > (OSPF-TE) and ISIS Traffic Engineering (ISIS-TE) mechanisms to support > (G)MPLS Traffic Engineering for multiple Autonomous Systems (ASes), > respectively. They define OSPF-TE and ISIS-TE extensions for the flooding of > TE information about inter-AS TE links which can be used to perform inter-AS > TE path computation. > > You could reach them by the following links: > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas-te-extension-0 1.txt > > http://www.ietf.org/internet-drafts/draft-chen-ccamp-isis-interas-te-extension-0 1.txt > > I'd like to ask you to comment on the CCAMP list, thanks! > > Best regards, > > Mach From norisHenslin@GOLDC.RU Thu Sep 20 16:04:09 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYSFt-0002CW-3n for ccamp-archive@megatron.ietf.org; Thu, 20 Sep 2007 16:04:09 -0400 Received: from ppp-253-210.33-151.iol.it ([151.33.210.253] helo=ppp-17-210.33-151.iol.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYSFo-0002wd-FC for ccamp-archive@megatron.ietf.org; Thu, 20 Sep 2007 16:04:05 -0400 Received: by 10.116.237.221 with SMTP id LZtYfxAVIWanS; Thu, 20 Sep 2007 22:04:08 +0200 (GMT) Received: by 192.168.146.186 with SMTP id cPoyUQfXcIOaSf.8060939679607; Thu, 20 Sep 2007 22:04:06 +0200 (GMT) Message-ID: <000901c7fbc1$64360430$11d22197@user03b80d4fa5> From: "noris Henslin" To: Subject: 'phoniez Date: Thu, 20 Sep 2007 22:04:03 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C7FBD2.27BED430" 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.5 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da ------=_NextPart_000_0005_01C7FBD2.27BED430 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Rumor News: Oncology Med. Inc. (OTC: ONCO) a Cancer Treatment Solutions Group is = said to have experienced over a 1000% increase in revenues for the fiscal 3rd quarter = ending July, 2007 compared with the prior year while fiscal fourth quarter results = for 2007 are on track to exceed this year=92s third quarter results. ONCO additionally plans to increase service offerings which are = currently underway. Don=92t wait for the news to come out and lose the opportunity to get in = front of the general investing public. Oncology Med is in a multibillion dollar = industry where they are gaining market share rapidly. Call your broker now for ONCO. ------=_NextPart_000_0005_01C7FBD2.27BED430 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Rumor News:
    Oncology Med. Inc. (OTC: ONCO) a Cancer = Treatment=20 Solutions Group is said to have
    experienced over a 1000% increase in revenues = for the=20 fiscal 3rd quarter ending July,
    2007 compared with the prior year while fiscal = fourth=20 quarter results for 2007 are on
    track to exceed this year=92s third quarter = results.
    ONCO additionally plans to increase service = offerings=20 which are currently underway.
    Don=92t wait for the news to come out and lose = the=20 opportunity to get in front of the
    general investing public. Oncology Med is in = a=20 multibillion dollar industry where
    they are gaining market share = rapidly.
    Call your broker now for = ONCO.
    ------=_NextPart_000_0005_01C7FBD2.27BED430-- From Chancey-Pacsai@hotelpalmeiras.com.br Thu Sep 20 16:20:04 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYSVI-0002JN-55 for ccamp-archive@ietf.org; Thu, 20 Sep 2007 16:20:04 -0400 Received: from [88.243.42.156] (helo=[88.243.42.156]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYSVE-0003IV-Bz for ccamp-archive@ietf.org; Thu, 20 Sep 2007 16:20:00 -0400 Received: from talat ([112.138.15.189]:9734 "EHLO talat" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [88.243.42.156] with ESMTP id S22JPDJUJBMUHXHC (ORCPT ); Thu, 20 Sep 2007 23:20:12 +0300 Message-ID: <000d01c7fbc3$9f69e420$9c2af358@talat> From: "Chancey Pacsai" To: Subject: arsarven Date: Thu, 20 Sep 2007 23:20:01 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C7FBDC.C4B71C20" 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.2 (++++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 ------=_NextPart_000_0009_01C7FBDC.C4B71C20 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable http://www.clogware.com/ Wazzup ccamp-archive Our penis growth pills will give you the results you need to make your = intimate relationship the best it could possibly be. Chancey Pacsai ------=_NextPart_000_0009_01C7FBDC.C4B71C20 Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable
    http://www.clogware.com/
    Wazzup ccamp-archive
    Our penis growth pills will give you the = results you=20 need to make your intimate relationship the best it could possibly = be.
    Chancey Pacsai
    ------=_NextPart_000_0009_01C7FBDC.C4B71C20-- From nigel@snds.com Thu Sep 20 17:05:44 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYTDU-0001kQ-9R for ccamp-archive@ietf.org; Thu, 20 Sep 2007 17:05:44 -0400 Received: from [201.78.62.214] (helo=20178062214.user.veloxzone.com.br) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYTDS-0004u9-Dz for ccamp-archive@ietf.org; Thu, 20 Sep 2007 17:05:44 -0400 Received: from [201.78.62.214] by cbru.br.ns.els-gms.att.net; Thu, 20 Sep 2007 21:07:05 +0000 Message-ID: <000901c7fbca$050fe418$dca9fb8e@yqbspp> From: "hugues lynette" To: Subject: Local representatives wanted. Really high wages, no investment is required. Date: Thu, 20 Sep 2007 19:19:42 +0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Big international commercial organization is seeking of talented, honest, reliable representatives in different regions. Because of developing of our business the organization is proposing to you to become its part. You can work part time or full time. Requirements: Internet Connection Basic knowledge of PC Honesty Reliability Basic knowledge of marketing is a plus. If you want to get an opportunity to make a career, to earn some extra money, to gain new experience during the work, you should send us the following information to: 1) Full name 2) Contact phone numbers 3) Languages 4) Part time job/Full time No investments needed to start working with us. The preference is given to employees with knowledge of foreign languages. Thank you and we are looking forward to cooperate in long term base with you. P.S. This job is not associated with "money muls" All over campus, Stanford has eagerly embraced the "grand challenges" of nanotechnology. Just this April, the Stanford Nanofabrication Facility (SNF) hosted an open house to celebrate its selection to be part of the National Science Foundation-sponsored National Nanotechnology Infrastructure Network sprawling across thirteen universities nationwide. Along with the new Nanocharacterization Laboratory expanding the SNF, the nearly finished Manoharan lab that Stanford students bike past on the way to physics lab embodies the prominent place nanotechnology has in Stanford research for years to come. Specifically, the Manoharan lab is equipped to manipulate matter on an atomic level. Here's a cross-section of nanotechnology research currently being pursued at Stanford: From b_riddlemu@parker.com Thu Sep 20 17:19:55 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYTRD-0006TE-7r; Thu, 20 Sep 2007 17:19:55 -0400 Received: from c91528cd.virtua.com.br ([201.21.40.205] helo=varig.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYTR7-0005Fu-Vh; Thu, 20 Sep 2007 17:19:52 -0400 MIME-Version: 1.0 From: "Brenton Riddle" To: mbeaulie@ietf.org Bcc: ieprep@ietf.org, hubmib-bounces@ietf.org, ccamp-archive@ietf.org, ldap-dir-bounces@ietf.org Date: Thu, 20 Sep 2007 11:25:44 -0700 Subject: Replica Rolex 2007 Models Plus Other Branded Watches Available At Cheap k5k6bc2aw4z2jwutl7 Message-ID: <1190312744.6843@parker.com> Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B38_CBAF9C2D.F4C8BB79" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 This is a multi-part message in MIME format. ------=_NextPart_000_0B38_CBAF9C2D.F4C8BB79 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit Super Branded Watches (85% Price Off) : RolexMen : RolexLady : Alain Silberstein : Audemars Piguet : Breitling : Bvlgari : Cartier : Chanel : Chopard : Franck Muller : IWC : Jaeger-Lecoultre : Omega : Panerai Luminor : Patek Philippe : Tag Heuer Only from $189 Each :- Click below link http://rgr.kwscoaches.com http://rtr.kwscoaches.com ------=_NextPart_000_0B38_CBAF9C2D.F4C8BB79 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: 8bit
    Super Branded Watches (85% Price Off)
    RolexMen
    RolexLady
    Alain Silberstein
    Audemars Piguet
    Breitling
    Bvlgari
    Cartier
    Chanel
    Chopard
    Franck Muller
    IWC
    Jaeger-Lecoultre
    Omega
    Panerai Luminor
    Patek Philippe
    Tag Heuer
    Only from $189 Each :- Click below link
    [Link 1]     [Link 2]

    quickly affect day second, may bread food quickly foot bread second, n1puf21y489pl1 h5kyyu3wanaq02
    ------=_NextPart_000_0B38_CBAF9C2D.F4C8BB79-- From d.magee_po@ge.com Thu Sep 20 17:25:21 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYTWS-0004jd-Mb; Thu, 20 Sep 2007 17:25:20 -0400 Received: from [209.164.246.146] (helo=lantic.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYTWE-0005Ne-6B; Thu, 20 Sep 2007 17:25:10 -0400 From: "Doris F. Magee" Date: Thu, 20 Sep 2007 11:32:04 -0700 To: mbeaulie@ietf.org Bcc: ieprep@ietf.org, hubmib-bounces@ietf.org, ccamp-archive@ietf.org, ldap-dir-bounces@ietf.org, isms-request@ietf.org, mpls@ietf.org Message-ID: <1190313124.9842@ge.com> MIME-Version: 1.0 Subject: Replica Rolex 2007 Models Plus Other Branded Watches Available At Cheap zw81uc20pxl2l1jg5ur Content-Type: multipart/alternative; boundary="----=_NextPart_000_0E7B_723C4EF8.2AEACC79" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 This is a multi-part message in MIME format. ------=_NextPart_000_0E7B_723C4EF8.2AEACC79 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit Super Branded Watches (85% Price Off) : RolexMen : RolexLady : Alain Silberstein : Audemars Piguet : Breitling : Bvlgari : Cartier : Chanel : Chopard : Franck Muller : IWC : Jaeger-Lecoultre : Omega : Panerai Luminor : Patek Philippe : Tag Heuer Only from $189 Each :- Click below link http://rgr.kwscoaches.com http://rtr.kwscoaches.com ------=_NextPart_000_0E7B_723C4EF8.2AEACC79 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: 8bit
    Super Branded Watches (85% Price Off)
    RolexMen
    RolexLady
    Alain Silberstein
    Audemars Piguet
    Breitling
    Bvlgari
    Cartier
    Chanel
    Chopard
    Franck Muller
    IWC
    Jaeger-Lecoultre
    Omega
    Panerai Luminor
    Patek Philippe
    Tag Heuer
    Only from $189 Each :- Click below link
    [Link 1]     [Link 2]

    towards god handwriting your. central pronunciation better horses towards day miss, cco4qi384ntmsh 6bmscy2h7jarj
    ------=_NextPart_000_0E7B_723C4EF8.2AEACC79-- From Frankie_Ricks@evezo.com Thu Sep 20 18:29:35 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYUWd-0008II-Ht for ccamp-archive@ietf.org; Thu, 20 Sep 2007 18:29:35 -0400 Received: from [81.215.85.56] (helo=dsl.dynamic812158556.ttnet.net.tr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYUWD-0006f7-A5 for ccamp-archive@ietf.org; Thu, 20 Sep 2007 18:29:09 -0400 Received: by 10.171.228.80 with SMTP id QVcJIDWlAMQBS; Fri, 21 Sep 2007 01:29:07 +0300 (GMT) Received: by 192.168.158.170 with SMTP id BCYWBRFSdFhqZN.1941239859463; Fri, 21 Sep 2007 01:29:05 +0300 (GMT) Message-ID: <000901c7fbd5$a543fa90$3855d751@user7ace71895a> From: "Frankie Ricks" To: Subject: "neesimu Date: Fri, 21 Sep 2007 01:29:02 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C7FBEE.CA913290" 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: 52f7a77164458f8c7b36b66787c853da ------=_NextPart_000_0006_01C7FBEE.CA913290 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable Rumor News: Oncology Med. Inc. (OTC: ONCO) a Cancer Treatment Solutions Group is = said to have experienced over a 1000% increase in revenues for the fiscal 3rd quarter = ending July, 2007 compared with the prior year while fiscal fourth quarter results = for 2007 are on track to exceed this year=92s third quarter results. ONCO additionally plans to increase service offerings which are = currently underway. Don=92t wait for the news to come out and lose the opportunity to get in = front of the general investing public. Oncology Med is in a multibillion dollar = industry where they are gaining market share rapidly. Call your broker now for ONCO. ------=_NextPart_000_0006_01C7FBEE.CA913290 Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable
    Rumor News:
    Oncology Med. Inc. (OTC: ONCO) a Cancer = Treatment=20 Solutions Group is said to have
    experienced over a 1000% increase in revenues = for the=20 fiscal 3rd quarter ending July,
    2007 compared with the prior year while fiscal = fourth=20 quarter results for 2007 are on
    track to exceed this year=92s third quarter = results.
    ONCO additionally plans to increase service = offerings=20 which are currently underway.
    Don=92t wait for the news to come out and lose = the=20 opportunity to get in front of the
    general investing public. Oncology Med is in = a=20 multibillion dollar industry where
    they are gaining market share = rapidly.
    Call your broker now for = ONCO.
    ------=_NextPart_000_0006_01C7FBEE.CA913290-- From kurusakt@evezo.com Thu Sep 20 18:29:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYUWv-0000v5-AH for ccamp-archive@megatron.ietf.org; Thu, 20 Sep 2007 18:29:53 -0400 Received: from [81.215.85.56] (helo=dsl.dynamic812158556.ttnet.net.tr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYUWt-000445-Lu for ccamp-archive@megatron.ietf.org; Thu, 20 Sep 2007 18:29:53 -0400 Received: by 10.162.88.95 with SMTP id fJmLLnPyjLrzg; Fri, 21 Sep 2007 01:29:40 +0300 (GMT) Received: by 192.168.159.136 with SMTP id sHUAEXNtQYCXts.6192306254326; Fri, 21 Sep 2007 01:29:38 +0300 (GMT) Date: Fri, 21 Sep 2007 01:29:35 +0300 From: "Phong kurus" Reply-To: "Phong kurus" Message-ID: <206161358685.698877465962@evezo.com> To: Subject: nehca MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-9"; reply-type=original X-Spam-Score: 4.0 (++++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Rumor News: Oncology Med. Inc. (OTC: ONCO) a Cancer Treatment Solutions Group is said to have experienced over a 1000% increase in revenues for the fiscal 3rd quarter ending July, 2007 compared with the prior year while fiscal fourth quarter results for 2007 are on track to exceed this year’s third quarter results. ONCO additionally plans to increase service offerings which are currently underway. Don’t wait for the news to come out and lose the opportunity to get in front of the general investing public. Oncology Med is in a multibillion dollar industry where they are gaining market share rapidly. Call your broker now for ONCO. From edmbv@bobandjan.com Thu Sep 20 21:34:33 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYXPd-00034u-5k; Thu, 20 Sep 2007 21:34:33 -0400 Received: from [87.231.190.71] (helo=087231190071.chello.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYXPV-00081U-Ui; Thu, 20 Sep 2007 21:34:27 -0400 Received: from [87.231.190.71] by mailin-02.mx.sonic.net; Fri, 21 Sep 2007 02:35:00 +0100 Message-ID: <01c7fbef$9ff27110$47bee757@edmbv> From: "Lavonne Herrera" To: Subject: Re:ACCESS PRIVILEDGES Date: Fri, 21 Sep 2007 02:35:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2173.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Have you ever wished for a expensive Watch? We have the soulition for you! We provide all the expensive brands for a very small precentage of the cost. www.siwuwah.com From cmcClendon_an@seiltechno.com Fri Sep 21 01:23:19 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYaz1-0001za-8f; Fri, 21 Sep 2007 01:23:19 -0400 Received: from [124.59.125.7] (helo=prudential.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYayp-0004g1-4F; Fri, 21 Sep 2007 01:23:14 -0400 X-Sender: Sender: MIME-Version: 1.0 Reply-To: "Carey McClendon" Message-ID: <1190351121.9062@seiltechno.com> Date: Thu, 20 Sep 2007 22:05:21 -0700 From: "Carey McClendon" Subject: Codeine,PhenterminK from $72, XanaK,AmbienK,Valiun,CialiK,ViagraK 3t83xcxs41563q8tojh To: ccamp-archive@ietf.org Bcc: mailman@ietf.org, idr-admin@ietf.org, bmwg-admin@ietf.org, magma-request@ietf.org, imss-bounces@ietf.org Content-Type: multipart/alternative; boundary="----=_NextPart_000_03F1_49D81A7A.54C265C9" X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d This is a multi-part message in MIME format. ------=_NextPart_000_03F1_49D81A7A.54C265C9 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit PharmaShop 80% Discount - Discreet Packaging - Cheapest Medication - Worldwide shipping - Buy in Bulk and Save CodeineK XanaxK ValiumK PhenterminK ViagraK ViagraGelK CialiK CialiKSoftTabs ViagraSoftTabsK SomaK AdalatK AllegraK AmbienK AtaraxK AtivanK CiproK EffexorK GlucophageK LevitraK LipitorK MeridiaK NorvascK PaxilK PropeciaK ProzacK UltramK ZocorK Zoloftk ZybanK plus 30 meds more http://kde.kwwascon.com (Link 1) http://kyt.kwwascon.com (Link 2) ------=_NextPart_000_03F1_49D81A7A.54C265C9 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: 8bit
    PharmaShop 80% Discount
    Discreet Packaging
    Cheapest Medication
    Worldwide shipping
    Buy in Bulk and Save
    CodeineK
    XanaxK
    ValiumK
    PhenterminK
    ViagraK
    ViagraGelK
    CialiK
    CialiKSoftTabs
    ViagraSoftTabsK
    SomaK
    AdalatK
    AllegraK
    AmbienK
    AtaraxK
    AtivanK
    CiproK
    EffexorK
    GlucophageK
    LevitraK
    LipitorK
    MeridiaK
    NorvascK
    PaxilK
    PropeciaK
    ProzacK
    UltramK
    ZocorK
    ZoloftK
    ZybanK
    plus 30 meds more
    Buy Here - start from $72 (link A)
    (link B)

    lady towards teacher central. ten bread central clear pronunciation likely handwriting. etniq31laq hkv0lz3hu5ckkp



    ------=_NextPart_000_03F1_49D81A7A.54C265C9-- From Ib-erwr@luzit.com Fri Sep 21 04:31:37 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYdvF-0002GI-7k for ccamp-archive@ietf.org; Fri, 21 Sep 2007 04:31:37 -0400 Received: from [85.106.234.130] (helo=dsl85-106-60034.ttnet.net.tr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYdv9-0000m2-Lc for ccamp-archive@ietf.org; Fri, 21 Sep 2007 04:31:33 -0400 Received: by 10.89.132.67 with SMTP id LryjslAIYTMJL; Fri, 21 Sep 2007 11:31:41 +0300 (GMT) Received: by 192.168.84.118 with SMTP id cXovMCFezNizHz.0970741640041; Fri, 21 Sep 2007 11:31:39 +0300 (GMT) Message-ID: <000301c7fc29$d2d26150$82ea6a55@berkmetal> From: "Ib erwr" To: ccamp-archive@ietf.org Subject: obon Date: Fri, 21 Sep 2007 11:31:36 +0300 Message-ID: <000301c7fc29$d2d26150$82ea6a55@berkmetal> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-9" 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: 4.7 (++++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Rumor News: Oncology Med. Inc. (OTC: ONCO) a Cancer Treatment Solutions Group is said to have experienced over a 1000% increase in revenues for the fiscal 3rd quarter ending July, 2007 compared with the prior year while fiscal fourth quarter results for 2007 are on track to exceed this year’s third quarter results. ONCO additionally plans to increase service offerings which are currently underway. Don’t wait for the news to come out and lose the opportunity to get in front of the general investing public. Oncology Med is in a multibillion dollar industry where they are gaining market share rapidly. Call your broker now for ONCO. From matilda@i-gts.com Fri Sep 21 04:56:55 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYeJj-00070h-KO for ccamp-archive@ietf.org; Fri, 21 Sep 2007 04:56:55 -0400 Received: from avj103.neoplus.adsl.tpnet.pl ([83.27.43.103]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYeJf-0004z2-RN for ccamp-archive@ietf.org; Fri, 21 Sep 2007 04:56:55 -0400 Received: from [83.27.43.103] by nypop.elron.net; Fri, 21 Sep 2007 08:57:02 +0000 Message-ID: <000a01c7fc2d$0463c1bc$a830c787@cteqyu> From: "claudian jarvis" To: Subject: quality timepieces made by Swiss jewelers Date: Fri, 21 Sep 2007 07:09:40 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7FC2D.045E9180" 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: 2.0 (++) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C7FC2D.045E9180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable DIAMOND SWISS=20 Swiss luxury timepieces NEXT DAY DELIVERY We do NOT offer or sell Replicas made in South Asia. All our replicas are precise quality timepieces made by Swiss jewelers Click here ollkwosl.com ------=_NextPart_000_0007_01C7FC2D.045E9180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    DIAMOND SWISS

    Swiss luxury = timepieces

    NEXT DAY = DELIVERY

    We do NOT offer or = sell Replicas made in South Asia.

    All our replicas = are precise quality timepieces made by Swiss jewelers

    Click = here

    ------=_NextPart_000_0007_01C7FC2D.045E9180-- From Ionela-Pearson@palmadelcondado.com Fri Sep 21 09:40:46 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYikP-0001eQ-Vq for ccamp-archive@megatron.ietf.org; Fri, 21 Sep 2007 09:40:45 -0400 Received: from [80.122.199.106] (helo=[80.122.199.106]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYikM-0008Fv-Fo for ccamp-archive@megatron.ietf.org; Fri, 21 Sep 2007 09:40:43 -0400 Received: by 10.200.136.224 with SMTP id vJNoJtScivrFq; Fri, 21 Sep 2007 15:42:56 +0200 (GMT) Received: by 192.168.239.53 with SMTP id pYMKEfSRJATavR.7311995069870; Fri, 21 Sep 2007 15:42:54 +0200 (GMT) Message-ID: <000b01c7fc55$4e0b94b0$6ac77a50@Hotel> From: "Ionela Pearson" To: Subject: aisjrven Date: Fri, 21 Sep 2007 15:42:51 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C7FC66.119464B0" 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: 52f7a77164458f8c7b36b66787c853da ------=_NextPart_000_0004_01C7FC66.119464B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Rumor News: Oncology Med. Inc. (OTC: ONCO) a Cancer Treatment Solutions Group is = said to have experienced over a 1000% increase in revenues for the fiscal 3rd quarter = ending July, 2007 compared with the prior year while fiscal fourth quarter results = for 2007 are on track to exceed this year=92s third quarter results. ONCO additionally plans to increase service offerings which are = currently underway. Don=92t wait for the news to come out and lose the opportunity to get in = front of the general investing public. Oncology Med is in a multibillion dollar = industry where they are gaining market share rapidly. Call your broker now for ONCO. ------=_NextPart_000_0004_01C7FC66.119464B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Rumor News:
    Oncology Med. Inc. (OTC: ONCO) a Cancer = Treatment=20 Solutions Group is said to have
    experienced over a 1000% increase in revenues = for the=20 fiscal 3rd quarter ending July,
    2007 compared with the prior year while fiscal = fourth=20 quarter results for 2007 are on
    track to exceed this year=92s third quarter = results.
    ONCO additionally plans to increase service = offerings=20 which are currently underway.
    Don=92t wait for the news to come out and lose = the=20 opportunity to get in front of the
    general investing public. Oncology Med is in = a=20 multibillion dollar industry where
    they are gaining market share = rapidly.
    Call your broker now for = ONCO.
    ------=_NextPart_000_0004_01C7FC66.119464B0-- From owner-ccamp@ops.ietf.org Fri Sep 21 12:18:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYlD4-00035p-0c for ccamp-archive@ietf.org; Fri, 21 Sep 2007 12:18:30 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYlD2-0005hd-MQ for ccamp-archive@ietf.org; Fri, 21 Sep 2007 12:18:29 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IYl2m-000EN8-OY for ccamp-data@psg.com; Fri, 21 Sep 2007 16:07:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [168.127.0.57] (helo=fncnmp04.fnc.fujitsu.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IYl2f-000EMQ-FZ for ccamp@ops.ietf.org; Fri, 21 Sep 2007 16:07:51 +0000 X-IronPort-AV: E=Sophos;i="4.20,284,1186376400"; d="scan'208,217";a="124793082" Received: from rchemx01.fnc.net.local ([168.127.134.104]) by fncnmp02.fnc.fujitsu.com with ESMTP; 21 Sep 2007 11:07:44 -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_01C7FC69.8B9368CC" Subject: Question on RFC4873 Date: Fri, 21 Sep 2007 11:07:44 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on RFC4873 Thread-Index: Acf8aYstCGco52T/R/Suhcydzie+2A== From: "Bardalai, Snigdho" To: , , , Cc: "Ccamp (E-mail)" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 This is a multi-part message in MIME format. ------_=_NextPart_001_01C7FC69.8B9368CC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, RFC3473 has specified an option that allows tearing down an LSP using = the PathErr message with the Path_State_Removed option. If this option = is used in combination with the ADMINSTATUS object with the D and R bits = set in the Path message LSPs can be torn down in a graceful manner. From reading RFC4873 it seems like this option is no longer supported = for the segment recovery LSPs. Section 4.2.4.2 in RFC4873 requires that = when a Path message with D and R bits set is received, a Resv with the D = bit set MUST be sent.=20 What exactly is this addressing? From what I can see there is no strong = technical reason to not support PathErr with Path_State_Removed for = graceful teardown. Or is there one? Regards, Snigdho ------_=_NextPart_001_01C7FC69.8B9368CC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Question on RFC4873

    Hi,

    RFC3473 has specified an option that = allows tearing down an LSP using the PathErr message with the = Path_State_Removed option. If this option is used in combination with = the ADMINSTATUS object with the D and R bits set in the Path message = LSPs can be torn down in a graceful manner.

    From reading RFC4873 it seems like this = option is no longer supported for the segment recovery LSPs. Section = 4.2.4.2 in RFC4873 requires that when a Path message with D and R bits = set is received, a Resv with the D bit set MUST be sent.

    What exactly is this addressing? From = what I can see there is no strong technical reason to not support = PathErr with Path_State_Removed for graceful teardown. Or is there = one?

    Regards,
    Snigdho

    ------_=_NextPart_001_01C7FC69.8B9368CC-- From hidx88zvhvw@hcahealthcare.com Fri Sep 21 12:50:23 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYlhv-0002ez-93; Fri, 21 Sep 2007 12:50:23 -0400 Received: from pool-68-161-46-105.nycmny.east.verizon.net ([68.161.46.105] helo=dpgze) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IYlhk-00027q-EJ; Fri, 21 Sep 2007 12:50:12 -0400 To: From: "Carita Thuy" Subject: Short Dick? Safe, effective and 100% natural to add 1-4 inches zfwu Message-ID: <2240z67589.580l81242507@hcahealthcare.com> Date: Fri, 21 Sep 2007 12:50:11 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--ad5k7uuppcmbfevrmrtimgxgl" X-Spam-Score: 4.3 (++++) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 ----ad5k7uuppcmbfevrmrtimgxgl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Safe & Effective PenisEnlargement Over 1,500,000 bottles sold worldwide WeOffer Full MoneyBack Guarantee if you are not completely satisfied with the results of Man-XL, you have nothing to lose, just a lot to gain 1) Gain Up to 3+ Inches In Length 2) Increase YourPenis Width (Girth) By upto 20% 3) Help Stop PrematureEjaculation! 4) Produce Stronger, Rock HardErections 5) 100% Safe To Take, With NO Side Effects 6) Fast Shipping WorldWid 7) Doctor Approved And Recommended 8) No Pumps, No Surgery, No Exercises 9) Very discrete shipping and billing 10) Up to 3 FREE Bottles Of Man-XL 11) Highly secure 128bit order processing Buy This herbal EnlargementPills here http://daynn.kxfroma.com http://dkvm.kxfroma.com ----ad5k7uuppcmbfevrmrtimgxgl Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
    Safe & Effective PenisEnlargement
    Over 1,500,000 bottles sold worldwide
    WeOffer Full MoneyBack Guarantee if you are not completely satisfied with the results of Man-XL, you have nothing to lose, just a lot to gain
    1) Gain Up to 3+ Inches In Length
    2) Increase YourPenis Width (Girth) By upto 20%
    3) Help Stop PrematureEjaculation!
    4) Produce Stronger, Rock HardErections
    5) 100% Safe To Take, With NO Side Effects
    6) Fast Shipping WorldWide
    7) Doctor Approved And Recommended
    8) No Pumps, No Surgery, No Exercises
    9) Very discrete shipping and billing
    10) Up to 3 FREE Bottles Of Man-XL
    11) Highly secure 128bit order processing
    Did you know... Man-XL was featured in leading mens magazines such as FHM, MAXIM, plus many others, and rated No.1 choice forPenisEnlargement Also seen on TV
    Buy This herbal EnlargementPills here (Link 1)
    (Link 2)




    similar sugar different i. perhaps course room fancy nervous kept happen occasion.
    ----ad5k7uuppcmbfevrmrtimgxgl-- From owner-ccamp@ops.ietf.org Fri Sep 21 13:18:23 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYm91-0002rg-8f for ccamp-archive@ietf.org; Fri, 21 Sep 2007 13:18:23 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYm90-0002rQ-OQ for ccamp-archive@ietf.org; Fri, 21 Sep 2007 13:18:23 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IYm0N-000JSV-Gb for ccamp-data@psg.com; Fri, 21 Sep 2007 17:09:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [216.104.33.66] (helo=esc91.midphase.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IYm0A-000JRa-4v for ccamp@ops.ietf.org; Fri, 21 Sep 2007 17:09:19 +0000 Received: from esc91.midphase.com ([216.104.33.66] helo=LC1.labn.net) by esc91.midphase.com with esmtpa (Exim 4.68) (envelope-from ) id 1IYlzr-00081j-1P; Fri, 21 Sep 2007 13:08:55 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 21 Sep 2007 13:08:52 -0400 To: "Bardalai, Snigdho" From: Lou Berger Subject: Re: Question on RFC4873 Cc: ,, ,, "Ccamp (E-mail)" In-Reply-To: References: 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: 97adf591118a232206bdb5a27b217034 Snigdho, see responses in-line. At 12:07 PM 9/21/2007, Bardalai, Snigdho wrote: >Hi, > >RFC3473 has specified an option that allows tearing down an LSP >using the PathErr message with the Path_State_Removed option. If >this option is used in combination with the ADMINSTATUS object with >the D and R bits set in the Path message LSPs can be torn down in a >graceful manner. > > From reading RFC4873 it seems like this option is no longer > supported for the segment recovery LSPs. Section 4.2.4.2 in RFC4873 > requires that when a Path message with D and R bits set is > received, a Resv with the D bit set MUST be sent. I don't see this. Section 4.2.4.2 only relates to path senders (aka "the ingress node"). The draft doesn't limit/modify use of the PathErr message with the Path_State_Removed option. (Handling of such messages at the recovery LSP ingress is covered in 4.2.1.) Lou >What exactly is this addressing? From what I can see there is no >strong technical reason to not support PathErr with >Path_State_Removed for graceful teardown. Or is there one? > >Regards, >Snigdho From Piotr799@unfallklinik.com Fri Sep 21 13:51:14 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYmeo-0007uQ-Q2 for ccamp-archive@ietf.org; Fri, 21 Sep 2007 13:51:14 -0400 Received: from host87-138-dynamic.56-82-r.retail.telecomitalia.it ([82.56.138.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYmeZ-00012z-BW for ccamp-archive@ietf.org; Fri, 21 Sep 2007 13:51:08 -0400 Received: from jessica-1a13910 ([129.196.146.54] helo=jessica-1a13910) by host87-138-dynamic.56-82-r.retail.telecomitalia.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1FObur-000ALA-Hs for ccamp-archive@ietf.org; Fri, 21 Sep 2007 19:51:42 +0200 Message-ID: <000a01c7fc77$fa6f3b90$578a3852@jessica1a13910> From: "Piotr Kairis" To: Subject: amtsuber Date: Fri, 21 Sep 2007 19:51:03 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7FC88.BDF80B90" 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.4 (++++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0007_01C7FC88.BDF80B90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.maxsway.com/ Morning ccamp-archive I was able to get and sustain rock solid erections. I had growth of both = the length and the thickness Piotr Kairis ------=_NextPart_000_0007_01C7FC88.BDF80B90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    http://www.maxsway.com/
    Morning ccamp-archive
    I was able to get and sustain rock solid = erections. I=20 had growth of both the length and the thickness
    Piotr Kairis
    ------=_NextPart_000_0007_01C7FC88.BDF80B90-- From owner-ccamp@ops.ietf.org Fri Sep 21 14:49:26 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYnZ8-0002vb-Iy for ccamp-archive@ietf.org; Fri, 21 Sep 2007 14:49:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYnZ3-0002f2-6U for ccamp-archive@ietf.org; Fri, 21 Sep 2007 14:49:26 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IYnP6-0000kV-Py for ccamp-data@psg.com; Fri, 21 Sep 2007 18:39:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [168.127.0.57] (helo=fncnmp04.fnc.fujitsu.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IYnP4-0000k4-2c for ccamp@ops.ietf.org; Fri, 21 Sep 2007 18:39:03 +0000 X-IronPort-AV: E=Sophos;i="4.20,284,1186376400"; d="scan'208";a="124824583" Received: from rchemx01.fnc.net.local ([168.127.134.104]) by fncnmp02.fnc.fujitsu.com with ESMTP; 21 Sep 2007 13:39:01 -0500 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: Question on RFC4873 Date: Fri, 21 Sep 2007 13:39:00 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on RFC4873 Thread-Index: Acf8cvugnM9/pEXTSw6xacH8iMhtugACUDGA From: "Bardalai, Snigdho" To: "Lou Berger" Cc: , , , "Ccamp (E-mail)" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Hi Lou, The text is a bit confusing... Section 4.2.4.2 has a reference to Section 4.2.3 and in this section the = Path and Resv message processing is described. Section 4.2.3 talks about message co-ordination at the branch nodes. The = described method works fine when in response to a Path message with D+R = bits set a Resv with D bit set is generated at the egress location. I = believe in order for PathErr message with the Path_State_Removed option = set it is probably necessary to have some message coordination at the = merge nodes. as well. The Path messages with D+R bits set from all = branches need to be received at the merge node before the message can be = forwarded downstream. This is required in order to ensure that the = primary and secondary (recovery) LSPs can be deleted in a graceful = manner. Thanks, Snigdho -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Lou Berger Sent: Friday, September 21, 2007 12:09 PM To: Bardalai, Snigdho Cc: lberger@labn.net; IBryskin@advaoptical.com; dimitri.papadimitriou@alcatel-lucent.be; adrian@olddog.co.uk; Ccamp (E-mail) Subject: Re: Question on RFC4873 Snigdho, see responses in-line. At 12:07 PM 9/21/2007, Bardalai, Snigdho wrote: >Hi, > >RFC3473 has specified an option that allows tearing down an LSP=20 >using the PathErr message with the Path_State_Removed option. If=20 >this option is used in combination with the ADMINSTATUS object with=20 >the D and R bits set in the Path message LSPs can be torn down in a=20 >graceful manner. > > From reading RFC4873 it seems like this option is no longer=20 > supported for the segment recovery LSPs. Section 4.2.4.2 in RFC4873=20 > requires that when a Path message with D and R bits set is=20 > received, a Resv with the D bit set MUST be sent. I don't see this. Section 4.2.4.2 only relates to path senders (aka=20 "the ingress node"). The draft doesn't limit/modify use of the=20 PathErr message with the Path_State_Removed option. (Handling of such=20 messages at the recovery LSP ingress is covered in 4.2.1.) Lou >What exactly is this addressing? From what I can see there is no=20 >strong technical reason to not support PathErr with=20 >Path_State_Removed for graceful teardown. Or is there one? > >Regards, >Snigdho From p3617@labpak.com Fri Sep 21 15:40:20 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYoMO-0008Tz-7R for ccamp-archive@ietf.org; Fri, 21 Sep 2007 15:40:20 -0400 Received: from dpc674519026.direcpc.com ([67.45.19.26]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IYoMH-0007Wq-Ui for ccamp-archive@ietf.org; Fri, 21 Sep 2007 15:40:14 -0400 Received: from [237.58.114.174] (helo=bvz) by dpc674519026.direcpc.com with smtp (Exim 4.62 (FreeBSD)) id 1JIoNQ-0003Wd-ES; Fri, 21 Sep 2007 14:41:24 -0500 Message-ID: <46F41E17.6080601@labpak.com> Date: Fri, 21 Sep 2007 14:40:07 -0500 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: The answer to your question is yes Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.2 (+++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Check out our 1000 free games online. http://76.203.17.109/ From gu_nascimento@siemens.com.pk Fri Sep 21 15:40:57 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYoMz-00008I-9w for ccamp-archive@megatron.ietf.org; Fri, 21 Sep 2007 15:40:57 -0400 Received: from dpc674519026.direcpc.com ([67.45.19.26]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IYoMo-0003xy-FR for ccamp-archive@megatron.ietf.org; Fri, 21 Sep 2007 15:40:53 -0400 Received: from [66.170.204.113] (helo=atycp) by dpc674519026.direcpc.com with smtp (Exim 4.62 (FreeBSD)) id 1JIoN-0006gX-7f; Fri, 21 Sep 2007 14:40:57 -0500 Message-ID: <46F41E25.2050000@siemens.com.pk> Date: Fri, 21 Sep 2007 14:40:21 -0500 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ccamp-archive@megatron.ietf.org Subject: Your prayers have been answered Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Check out our 1000 free games online. http://62.238.195.105/ From Molllhw@agrilac.com Fri Sep 21 18:05:21 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYqcj-0003sY-5h for ccamp-archive@megatron.ietf.org; Fri, 21 Sep 2007 18:05:21 -0400 Received: from [88.235.103.33] (helo=[88.235.103.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYqcf-000085-Ma for ccamp-archive@megatron.ietf.org; Fri, 21 Sep 2007 18:05:19 -0400 Received: by 10.52.172.48 with SMTP id NKziWZYUBdErv; Sat, 22 Sep 2007 01:05:20 +0300 (GMT) Received: by 192.168.45.71 with SMTP id CYccFSuoUeniyb.6583470794021; Sat, 22 Sep 2007 01:05:18 +0300 (GMT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 22 Sep 2007 01:05:15 +0300 To: ccamp-archive@megatron.ietf.org From: "Evaldo Moll" Subject: opeimmat Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 3.7 (+++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 R,umor N*e w_s.: Oncol+og-y M e+d.. I'n'c.. (OTC-: ONC+O) a C'ancer Treat.me.nt Sol*u'tions Grou_p is s,a-i_d to h a,v,e exp-,erienced o-v_e*r a 10+00% in-cr*ease in reve,n_ues f+o-r t.h*e f iscal 3+r+d quart.er end*ing J_u,l-y*, 2 0*0*7 c*ompar-ed w_i.t'h t,h.e pri.or y'e,a-r whi le fisc.al fourt*h quart_er re*sults f+o_r 2*0,0,7 a_r e on tra.ck to exce'ed t'h,i's ye ar’s t.hird quart+er re-sults. O-N.C'O addi tiona lly p lans to i.ncre+ase s_ervice offer--ings w,hich a.r,e cur_rent ly underway_'. Do*n’t w,a_i-t f.o r t,h.e n.e_w.s to c+o*m.e o-u-t a-n_d l,o*s-e t+h'e oppo'rt-unity to g-e,t in fr_ont of the gener*al inves.*ting p_ublic. Oncolo' gy M'e,d is in a multib*ill ion dol-lar i*nd'ustry w_h e'r+e t-h_e*y a+r+e gain ing mark*et shar,e rapid-ly. C-a-l+l y'o-u-r bro'ker n+o+w f+o_r O'N+C'O*. From ohhzu3lnia@varig.com Fri Sep 21 19:12:10 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYrfO-00075I-3w; Fri, 21 Sep 2007 19:12:10 -0400 Received: from 84.121.252.231.dyn.user.ono.com ([84.121.252.231]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IYrfN-0006ir-1j; Fri, 21 Sep 2007 19:12:09 -0400 To: iesg-request@ietf.org From: "Mattie Vernon" Subject: Rolex Replicas, Fake Rolex Watches, Cartier, Omega, IWC, Swiss Replica Watches my Message-ID: <20d96320.89w20501717@gap.com> Date: Fri, 21 Sep 2007 18:12:08 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--uxcd0f60kyhbn5v019gimmj87bm7o3" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 ----uxcd0f60kyhbn5v019gimmj87bm7o3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Super Branded Watches (85% Price Off) : RolexMen : RolexLady : Alain Silberstein : Audemars Piguet : Breitling : Bvlgari : Cartier : Chanel : Chopard : Franck Muller : IWC : Jaeger-Lecoultre : Omega : Panerai Luminor : Patek Philippe : Tag Heuer Only from $189 Each :- Click below link http://rpbit.kxfiscated.com http://rqnw.kxfiscated.com ----uxcd0f60kyhbn5v019gimmj87bm7o3 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
    Super Branded Watches (85% Price Off)
    RolexMen
    RolexLady
    Alain Silberstein
    Audemars Piguet
    Breitling
    Bvlgari
    Cartier
    Chanel
    Chopard
    Franck Muller
    IWC
    Jaeger-Lecoultre
    Omega
    Panerai Luminor
    Patek Philippe
    Tag Heuer
    Only from $189 Each :- Click below link
    [Link 1]     [Link 2]

    fancy respect mentioned times.
    ----uxcd0f60kyhbn5v019gimmj87bm7o3-- From cjfcnm@blueskywood.com Sat Sep 22 01:15:51 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYxLL-00088c-4M; Sat, 22 Sep 2007 01:15:51 -0400 Received: from amontpellier-157-1-153-217.w90-9.abo.wanadoo.fr ([90.9.72.217]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYxLH-000779-8R; Sat, 22 Sep 2007 01:15:47 -0400 Received: from [90.9.72.217] by company.blueskywood.com; Sat, 22 Sep 2007 06:15:43 +0100 From: "Lisa Gutierrez" To: Subject: Bug #100 SMILEY Date: Sat, 22 Sep 2007 06:15:43 +0100 Message-ID: <01c7fcd7$9fcda090$d948095a@cjfcnm> 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.1158 Importance: Normal X-Spam-Score: 4.0 (++++) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed PPYH Finishes Restructure to Focus on Trillion Dollar China Market. Physical Property Holdings Inc. PPYH $0.25 PPYH has recently restructured their company to focus on the booming China real estate market. With Dozens of Multi Million Dollar properties listed on the new website, this company is going to explode. Get on PPYH first thing Monday! From joker_Hoglind@bargainawnings.com Sat Sep 22 09:46:07 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ5J9-00089X-NF for ccamp-archive@megatron.ietf.org; Sat, 22 Sep 2007 09:46:07 -0400 Received: from centurion.arkada-x.com.ua ([194.44.23.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZ5J2-0003ZE-Bd for ccamp-archive@megatron.ietf.org; Sat, 22 Sep 2007 09:46:03 -0400 Received: from home-j7dx350yal by bargainawnings.com with ASMTP id 16A8DBA4 for ; Sat, 22 Sep 2007 16:45:52 +0300 Received: from home-j7dx350yal ([114.149.46.35]) by bargainawnings.com with ESMTP id 426A8392149F for ; Sat, 22 Sep 2007 16:45:52 +0300 Message-ID: <000901c7fd1e$dd9e1700$be172cc2@homej7dx350yal> From: "joker Hoglind" To: Subject: 8943019 Date: Sat, 22 Sep 2007 16:45:41 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C7FD38.02EB4F00" 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.0 (++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0006_01C7FD38.02EB4F00 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable http://www.mountanx.com/ Wazzup ccamp-archive imagine the look on your wifes face when she sees the new you joker Hoglind ------=_NextPart_000_0006_01C7FD38.02EB4F00 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
    http://www.mountanx.com/
    Wazzup ccamp-archive
    imagine the look on your wifes face when she = sees the=20 new you
    joker Hoglind
    ------=_NextPart_000_0006_01C7FD38.02EB4F00-- From nalq0tlocl@jci.com Sat Sep 22 11:37:28 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ72u-0006ge-HS; Sat, 22 Sep 2007 11:37:28 -0400 Received: from [12.206.143.140] (helo=nzupjvye) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IZ72t-0006TX-Va; Sat, 22 Sep 2007 11:37:28 -0400 To: From: "Tiffanie Lannie" Subject: Rolex Replica, Fake Rolex Watches, Cartier, Omega, IWC, Swiss Replica Watches yx Message-ID: <067i67162.04652n63956145@jci.com> Date: Sat, 22 Sep 2007 11:37:00 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--kkte32nfc1ktsalie3seqjwmz" X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a ----kkte32nfc1ktsalie3seqjwmz Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Super Branded Watches (85% Price Off) : RolexMen : RolexLady : Alain Silberstein : Audemars Piguet : Breitling : Bvlgari : Cartier : Chanel : Chopard : Franck Muller : IWC : Jaeger-Lecoultre : Omega : Panerai Luminor : Patek Philippe : Tag Heuer Only from $189 Each :- Click below link http://rqasmn.kypatriot.com http://reomn.kypatriot.com ----kkte32nfc1ktsalie3seqjwmz Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
    Super Branded Watches (85% Price Off)
    RolexMen
    RolexLady
    Alain Silberstein
    Audemars Piguet
    Breitling
    Bvlgari
    Cartier
    Chanel
    Chopard
    Franck Muller
    IWC
    Jaeger-Lecoultre
    Omega
    Panerai Luminor
    Patek Philippe
    Tag Heuer
    Only from $189 Each :- Click below link
    [Link 1]     [Link 2]

    pay come arms come. sense degree already blue.
    ----kkte32nfc1ktsalie3seqjwmz-- From ulate50spsb@baxter.com Sat Sep 22 12:24:04 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ7m0-0001HP-LT; Sat, 22 Sep 2007 12:24:04 -0400 Received: from pool-71-187-91-92.nwrknj.east.verizon.net ([71.187.91.92] helo=qitww) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IZ7lw-0007Yt-3J; Sat, 22 Sep 2007 12:24:00 -0400 Received: from [71.172.176.21] by ; Sat, 22 Sep 2007 11:14:03 -0500 Message-ID: <01c7fd34$f99ea940$15b0ac47@ulate50spsb> From: "Manuela Shoemaker" To: Subject: *])(.[ ]-.(! - ] **:.. Date: Sat, 22 Sep 2007 11:14:03 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 X-Spam-Score: 2.4 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Ti.ck[eeer F)D.E+G Last 0.04 Ta)rg[et 0.12 From cheryl-Petrosyan@scarydreams.net Sat Sep 22 12:46:05 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ87J-00053f-3g for ccamp-archive@ietf.org; Sat, 22 Sep 2007 12:46:05 -0400 Received: from 72.pool85-59-86.dynamic.orange.es ([85.59.86.72] helo=86.pool85-60-31.dynamic.orange.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZ876-0001n8-8z for ccamp-archive@ietf.org; Sat, 22 Sep 2007 12:46:00 -0400 Received: from forner ([177.167.97.46] helo=forner) by 30.pool85-54-246.dynamic.orange.es ( sendmail 8.13.3/8.13.1) with esmtpa id 1NYsgB-000AXS-nN for ccamp-archive@ietf.org; Sat, 22 Sep 2007 18:46:14 +0200 Message-ID: <000901c7fd37$ff8567b0$1ef63655@forner> From: "cheryl Petrosyan" To: Subject: proctium Date: Sat, 22 Sep 2007 18:45:35 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C7FD48.C30E37B0" 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.3 (++++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 ------=_NextPart_000_0008_01C7FD48.C30E37B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.mountanx.com/ greeting ccamp-archive people are so shocked when they find out these herbal pills actually = work cheryl Petrosyan ------=_NextPart_000_0008_01C7FD48.C30E37B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    http://www.mountanx.com/
    greeting ccamp-archive
    people are so shocked when they find out these = herbal=20 pills actually work
    cheryl Petrosyan
    ------=_NextPart_000_0008_01C7FD48.C30E37B0-- From rpbeternal@sovereignsc.com Sat Sep 22 14:13:27 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ9Tr-00016K-FV; Sat, 22 Sep 2007 14:13:27 -0400 Received: from host851484246.3s.pl ([85.14.84.246] helo=tc154.internetdsl.tpnet.pl) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IZ9Th-0001pg-M6; Sat, 22 Sep 2007 14:13:18 -0400 Received: from qh6hnvvxkacrfg1 ([97.148.233.51]:24209 "HELO qh6hnvvxkacrfg1" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 9a6a3750sovereignsc.com with ESMTP id 1734256B1AD1 (ORCPT ); Sat, 22 Sep 2007 20:12:51 +0200 Message-ID: <001c01c7fd54$f42d7b10$018ff21c@qh6hnvvxkacrfg1> From: Magdalena To: ccamp-archive@ietf.org Subject: hindian Date: Sat, 22 Sep 2007 20:12:51 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C7FD54.F42D7B10" 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.181 X-Spam-Score: 2.9 (++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C7FD54.F42D7B10 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable drawing by hand.These quickly redrawn views however, only remain opportunities for new and non-mainstream art to find an audience. do the m= ore integration of signals will occur. It is interesting ------=_NextPart_000_0019_01C7FD54.F42D7B10 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable

    which challenges the conventional meanings of art and literary

    Are you wanting a bigger p >e n _i s?

    As se -e -n on TV

    Over 701,000 Men around the world are already satisfied
    Gain 4+ Inches In Leng _th
    Increase Your P _en -is Wi _dth (Girth) By up _to 27%
    100% Safe To Take, With NO Side Effects
    No Pum ps! No Surg ery! No Ex ercises!
    *3 FREE Bottles

    still be better than nothing and would probably make a positive
    ------=_NextPart_000_0019_01C7FD54.F42D7B10-- From Chintana.manson@NREIS.COM Sat Sep 22 14:44:00 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ9xQ-0008Sz-SI for ccamp-archive@ietf.org; Sat, 22 Sep 2007 14:44:00 -0400 Received: from e182047021.adsl.alicedsl.de ([85.182.47.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZ9x5-0002UX-On for ccamp-archive@ietf.org; Sat, 22 Sep 2007 14:43:40 -0400 Received: from KRÜGER by NREIS.COM with ASMTP id EFE0AE8D for ; Sat, 22 Sep 2007 20:45:15 +0200 Received: from KRÜGER ([178.191.2.27]) by NREIS.COM with ESMTP id 0A2B66AE7614 for ; Sat, 22 Sep 2007 20:45:15 +0200 Message-ID: <19CC3F64.97F638B5@NREIS.COM> Date: Sat, 22 Sep 2007 20:44:51 +0200 From: "Chintana manson" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: mopus Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000775-6, 22.09.2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 2.0 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Evening ccamp-archive these herbs are used in Africa and look at the size of their manhoods Chintana manson http://modaua.com/ From sallyf@scnsoft.com Sat Sep 22 16:50:03 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZBvP-0006BA-Kb for ccamp-archive@ietf.org; Sat, 22 Sep 2007 16:50:03 -0400 Received: from [87.252.165.16] (helo=16-165-252-87.astrabg.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IZBvM-0005Z6-Mx for ccamp-archive@ietf.org; Sat, 22 Sep 2007 16:50:01 -0400 Received: (qmail 27330 invoked from network); Sat, 22 Sep 2007 23:49:03 +0300 Received: from unknown (HELO ogr) (176.72.65.68) by 16-165-252-87.astrabg.net with SMTP; Sat, 22 Sep 2007 23:49:03 +0300 Message-ID: <000901c7fd5a$025a1310$444148b0@ogr> From: To: Subject: Please read this before Monday Date: Sat, 22 Sep 2007 23:49:03 +0300 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.4920.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-Spam-Score: 0.6 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Watch Out For Big News Monday Score One Inc. (SREA) $0.1 Don't be surprised to see this skyrocket after news hits. Get on SREA before news hits the street on Monday. From bulkinnn@cms-uk.org Sat Sep 22 20:03:14 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZEwM-0008Em-ED for ccamp-archive@megatron.ietf.org; Sat, 22 Sep 2007 20:03:14 -0400 Received: from [189.168.116.82] (helo=desktop) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZEwL-0003N9-6I for ccamp-archive@megatron.ietf.org; Sat, 22 Sep 2007 20:03:14 -0400 Received: from 189.168.116.82 by Mx103.emailfiltering.com; Sat, 22 Sep 2007 19:03:38 +0200 From: "bulkinnn" To: "ccamp-archive" Subject: Scientists: Hobbit Date: Sun, 23 Sep 2007 01:35:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Aca6Qqm2WrNZOJseWpWMSgQeFciTob== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Message-ID: X-Spam-Score: 4.4 (++++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 PPYH Announces Acquisition Of Manhattan Hill Project Apartments. Physical Property Holdings Inc. PPYH $0.25 This release is huge, read up and check out the Manhattan hill website. PPYH will rock investors on Monday with this news. Get ahead of the rush and grab PPYH first thing on Monday morning. The mother of a teenage girl who died behind bars. A three-year-old girl abandoned by her father in Australia as. From bulkinnn@cms-uk.org Sat Sep 22 20:03:16 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZEwO-0008GK-06 for ccamp-archive@ietf.org; Sat, 22 Sep 2007 20:03:16 -0400 Received: from [189.168.116.82] (helo=desktop) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZEwN-0001z6-DO for ccamp-archive@ietf.org; Sat, 22 Sep 2007 20:03:15 -0400 Received: from 189.168.116.82 by Mx103.emailfiltering.com; Sat, 22 Sep 2007 19:03:40 +0200 From: "bulkinnn" To: "ccamp-archive" Subject: Scientists: Hobbit Date: Sun, 23 Sep 2007 01:35:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Aca6Qqm2WrNZOJseWpWMSgQeFciTob== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Message-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 PPYH Announces Acquisition Of Manhattan Hill Project Apartments. Physical Property Holdings Inc. PPYH $0.25 This release is huge, read up and check out the Manhattan hill website. PPYH will rock investors on Monday with this news. Get ahead of the rush and grab PPYH first thing on Monday morning. The mother of a teenage girl who died behind bars. A three-year-old girl abandoned by her father in Australia as. From ersun-dubayen@serviceexpressinc.com Sat Sep 22 20:39:24 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZFVM-0002Y1-IT for ccamp-archive@megatron.ietf.org; Sat, 22 Sep 2007 20:39:24 -0400 Received: from wsip-70-184-174-146.hr.hr.cox.net ([70.184.174.146] helo=ip70-177-255-251.hr.hr.cox.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZFVC-0003yY-DP for ccamp-archive@megatron.ietf.org; Sat, 22 Sep 2007 20:39:20 -0400 Received: from AL-JUFI ([141.136.6.147] helo=AL-JUFI) by ip70-177-255-251.hr.hr.cox.net ( sendmail 8.13.3/8.13.1) with esmtpa id 1SzQDN-000CHB-Jj for ccamp-archive@megatron.ietf.org; Sat, 22 Sep 2007 20:39:10 -0400 Message-ID: <000501c7fd7a$1daf8cb0$fbffb146@ALJUFI> From: "ersun dubayen" To: Subject: tynytsim Date: Sat, 22 Sep 2007 20:38:52 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7FD58.969DECB0" 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.5 (+++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0007_01C7FD58.969DECB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.msdesert.com/ Greeting ccamp-archive imagine the look on your wifes face when she sees the new you ersun dubayen ------=_NextPart_000_0007_01C7FD58.969DECB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    http://www.msdesert.com/
    Greeting ccamp-archive
    imagine the look on your wifes face when she = sees the=20 new you
    ersun dubayen
    ------=_NextPart_000_0007_01C7FD58.969DECB0-- From Kerbelpxic@paal9.com Sun Sep 23 04:56:20 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZNGG-0007LI-1t for ccamp-archive@ietf.org; Sun, 23 Sep 2007 04:56:20 -0400 Received: from host235-51-dynamic.117-80-r.retail.telecomitalia.it ([80.117.51.235]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZNGF-0001WM-Ae for ccamp-archive@ietf.org; Sun, 23 Sep 2007 04:56:19 -0400 Received: from computer-ecd4c7 ([199.184.45.141] helo=computer-ecd4c7) by host235-51-dynamic.117-80-r.retail.telecomitalia.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1dQMrz-000OUF-Pq for ccamp-archive@ietf.org; Sun, 23 Sep 2007 10:57:14 +0200 Message-ID: Date: Sun, 23 Sep 2007 10:56:44 +0200 From: "Di Kerbel" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: negniled 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 get a BIG schlong, check this website out. Di Kerbel http://www.gptone.com/ From Kroeger@paal9.com Sun Sep 23 04:58:52 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZNIh-0002BO-UB for ccamp-archive@megatron.ietf.org; Sun, 23 Sep 2007 04:58:52 -0400 Received: from host235-51-dynamic.117-80-r.retail.telecomitalia.it ([80.117.51.235]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZNIh-0001Yi-6H for ccamp-archive@megatron.ietf.org; Sun, 23 Sep 2007 04:58:51 -0400 Received: from computer-ecd4c7 ([110.155.142.191]:22098 "EHLO computer-ecd4c7" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by host235-51-dynamic.117-80-r.retail.telecomitalia.it with ESMTP id S22CUSFFEERJBFLZ (ORCPT ); Sun, 23 Sep 2007 10:59:54 +0200 Message-ID: <000801c7fdc0$0984ba30$eb337550@computerecd4c7> From: "Jayme Kroeger" To: Subject: negdiloo Date: Sun, 23 Sep 2007 10:59:23 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7FDD0.CD0D8A30" 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.1 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0007_01C7FDD0.CD0D8A30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.gpogor.com/ hello ccamp-archive WOW! EXCLUSIVE herbal pills that will ENLARGE your cock Jayme Kroeger ------=_NextPart_000_0007_01C7FDD0.CD0D8A30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    http://www.gpogor.com/
    hello ccamp-archive
    WOW! EXCLUSIVE herbal pills that will ENLARGE = your cock
    Jayme Kroeger
    ------=_NextPart_000_0007_01C7FDD0.CD0D8A30-- From cup@mynmail.com Sun Sep 23 06:53:26 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZP5a-0000bL-Aj for ccamp-archive@megatron.ietf.org; Sun, 23 Sep 2007 06:53:26 -0400 Received: from [125.187.32.246] (helo=m00.mailyes.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZP5R-00049q-PV for ccamp-archive@megatron.ietf.org; Sun, 23 Sep 2007 06:53:24 -0400 Received: (qmail 11635 invoked by uid 0); 23 Sep 2007 19:20:43 +0900 Message-ID: <20070923102043.11634.qmail@m00.mailyes.net> To: ccamp-archive Subject: =?ISO-2022-JP?B?GyRCJDQ2YT1qOCE6dyRHQigbKEI=?= =?ISO-2022-JP?B?GyRCJSIlXTQwQTRMNU5BGyhC?= From: infomail Reply-to: delivery_rt Date: 2007-09-23 19:01:02 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: GOOD Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20070921173850_cbur Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 3.6 (+++) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f -------$B!|!|!|!|!|!|!|!!(0!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1(0(B -----$B!|(B///////////$B!|!@!!!!!!!!!!!!40A41J5WL5NA%5%$%H(B ---$B!|(B////////////$B!|!@!!(0(Bhttp://black-6969.org.uk/pc/index2.php?u9psp4 --$B!|(B////////////$B!|!@(B-$B!|!|!|!|!|!|!|!|!|!|!|(B---$B!|!|!|!|!|!|!|!|!|!|!|(B ---$B!|!|!|(B//////$B!|!@(B-$B!|(B//////////////////$B!|!@(B-$B!|(B//////////////////$B!|!@(B ------$B!|(B//////$B!|!@(B-$B!|(B////$B!|!|!|!|!|(B////$B!|!@(B-$B!|(B////$B!|!|!|!|!|(B////$B!|!@(B -----$B!|(B//////$B!|!@(B-$B!|(B////$B!|!@!@!@!|(B////$B!|!@(B-$B!|(B////$B!|!@!@!@!|(B////$B!|!@(B ----$B!|(B//////$B!|!@(B-$B!|(B////$B!|!@(B----$B!|(B////$B!|!@(B-$B!|(B////$B!|!@(B----$B!|(B////$B!|!@(B ---$B!|(B//////$B!|!@(B-$B!|(B////$B!|!@(B----$B!|(B////$B!|!@(B-$B!|(B////$B!|!@(B----$B!|(B////$B!|!@(B --$B!|(B//////$B!|!@(B-$B!|(B////$B!|!|!|!|!|(B////$B!|!@(B-$B!|(B////$B!|!|!|!|!|(B////$B!|!@(B -$B!|(B//////$B!|!@(B-$B!|(B//////////////////$B!|!@(B-$B!|(B//////////////////$B!|!@(B $B!|!|!|!|!|!@(B-$B!|!|!|!|!|!|!|!|!|!|!|!@(B-$B!|!|!|!|!|!|!|!|!|!|!|!@(B $B!@!@!@!@!@!!(B $B!@!@!@!@!@!@!@!@!@!@!@!!(B $B!@!@!@!@!@!@!@!@!s=P2q$($k!#(B $B!!(B $B!!(B $B!!!!!!!!!!"v$*6b$r$+$1$J$$$G2q$($k$N$O$"$?$jA0"v(B $B!!!!(Bhttp://black-6969.org.uk/pc/index2.php?u9psp4 $B!!(B $B!!!!!!!!!!"v$I$&$;$J$i%(%C%A$7$F$*6b$rLc$*$&$h"v(B $B!!!!(Bhttp://black-6969.org.uk/pc/index2.php?u9psp4 $B!!(B $B!!!!!!!!!!"v%;%l%V$J?M:J$,5.J}$r$*BT$A$7$F$$$^$9"v(B $B!!!!(Bhttp://black-6969.org.uk/pc/index2.php?u9psp4 $B!!(B $B!!!!!!!!!!EPO?NA!&MxMQNA!!!&!&!&!&!&!&!&!&!&!ZL5NA![(B $B!!!!!!!!!!%a!<%k$NAw Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZPhE-00008J-EF for ccamp-archive@megatron.ietf.org; Sun, 23 Sep 2007 07:32:20 -0400 Received: from chello087206089038.chello.pl ([87.206.89.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZPh8-0004AA-Ng for ccamp-archive@megatron.ietf.org; Sun, 23 Sep 2007 07:32:15 -0400 Received: from mac ([197.140.4.43] helo=mac) by chello087206089038.chello.pl ( sendmail 8.13.3/8.13.1) with esmtpa id 1AdYNh-000CNY-uZ for ccamp-archive@megatron.ietf.org; Sun, 23 Sep 2007 13:29:53 +0200 Message-ID: <000301c7fdd5$007f69c0$2659ce57@mac> From: "Bayani Hensley" To: Subject: shikakud Date: Sun, 23 Sep 2007 13:29:28 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C7FDE5.C40839C0" 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: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0008_01C7FDE5.C40839C0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable http://www.grafitgi.com/ greeting ccamp-archive No girls laugh at me now, haha, i laugh at them Bayani Hensley ------=_NextPart_000_0008_01C7FDE5.C40839C0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
    http://www.grafitgi.com/
    greeting ccamp-archive
    No girls laugh at me now, haha, i laugh at = them
    Bayani Hensley
    ------=_NextPart_000_0008_01C7FDE5.C40839C0-- From Rimas-Huckelberry@aigrette.net Sun Sep 23 11:10:20 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZT6C-0008H0-AB for ccamp-archive@ietf.org; Sun, 23 Sep 2007 11:10:20 -0400 Received: from 5ac97f94.bb.sky.com ([90.201.127.148] helo=5ac97f93.bb.sky.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZT5u-0000ba-2w for ccamp-archive@ietf.org; Sun, 23 Sep 2007 11:10:02 -0400 Received: from your-bblib2itoh by aigrette.net with ASMTP id FFF3033E for ; Sun, 23 Sep 2007 16:10:01 +0100 Received: from your-bblib2itoh ([108.156.129.29]) by aigrette.net with ESMTP id B6A41E9B41BE for ; Sun, 23 Sep 2007 16:10:01 +0100 Message-ID: <000201c7fdf3$c8ca2640$937fc95a@yourbblib2itoh> From: "Rimas Huckelberry" To: Subject: kilag Date: Sun, 23 Sep 2007 16:09:49 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C7FDFC.2A8E8E40" 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.7 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0006_01C7FDFC.2A8E8E40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://guaed.com/ Hi there ccamp-archive Voted no.1 schlong enlargement product 2007 Rimas Huckelberry ------=_NextPart_000_0006_01C7FDFC.2A8E8E40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    http://guaed.com/
    Hi there ccamp-archive
    Voted no.1 schlong enlargement product = 2007
    Rimas Huckelberry
    ------=_NextPart_000_0006_01C7FDFC.2A8E8E40-- From rscheme@klkcpa.com Sun Sep 23 11:33:45 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZTSr-0001Ra-LY; Sun, 23 Sep 2007 11:33:45 -0400 Received: from [80.50.254.50] (helo=klkcpa.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IZTSi-0001Ki-JV; Sun, 23 Sep 2007 11:33:37 -0400 Received: from barbol ([80.107.140.118]:20750 "HELO barbol" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 32fe3250klkcpa.com with ESMTP id y9RJTIDU214456 (ORCPT ); Sun, 23 Sep 2007 17:33:18 +0200 Message-ID: <001001c7fe07$d46985e0$0180aee4@barbol> From: overnight it To: ccamp-archive@ietf.org Subject: do to logistics Date: Sun, 23 Sep 2007 17:33:18 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C7FE07.D46985E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.2962 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2720.2969 X-Spam-Score: 2.1 (++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C7FE07.D46985E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable electronic facilities, whereas paper is mortal and indefinite it is. Virtual reality is being treated like some radical new Adventure's h= is bread, excitement's his butter and danger, why to ------=_NextPart_000_000D_01C7FE07.D46985E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    computer technology has yet to offer the contemporary artist.

    Are you wanting a bigger p >e n _i s?

    As se -e -n on TV

    Over 775,000 Men around the world are already satisfied
    Gain 4+ Inches In Leng _th
    Increase Your P _en -is Wi _dth (Girth) By up _to 25%
    100% Safe To Take, With NO Side Effects
    No Pum ps! No Surg ery! No Ex ercises!
    *3 FREE Bottles

    answer: the country with contemporary technology and culture
    ------=_NextPart_000_000D_01C7FE07.D46985E0-- From EtiLister@jetsys.co.kr Sun Sep 23 15:49:38 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZXSU-0005RG-QK for ccamp-archive@ietf.org; Sun, 23 Sep 2007 15:49:38 -0400 Received: from [82.84.193.90] (helo=ppp-82-84-193-90.cust-adsl.tiscali.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZXSF-0000L3-DP for ccamp-archive@ietf.org; Sun, 23 Sep 2007 15:49:23 -0400 Received: from ester-b39d2c482 ([124.100.115.75] helo=ester-b39d2c482) by ppp-82-84-193-90.cust-adsl.tiscali.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1NZfGU-000USG-QJ for ccamp-archive@ietf.org; Sun, 23 Sep 2007 21:50:18 +0200 Message-ID: <000501c7fe1a$e4572670$5ac15452@esterb39d2c482> From: "Eti Lister" To: Subject: resigh Date: Sun, 23 Sep 2007 21:49:45 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7FE2B.A7DFF670" 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.5 (+++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0007_01C7FE2B.A7DFF670 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.sglzw.com/ Good day ccamp-archive people are so shocked when they find out these herbal pills actually = work Eti Lister ------=_NextPart_000_0007_01C7FE2B.A7DFF670 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    http://www.sglzw.com/
    Good day ccamp-archive
    people are so shocked when they find out these = herbal=20 pills actually work
    Eti Lister
    ------=_NextPart_000_0007_01C7FE2B.A7DFF670-- From owner-ccamp@ops.ietf.org Sun Sep 23 18:14:52 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZZj2-0005qZ-NU for ccamp-archive@ietf.org; Sun, 23 Sep 2007 18:14:52 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZZix-000385-3Y for ccamp-archive@ietf.org; Sun, 23 Sep 2007 18:14:47 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IZZXV-0006tX-Ba for ccamp-data@psg.com; Sun, 23 Sep 2007 22:02:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [212.23.3.27] (helo=doppler.zen.co.uk) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IZZXS-0006tE-RF for ccamp@ops.ietf.org; Sun, 23 Sep 2007 22:02:56 +0000 Received: from [212.23.3.141] (helo=heisenberg.zen.co.uk) by doppler.zen.co.uk with esmtp (Exim 4.50) id 1IZZXH-0000Y0-7Z for ccamp@ops.ietf.org; Sun, 23 Sep 2007 22:02:43 +0000 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1IZZWI-0005OT-Rr for ccamp@ops.ietf.org; Sun, 23 Sep 2007 22:01:42 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 23 Sep 2007 23:01:42 +0100 Message-ID: <021401c7fe2d$4bf2b850$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Four new liaisons received from ITU-T SG15 Date: Sun, 23 Sep 2007 22:48:47 +0100 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-OriginalArrivalTime: 23 Sep 2007 22:01:42.0572 (UTC) FILETIME=[532BEEC0:01C7FE2D] X-Originating-Heisenberg-IP: [88.96.235.138] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Hi, ITU-T Study Group 15 Questions 12 and 14 met in Stuttgart earlier this month and generated four liaisons to us. Liaison Statement to CCAMP WG on GMPLS Signaling for VCAT/LCAS https://datatracker.ietf.org/liaison/371/ For action. Response requested by 4th February 2008 Liaison Statement to IETF CCAMP on ASON Routing Loop Prevention https://datatracker.ietf.org/liaison/370/ For action. Response requested by 19th November 2007 Liaison Statement to CCAMP on GMPLS Calls https://datatracker.ietf.org/liaison/369/ For action. Response requested by 4th February 2008 Liaison Statement to CCAMP on Multi-Layer Network I-Ds https://datatracker.ietf.org/liaison/368/ In response to our liaison. No response is required, but we need to take this as input to our Working Group last call. As always, you can track liaisons at www.olddog.co.uk/ccamp.htm Assistance in drafting responses will be much welcomed. Thanks, Adrian From owner-ccamp@ops.ietf.org Mon Sep 24 05:55:48 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZkfM-00040L-LW for ccamp-archive@ietf.org; Mon, 24 Sep 2007 05:55:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZkfI-0001tX-VN for ccamp-archive@ietf.org; Mon, 24 Sep 2007 05:55:48 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IZkS5-000LHT-Jq for ccamp-data@psg.com; Mon, 24 Sep 2007 09:42:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.1 Received: from [61.144.161.53] (helo=szxga01-in.huawei.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IZkS2-000LGo-KU for ccamp@ops.ietf.org; Mon, 24 Sep 2007 09:42:04 +0000 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JOV00CD29LZEA@szxga01-in.huawei.com> for ccamp@ops.ietf.org; Mon, 24 Sep 2007 17:41:59 +0800 (CST) Received: from M55527 ([10.111.12.79]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JOV00IZ89LUAE@szxga01-in.huawei.com> for ccamp@ops.ietf.org; Mon, 24 Sep 2007 17:41:59 +0800 (CST) Date: Mon, 24 Sep 2007 17:41:45 +0800 From: Mach Chen Subject: =?gb2312?B?tPC4tDogW21wbHNdIEFzayBmb3IgY29tbWVudHMgb24gIklHUCBleA==?= =?gb2312?B?dGVuc2lvbiBpbiBzdXBwb3J0IG9mIGludGVyLUFTImRyYWZ0cw==?= In-reply-to: <005201c7fba7$d0c79740$0601a8c0@pc6> To: "'tom.petch'" Cc: ccamp@ops.ietf.org, 'OSPF List' Message-id: <019601c7fe8f$1f238b30$4f0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acf7sZ3iKouaCc6fQraeds2F7QwxYwAP2TEg Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.7 (--) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Hi Tom, Thanks for your comments! Sorry for the delay reply. Pls see inline. > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: owner-ccamp@ops.ietf.org = [mailto:owner-ccamp@ops.ietf.org] =B4=FA=B1=ED > tom.petch > =B7=A2=CB=CD=CA=B1=BC=E4: 2007=C4=EA9=D4=C221=C8=D5 0:35 > =CA=D5=BC=FE=C8=CB: Mach Chen > =B3=AD=CB=CD: ccamp@ops.ietf.org > =D6=F7=CC=E2: Re: [mpls] Ask for comments on "IGP extension in support = of > inter-AS"drafts >=20 > A minor editorial on = draft-ietf-ccamp-ospf-interas-te-extension-01.txt. >=20 > Since 3.2 says > "The value of the Link Type for an inter-AS point-to-point link is 3. = The use > of multi-access inter-AS TE links is for future study" > I think that s6. IANA Considerations should also be specific to point-to-point > and not just > " 3 Inter-AS link " Yes, it should be like this:" 3 Inter-AS point-to-point link" >=20 > And a more substantive issue. The I-D claims to be OSPF version = agnostic but, > as draft-ietf-ospf-ospfv3-traffic-08.txt (cited as an Informative Reference > only) says > "A new LS type is defined for the Intra-Area-TE LSA. This is > different from OSPFv2 Traffic Engineering [TE] where opaque LSAs = are > used to advertise TE information [OPAQUE]." > which leaves me thinking that that should be a normative reference = and that > text such as > "Type 10 opaque LSAs [RFC2370] are used to carry such TE information" > needs stretching to encompass OSPFv3. Yes, we will make this a Normative Reference. Here is the suggested text for use in Section 1: "[OSPF-TE-V3] defines similar extensions to OSPFv3 [OSPFV3], it defines = a new LSA which is referred to as Intra-Area-TE LSA, to advertise TE information. [OSPF-TE-V3] uses "Traffic Engineering Extensions to OSPF" [OSPF-TE] as a base for TLV definitions and defines some new TLVs and sub-TLVs to extend TE capabilities to IPv6 networks." >=20 > Likewise, 3.3. Link ID says >=20 > " For an inter-AS link, the Link ID carried in the Link ID sub-TLV is > the remote ASBR identifier which could be any address of the remote > ASBR(e.g., the TE Router ID, Router ID or interface address of the > remote ASBR reached through this inter-AS link). The TE Router ID = is > RECOMMENDED. >=20 > whereas ospfv3-traffic says >=20 > " The Link ID sub-TLV is used in OSPFv2 to identify the other end of > the link. In OSPFv3, the Neighbor ID sub-TLV MUST be used for link > identification. In OSPFv3, The Link ID sub-TLV SHOULD NOT be sent > and MUST be ignored upon receipt. >=20 > Again, looks like the language needs stretching=20 Yes,=20 As to the Section 3.3 "Link ID", actually, using Remote ASBR ID is more suitable for an inter-AS TE link. If only for OSPF v2 TE, using Link ID = to carry the Remote ASBR ID is OK. But the remote ASBR identifier could be = an IPv4 address or an IPv6 address, using Link ID sub-TLV(OSPF-TE-v2) = ,Neighbor ID sub-TLV(OSPF-TE-v3) or other legacy sub-TLVs to carry the Remote ASBR = ID is not suitable. So, a new separate sub-TLV: Remote ASBR ID sub-TLV, is needed to carry the Remote ASBR ID, just as defined in the "ISIS = inter-AS TE extension" document. > and the reference be made normative. =20 Yes, as you suggested, the reference will be updated in the next = revision (version 02). > There may be other instances of this as well; has this been reviewed > by the authors of ospfv3-traffic? We hope to receive more comments and suggestions from the authors of ospfv3-traffic and others, and we will continue to notify the OSPF = working group of our progress. >=20 > Tom Petch >=20 Thanks again! Best regards, Mach Chen From maustcr@eircom.net Mon Sep 24 06:02:59 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZkmJ-0006Gz-29 for ccamp-archive@megatron.ietf.org; Mon, 24 Sep 2007 06:02:59 -0400 Received: from [80.227.97.174] (helo=lmxcon) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IZkmD-00024q-GT for ccamp-archive@megatron.ietf.org; Mon, 24 Sep 2007 06:02:55 -0400 Received: (qmail 9394 invoked from network); Mon, 24 Sep 2007 14:02:15 +0400 Received: from unknown (HELO jcc) (136.111.73.186) by lmxcon with SMTP; Mon, 24 Sep 2007 14:02:15 +0400 Message-ID: <001001c7fe91$fbc4cc00$ba496f88@jcc> From: To: Subject: get on this before Opening bell Date: Mon, 24 Sep 2007 14:02:15 +0400 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.4920.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 News Expected Monday From SREA SCORE ONE INC. (SREA . OB) Current: $0.10 Last big release caused a frenzy. Be ready to grab SREA at opening bell Mond. From enog@alfalaval.se Mon Sep 24 06:03:00 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZkmK-0005xu-C6 for ccamp-archive@ietf.org; Mon, 24 Sep 2007 06:03:00 -0400 Received: from [80.227.97.174] (helo=lmxcon) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IZkln-0003wE-Tj for ccamp-archive@ietf.org; Mon, 24 Sep 2007 06:02:28 -0400 Received: (qmail 29008 invoked from network); Mon, 24 Sep 2007 14:02:07 +0400 Received: from unknown (HELO eub) (34.220.154.103) by lmxcon with SMTP; Mon, 24 Sep 2007 14:02:07 +0400 Message-ID: <002e01c7fe91$f7248ff0$679adc22@eub> From: To: Subject: Monday Is Coming! Are You ready? Date: Mon, 24 Sep 2007 14:02:07 +0400 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.4029.2901 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4029.2901 X-Spam-Score: 4.7 (++++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Watch Out For Big News Monday Score One Inc. (SREA . OB) Current: $0.10 Big news means big returns with SREA. Beat the news to the market, grab SREA at open on Monday. From isicnvekm@com-techsoftware.com Mon Sep 24 06:57:10 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZlck-0003NJ-Ar for ccamp-archive@megatron.ietf.org; Mon, 24 Sep 2007 06:57:10 -0400 Received: from [201.122.36.207] (helo=[201.122.36.207]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZlch-0005Fv-FQ for ccamp-archive@megatron.ietf.org; Mon, 24 Sep 2007 06:57:08 -0400 Received: from SECRELACIONES ([186.182.83.23] helo=SECRELACIONES) by [201.122.36.207] ( sendmail 8.13.3/8.13.1) with esmtpa id 1qNHyy-000HZR-SW for ccamp-archive@megatron.ietf.org; Mon, 24 Sep 2007 12:57:22 +0200 Message-ID: <000601c7fe99$a60511f0$cf247ac9@SECRELACIONES> From: "tini isic" To: Subject: alletso Date: Mon, 24 Sep 2007 12:57:07 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C7FEAA.698DE1F0" 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_0009_01C7FEAA.698DE1F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.siadz.com/ Wazzup ccamp-archive This is the website seen on the news and 60 minutes. tini isic ------=_NextPart_000_0009_01C7FEAA.698DE1F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    http://www.siadz.com/
    Wazzup ccamp-archive
    This is the website seen on the news and 60 = minutes.
    tini isic
    ------=_NextPart_000_0009_01C7FEAA.698DE1F0-- From cannon@leesmarket.com Mon Sep 24 07:35:54 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZmED-0007tO-VI for ccamp-archive@ietf.org; Mon, 24 Sep 2007 07:35:54 -0400 Received: from xdsl-177-200.nblnetworks.fi ([217.30.177.200] helo=hima) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZmED-0006Dj-8n for ccamp-archive@ietf.org; Mon, 24 Sep 2007 07:35:53 -0400 Received: from 217.30.177.200 by mail.leesmarket.com; Mon, 24 Sep 2007 14:36:28 +0300 Message-ID: <1CKmE0Ix16oA9LBsGfpSiUubEr@hima> From: "cannon" To: "ccamp-archive" Subject: Speedster To Be Date: Mon, 24 Sep 2007 13:31:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250" 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.2800.1106 X-Spam-Score: 4.3 (++++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 PPYH Represents Apartments In Manhattan Hill Project Co: Phys ical.Pro perty~Holdings-Inc. Sy: P.P-Y-H $0.25 The Manhattan Hill website shows it all, Check out the release. Watch this rocket once investors get this news. Move on PPYH firs thing Mon. Students at Delaware State University,. Medical teams have for the. Rick Ankiel and the St.. From Lilybelle-DOnofrio@mBank.com.pl Mon Sep 24 11:18:04 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZphE-0008HK-7O for ccamp-archive@megatron.ietf.org; Mon, 24 Sep 2007 11:18:04 -0400 Received: from [84.235.6.244] (helo=[87.101.244.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZphC-00041x-Mc for ccamp-archive@megatron.ietf.org; Mon, 24 Sep 2007 11:18:03 -0400 Received: from khalid-nabali by mBank.com.pl with ASMTP id A8ADB485 for ; Mon, 24 Sep 2007 18:20:36 +0300 Received: from khalid-nabali ([145.191.95.161]) by mBank.com.pl with ESMTP id DE88FE131C52 for ; Mon, 24 Sep 2007 18:20:36 +0300 Message-ID: <000501c7febe$5f27be70$a3ad0cd4@khalidnabali> From: "Lilybelle DOnofrio" To: Subject: ekra"nzt Date: Mon, 24 Sep 2007 18:19:59 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7FED7.8474F670" 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: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0007_01C7FED7.8474F670 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable http://tfcal.com/ Compliments ccamp-archive African tribes take these herbs all the time, this is why they have such = big cocks! Lilybelle DOnofrio ------=_NextPart_000_0007_01C7FED7.8474F670 Content-Type: text/html; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable
    http://tfcal.com/
    Compliments ccamp-archive
    African tribes take these herbs all the time, = this is=20 why they have such big cocks!
    Lilybelle DOnofrio
    ------=_NextPart_000_0007_01C7FED7.8474F670-- From siege@atavs.vth.ru Mon Sep 24 11:51:33 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZqDd-0002aH-DD for ccamp-archive@ietf.org; Mon, 24 Sep 2007 11:51:33 -0400 Received: from [66.119.115.34] (helo=34-115-119-66.net-comm.cc) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IZqDW-0003B3-It for ccamp-archive@ietf.org; Mon, 24 Sep 2007 11:51:29 -0400 Received: (qmail 4014 invoked from network); Mon, 24 Sep 2007 11:50:55 -0400 Received: from unknown (HELO yxwxd) (178.128.171.173) by 34-115-119-66.net-comm.cc with SMTP; Mon, 24 Sep 2007 11:50:55 -0400 Message-ID: <46F7DCDF.3050606@atavs.vth.ru> Date: Mon, 24 Sep 2007 11:50:55 -0400 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: Take ten min out to play a game today. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Get over here. It's a gamer's Paradise. All the free games you want. http://70.253.160.96/ From owner-ccamp@ops.ietf.org Mon Sep 24 12:22:37 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZqhh-0001Cc-EI for ccamp-archive@ietf.org; Mon, 24 Sep 2007 12:22:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZqhd-0004fA-Nv for ccamp-archive@ietf.org; Mon, 24 Sep 2007 12:22:37 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IZqWI-000Had-IG for ccamp-data@psg.com; Mon, 24 Sep 2007 16:10:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, STOX_REPLY_TYPE,USER_IN_ALL_SPAM_TO autolearn=no version=3.2.1 Received: from [212.23.3.141] (helo=heisenberg.zen.co.uk) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IZqWD-000HaH-V5 for ccamp@ops.ietf.org; Mon, 24 Sep 2007 16:10:48 +0000 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1IZqVp-0003Mx-Gs for ccamp@ops.ietf.org; Mon, 24 Sep 2007 16:10:21 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Sep 2007 17:10:21 +0100 Message-ID: <031301c7fec5$673e5860$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , , Subject: Deployment of the Internet-Draft Submission Tool Date: Mon, 24 Sep 2007 17:10:11 +0100 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-OriginalArrivalTime: 24 Sep 2007 16:10:21.0174 (UTC) FILETIME=[6817A160:01C7FEC5] X-Originating-Heisenberg-IP: [88.96.235.138] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Hi, Fed up with waiting one or two days for your I-D submissions to be posted? The new tool below seems to work fine. The only things to be aware of are: - It checks for nits - It requires that you include creation and expiry stamps such as Created: September 24, 2007 Expires: March 24, 2008 - If you want to fix the nits yourself, you should cancel the submission and come back later. Cheers, Adrian -----Original Message----- From: IETF Secretariat [mailto:ietf-secretariat@ietf.org] Sent: Wednesday, September 19, 2007 9:32 PM To: IETF Announcement list Cc: wgchairs@ietf.org; iesg@ietf.org Subject: Deployment of the Internet-Draft Submission Tool The IETF Secretariat is pleased to announce the deployment of the Internet-Draft Submission Tool (IDST)-Phase I. The IDST is a Web-based application that will allow an IETF participant to submit an Internet-Draft online, obtain approval to post the draft (if necessary), and make the draft immediately available to the community on the IETF Web site without the assistance of the Secretariat (in most cases). The URL for the IDST is: https://datatracker.ietf.org/idst/upload.cgi The URL for instructions for using the IDST is: http://www.ietf.org/idsubmit_instructions.html Although it will still be possible to submit your drafts by e-mail (i.e., by sending them to internet-drafts@ietf.org), the tool is available for use effective immediately, and we encourage you to submit your drafts via the tool starting today. If you have any questions about using the tool or wish to report a bug, then please send a message to idst-developers@ietf.org. Enjoy!! The IETF Secretariat _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From owner-ccamp@ops.ietf.org Mon Sep 24 13:44:39 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZrz5-0007Lf-2x for ccamp-archive@ietf.org; Mon, 24 Sep 2007 13:44:39 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZrz4-0001Bt-KE for ccamp-archive@ietf.org; Mon, 24 Sep 2007 13:44:38 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IZrpa-000MPq-4j for ccamp-data@psg.com; Mon, 24 Sep 2007 17:34:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [212.23.3.142] (helo=rutherford.zen.co.uk) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IZrpX-000MPd-Pe for ccamp@ops.ietf.org; Mon, 24 Sep 2007 17:34:48 +0000 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1IZrpN-0005LD-E1 for ccamp@ops.ietf.org; Mon, 24 Sep 2007 17:34:37 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Sep 2007 18:34:36 +0100 Message-ID: <038701c7fed1$294bec50$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: New revisions of MPLS/GMPLS I-Ds Date: Mon, 24 Sep 2007 18:33:14 +0100 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-OriginalArrivalTime: 24 Sep 2007 17:34:36.0912 (UTC) FILETIME=[2D8C0700:01C7FED1] X-Originating-Rutherford-IP: [88.96.235.138] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Hi, As part of preparing these documents for IESG review, I have resubmitted them to fix a bunch of IDnits and format issues. No changes of substance. Cheers, Adrian From etienne@faxsav.com Mon Sep 24 13:49:51 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZs47-0003Pl-Hq for ccamp-archive@ietf.org; Mon, 24 Sep 2007 13:49:51 -0400 Received: from 20132187143.user.veloxzone.com.br ([201.32.187.143]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZs46-0001Mj-Oe for ccamp-archive@ietf.org; Mon, 24 Sep 2007 13:49:51 -0400 Received: from [201.32.187.143] by nys2.netmoves.com; Mon, 24 Sep 2007 17:49:37 +0000 Message-ID: <000901c7fed3$05698d1d$2317e5a5@dwagi> From: "curry rivi" To: Subject: Local representatives wanted. Successful international company is looking for talented people. No investment is needed. Date: Mon, 24 Sep 2007 16:02:15 +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.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 1.6 (+) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 From owner-ccamp@ops.ietf.org Mon Sep 24 14:29:05 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZsg5-0007A5-Hs for ccamp-archive@ietf.org; Mon, 24 Sep 2007 14:29:05 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZsg2-0002ZS-Ot for ccamp-archive@ietf.org; Mon, 24 Sep 2007 14:29:03 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IZsXU-000PAd-QT for ccamp-data@psg.com; Mon, 24 Sep 2007 18:20:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-201.9 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO,USER_IN_WHITELIST autolearn=no version=3.2.1 Received: from [156.154.16.158] (helo=ns0.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IZsXR-000PAL-L9 for ccamp@ops.ietf.org; Mon, 24 Sep 2007 18:20:11 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 5D658328BA; Mon, 24 Sep 2007 16:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IZqVW-000571-9R; Mon, 24 Sep 2007 12:10:02 -0400 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-04.txt Message-Id: Date: Mon, 24 Sep 2007 12:10:02 -0400 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) : D. Papadimitriou, et al. Filename : draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04.txt Pages : 20 Date : 2007-09-24 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-04 September 2007 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-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-fmwk-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-fmwk-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-09-24120627.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-09-24120627.I-D\@ietf.org> --OtherAccess-- --NextPart-- From Prosantakindblad@lgi.lg.co.kr Mon Sep 24 15:30:03 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZtd5-0002H2-II for ccamp-archive@ietf.org; Mon, 24 Sep 2007 15:30:03 -0400 Received: from [78.88.221.112] (helo=078088221112.klc.vectranet.pl) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZtcr-00055G-VH for ccamp-archive@ietf.org; Mon, 24 Sep 2007 15:29:50 -0400 Received: from ppp-v6mqmtsd02r by lgi.lg.co.kr with ASMTP id 324C3680 for ; Mon, 24 Sep 2007 21:30:12 +0200 Received: from ppp-v6mqmtsd02r ([136.182.143.35]) by lgi.lg.co.kr with ESMTP id F33944554D89 for ; Mon, 24 Sep 2007 21:30:12 +0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 24 Sep 2007 21:29:36 +0200 To: ccamp-archive@ietf.org From: "Prosanta kindblad" Subject: crisante Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.1 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Good night ccamp-archive my banger is HUGE now thanks to these guys.. Prosanta kindblad http://entradad.com/ From Munsinbxi@lgi.lg.co.kr Mon Sep 24 15:31:11 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZteB-0003Ue-MR for ccamp-archive@megatron.ietf.org; Mon, 24 Sep 2007 15:31:11 -0400 Received: from [78.88.221.112] (helo=078088221112.klc.vectranet.pl) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZte6-00057T-J6 for ccamp-archive@megatron.ietf.org; Mon, 24 Sep 2007 15:31:07 -0400 Received: by 10.20.101.150 with SMTP id mGmOsUhwZcGYG; Mon, 24 Sep 2007 21:30:57 +0200 (GMT) Received: by 192.168.115.110 with SMTP id kGXxdLnxjfMIJB.7123102404068; Mon, 24 Sep 2007 21:30:55 +0200 (GMT) Message-ID: <000501c7fee1$6b842eb0$70dd584e@pppv6mqmtsd02r> From: "luther Munsin" To: Subject: crumbabl Date: Mon, 24 Sep 2007 21:30:52 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7FEF2.2F0CFEB0" 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.1 (++++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0003_01C7FEF2.2F0CFEB0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable http://www.envyef.com/ Yo yo yo ccamp-archive RESULTS NOW GUARANTEED: ENLARGE YOUR PENIS luther Munsin ------=_NextPart_000_0003_01C7FEF2.2F0CFEB0 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
    http://www.envyef.com/
    Yo yo yo ccamp-archive
    RESULTS NOW GUARANTEED: ENLARGE YOUR = PENIS
    luther Munsin
    ------=_NextPart_000_0003_01C7FEF2.2F0CFEB0-- From kbates44@power-sonic.com Mon Sep 24 15:45:37 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZts9-0004pu-Fm for ccamp-archive@ietf.org; Mon, 24 Sep 2007 15:45:37 -0400 Received: from [216.153.43.38] (helo=host38-69-153-216.isdn.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IZts4-0005PW-05 for ccamp-archive@ietf.org; Mon, 24 Sep 2007 15:45:32 -0400 Received: from [34.34.185.235] (helo=bqpn) by host38-69-153-216.isdn.net with smtp (Exim 4.62 (FreeBSD)) id 1Jgu0-0004Nw-8g; Mon, 24 Sep 2007 14:47:47 -0500 Message-ID: <46F813C3.5080201@power-sonic.com> Date: Mon, 24 Sep 2007 14:45:07 -0500 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: Read this before Monday Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.9 (+++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Monday Will Be Huge! SCORE ONE INC (SREA . OB) Price: $0.10 SREA had huge returns for investors after the last big news. Monday is the day to grab SREA. From owner-ccamp@ops.ietf.org Mon Sep 24 16:25:58 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZuVC-0005LD-9m for ccamp-archive@ietf.org; Mon, 24 Sep 2007 16:25:58 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZuUx-0004bE-Rd for ccamp-archive@ietf.org; Mon, 24 Sep 2007 16:25:58 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IZuKh-0005wT-BJ for ccamp-data@psg.com; Mon, 24 Sep 2007 20:15:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-201.9 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO,USER_IN_WHITELIST autolearn=no version=3.2.1 Received: from [156.154.24.139] (helo=ns4.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IZuKd-0005vI-PZ for ccamp@ops.ietf.org; Mon, 24 Sep 2007 20:15:05 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 4F3A32AC7E; Mon, 24 Sep 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IZuKb-0004lJ-K6; Mon, 24 Sep 2007 16:15:01 -0400 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-inter-domain-rsvp-te-07.txt Message-Id: Date: Mon, 24 Sep 2007 16:15:01 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 --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 : Inter domain Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering - RSVP-TE extensions Author(s) : A. Ayyangar, et al. Filename : draft-ietf-ccamp-inter-domain-rsvp-te-07.txt Pages : 22 Date : 2007-9-24 This document describes procedures and protocol extensions for the use of Resource ReserVation Protocol Traffic Engineering (RSVP-TE) signaling in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and non-packet networks to support the establishment and maintenance of Label Switched Paths that cross domain boundaries. For the purpose of this document, a domain is considered to be any collection of network elements within a common realm of address space or path computation responsibility. Examples of such domains include Autonomous Systems, IGP routing areas, and GMPLS overlay networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-te-07.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-inter-domain-rsvp-te-07.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-inter-domain-rsvp-te-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-9-24154647.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-te-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-inter-domain-rsvp-te-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-9-24154647.I-D@ietf.org> --OtherAccess-- --NextPart-- From Aryoh@ggoldstein.com.do Mon Sep 24 18:11:04 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZw8u-0005CF-5l for ccamp-archive@ietf.org; Mon, 24 Sep 2007 18:11:04 -0400 Received: from host44-51-dynamic.11-87-r.retail.telecomitalia.it ([87.11.51.44]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZw8p-0000mY-61 for ccamp-archive@ietf.org; Mon, 24 Sep 2007 18:10:59 -0400 Received: by 10.82.181.121 with SMTP id jXpXYyptiupeT; Tue, 25 Sep 2007 00:11:27 +0200 (GMT) Received: by 192.168.11.196 with SMTP id zPmLdOaDffopoU.2873136320123; Tue, 25 Sep 2007 00:11:25 +0200 (GMT) Message-ID: <000801c7fef7$d7339e50$2c330b57@nome682a4b16a4> From: "Aryo h" To: Subject: selaohs Date: Tue, 25 Sep 2007 00:11:22 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7FF08.9ABC6E50" 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_0007_01C7FF08.9ABC6E50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://envyef.com/ Hi ccamp-archive now im 2 inch bigger in my manhood.. i have all the confidence. Aryo h ------=_NextPart_000_0007_01C7FF08.9ABC6E50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    http://envyef.com/
    Hi ccamp-archive
    now im 2 inch bigger in my manhood.. i have = all the confidence.
    Aryo h
    ------=_NextPart_000_0007_01C7FF08.9ABC6E50-- From babuls@aonecomputers.com Mon Sep 24 18:29:27 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZwQh-0000jt-HI; Mon, 24 Sep 2007 18:29:27 -0400 Received: from [190.182.55.201] (helo=[190.182.55.201]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZwQF-00014V-Ha; Mon, 24 Sep 2007 18:29:00 -0400 Received: from [190.182.55.201] by aonecomputers.com.mail3.psmtp.com; Mon, 24 Sep 2007 17:29:01 -0500 Message-ID: <01c7fefa$4e512b90$c937b6be@babuls> From: "Cassandra Carr" To: Subject: Big trade day, shares up 120 percent Date: Mon, 24 Sep 2007 17:29:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.1 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de P*P.Y,H UP 120%, Investors Go Nuts! Physical Property Holdings Inc. P~P.Y~H $0.55 UP 120% New focus in market is making a big difference to investors. Prices rocketed up an amazing 120 percent by close today. Set your buy for first thing in the morning. This one is gonna rock. From owner-ccamp@ops.ietf.org Mon Sep 24 22:01:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZzk7-0007U7-Qe for ccamp-archive@ietf.org; Mon, 24 Sep 2007 22:01:43 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZzk1-0005aD-KQ for ccamp-archive@ietf.org; Mon, 24 Sep 2007 22:01:43 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IZzZ1-0002ak-Gn for ccamp-data@psg.com; Tue, 25 Sep 2007 01:50:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-201.9 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO,USER_IN_WHITELIST autolearn=no version=3.2.1 Received: from [156.154.24.138] (helo=ns3.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IZzYy-0002aV-G2 for ccamp@ops.ietf.org; Tue, 25 Sep 2007 01:50:13 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id C14D6175C8; Mon, 24 Sep 2007 16:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IZr8D-0005W2-Ml; Mon, 24 Sep 2007 12:50:01 -0400 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-02.txt Message-Id: Date: Mon, 24 Sep 2007 12:50:01 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 --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-02.txt Pages : 13 Date : 2007-09-24 Operation of an 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 (ships in the night). 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. K.Kumaki et al. [page 1] draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02 September 2007 This document describes a framework and Service Provider requirements for operating MPLS-TE networks over GMPLS networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02.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-02.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-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-09-24124412.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-09-24124412.I-D\@ietf.org> --OtherAccess-- --NextPart-- From kakogawa29gupi@HOTPOP.COM Mon Sep 24 23:52:09 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia1Sz-0000hc-LW for ccamp-archive@ietf.org; Mon, 24 Sep 2007 23:52:09 -0400 Received: from pool-71-251-14-29.nycmny.fios.verizon.net ([71.251.14.29]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ia1Sz-0001Go-3q for ccamp-archive@ietf.org; Mon, 24 Sep 2007 23:52:09 -0400 Received: from [71.251.14.29] by ghsewngt.HOTPOP.COM; Tue, 25 Sep 2007 03:53:03 +0000 Message-ID: <000601c7ff27$050dd6d9$4331eab3@hsewngt> From: "Celia Montano" To: "Reyes Painter" Subject: Fw: Thank you, we accepted your loan request Date: Tue, 25 Sep 2007 02:05:40 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7FF27.05098002" 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: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C7FF27.05098002 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you have your own business and need 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 the deal we can offer = you THIS EVENING (hurry, this deal will expire TONIGHT):   $66,000+ loan   Hurry, when the deal is gone, it is gone. Simply Call Us Free on=20 877-292-6892 ------=_NextPart_000_0003_01C7FF27.05098002 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    If you have your own business and need = 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 the deal we can offer you THIS EVENING (hurry, this = deal will expire TONIGHT):
    =20
     
    $66,000+ loan
     
    Hurry, when the deal is gone, it is = gone. Simply Call Us Free on 877-292-6892
    ------=_NextPart_000_0003_01C7FF27.05098002-- From maceo70chriss@apollo.lv Mon Sep 24 23:52:38 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia1TS-0000q2-0d for ccamp-archive@ietf.org; Mon, 24 Sep 2007 23:52:38 -0400 Received: from host-162-146.hosts.vtc.ru ([82.194.162.146]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ia1TM-0001HB-TJ for ccamp-archive@ietf.org; Mon, 24 Sep 2007 23:52:33 -0400 Received: from [82.194.162.146] by hfbdq.apollo.lv; Tue, 25 Sep 2007 03:50:38 +0000 Message-ID: <000901c7ff27$0190def4$35688b9b@bdqrue> From: "Susanne Esposito" To: "Deloris Potts" Subject: Thank you, we are ready to lend money Date: Tue, 25 Sep 2007 02:03:16 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C7FF27.018B8902" 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: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C7FF27.018B8902 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you have your own business and wish IMMEDIATE money to spend ANY way = you like or need Extra money to give your business a boost or want A low = interest loan - NO STRINGS ATTACHED, here is the deal we can offer you = TONIGHT (hurry, this deal will expire TODAY):   $64,000+ loan   Hurry, when our best deal is gone, it is gone. Simply Call Us Free on=20 877-292-6892 ------=_NextPart_000_0006_01C7FF27.018B8902 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    If you have your own business and wish = IMMEDIATE money to spend ANY way you like or need Extra money to give = your business a boost or want A low interest loan - NO STRINGS ATTACHED, = here is the deal we can offer you TONIGHT (hurry, this deal will expire = TODAY):
    =20
     
    $64,000+ loan
     
    Hurry, when our best deal is gone, it = is gone. Simply Call Us Free on 877-292-6892
    ------=_NextPart_000_0006_01C7FF27.018B8902-- From wheyalayne89@brasilmails.com Mon Sep 24 23:53:14 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia1U2-0001UU-G1 for ccamp-archive@ietf.org; Mon, 24 Sep 2007 23:53:14 -0400 Received: from [211.63.53.104] (helo=211.63.53.104) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ia1Tv-0007YL-57 for ccamp-archive@ietf.org; Mon, 24 Sep 2007 23:53:09 -0400 Received: from [211.63.53.104] by hpxg.brasilmails.com; Tue, 25 Sep 2007 03:53:23 +0000 Message-ID: <000601c7ff27$05bb7aab$766b0991@hpxgiled> From: "Jennifer Lyon" To: "Mara Dixon" Subject: Re: Thank you, we are ready to lend some cash Date: Tue, 25 Sep 2007 02:06:01 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7FF27.05B8521F" 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.9 (++++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C7FF27.05B8521F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you have your own business and want IMMEDIATE cash to spend ANY way = you like or wish Extra money to give your business a boost or wish A low = interest loan - NO STRINGS ATTACHED, here is best deal we can offer you = THIS NIGHT (hurry, this deal will expire NOW):   $54,000+ loan   Hurry, when the deal is gone, it is gone. Simply Call Us Free on=20 877-292-6892 ------=_NextPart_000_0003_01C7FF27.05B8521F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    If you have your own business and want = IMMEDIATE cash to spend ANY way you like or wish Extra money to give = your business a boost or wish A low interest loan - NO STRINGS ATTACHED, = here is best deal we can offer you THIS NIGHT (hurry, this deal will = expire NOW):
    =20
     
    $54,000+ loan
     
    Hurry, when the deal is gone, it is = gone. Simply Call Us Free on 877-292-6892
    ------=_NextPart_000_0003_01C7FF27.05B8521F-- From ufuks@difrecalcine.cl Tue Sep 25 04:14:34 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia5Yv-0002Na-Ur for ccamp-archive@ietf.org; Tue, 25 Sep 2007 04:14:33 -0400 Received: from [59.93.183.38] (helo=dhbtug) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ia5Yp-00059y-N0 for ccamp-archive@ietf.org; Tue, 25 Sep 2007 04:14:29 -0400 Received: from vpczo ([118.187.158.59]) by dhbtug with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 13:53:16 +0530 Message-ID: <000901c7ff4d$52bbea00$3b9ebb76@vpczo> From: To: Subject: More games than you can imagine. FREE Date: Tue, 25 Sep 2007 13:53:16 +0530 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 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1158 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 GAMES GAMES GAMES, All you want, and there free. http://75.3.0.145/ From Hickox@rheinkassel-langel.de Tue Sep 25 05:08:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia6PV-00041Z-DO for ccamp-archive@megatron.ietf.org; Tue, 25 Sep 2007 05:08:53 -0400 Received: from pool-71-252-164-38.dllstx.fios.verizon.net ([71.252.164.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ia6PP-0007AG-5q for ccamp-archive@megatron.ietf.org; Tue, 25 Sep 2007 05:08:53 -0400 Received: from home ([121.163.125.126] helo=home) by pool-71-252-164-38.dllstx.fios.verizon.net ( sendmail 8.13.3/8.13.1) with esmtpa id 1ifYyB-000TZQ-nw for ccamp-archive@megatron.ietf.org; Tue, 25 Sep 2007 04:11:13 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 25 Sep 2007 04:10:47 -0500 To: ccamp-archive@megatron.ietf.org From: "Nhut Hickox" Subject: kskytti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 4.6 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Good evening ccamp-archive life is too short to be small Nhut Hickox http://www.eregrine.com/ From owner-ccamp@ops.ietf.org Tue Sep 25 05:15:16 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia6Vg-0001wP-3k for ccamp-archive@ietf.org; Tue, 25 Sep 2007 05:15:16 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ia6Ve-0007Kz-Pk for ccamp-archive@ietf.org; Tue, 25 Sep 2007 05:15:16 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Ia6N7-0008PF-Lv for ccamp-data@psg.com; Tue, 25 Sep 2007 09:06:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.1 Received: from [212.23.3.27] (helo=doppler.zen.co.uk) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Ia6Ml-0008ML-1K for ccamp@ops.ietf.org; Tue, 25 Sep 2007 09:06:08 +0000 Received: from [212.23.3.141] (helo=heisenberg.zen.co.uk) by doppler.zen.co.uk with esmtp (Exim 4.50) id 1Ia6Mk-0002Fz-Cv for ccamp@ops.ietf.org; Tue, 25 Sep 2007 09:06:02 +0000 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1Ia6Mj-0001c6-Bj for ccamp@ops.ietf.org; Tue, 25 Sep 2007 09:06:01 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Sep 2007 10:06:00 +0100 Message-ID: <041501c7ff53$47282450$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Ross Callon" Cc: , "Brungard, Deborah A, ALABS" , , "WG Milestone Tracker" Subject: Please publish draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02.txt Date: Tue, 25 Sep 2007 10:03:02 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_040E_01C7FF5B.429BC4C0" 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-OriginalArrivalTime: 25 Sep 2007 09:06:00.0592 (UTC) FILETIME=[4AD0E100:01C7FF53] X-Originating-Heisenberg-IP: [88.96.235.138] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 This is a multi-part message in MIME format. ------=_NextPart_000_040E_01C7FF5B.429BC4C0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi Ross, Please take draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02.txt through the IESG process for publication as an Informational RFC. The proto-shepherd-write-up (TM) is attached. Cheers, Adrian ------=_NextPart_000_040E_01C7FF5B.429BC4C0 Content-Type: text/plain; format=flowed; name="draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02-write-up.txt"; reply-type=original Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02-write-up.txt" Proto-write-up for draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02 Suggest that this I-D is progressed in parallel with draft-ietf-ccamp-mpls-gmpls-interwork-fmwk > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? Adrian Farrel is the document shepherd. He has personally reviewed the I-D and believes it is ready for forwarding to the IESG for publication. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? This is a fairly old document. In its early days it had substantial review and discussion. More recently the level of input has tailed off probably because the draft was largely technically complete. The last few revisions of the I-D have been largely editorial working to improve the readability and presentaiton. Although the I-D has had no explicit review from the MPLS working group most of the people concerned with the operation of MPLS-TE networks over GMPLS networks are participants in CCAMP. > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? No concerns. > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. The document is sound. The document filename is easily confused with draft-ietf-ccamp-mpls-gmpls-interwork-fmwk that is also going to the IESG for publication at this time. But the document titles are sufficiently different to avoid confusion. > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? The working group has indicated is understanding and support for the requirements expressed in this I-D. The solution model described has not drawn any unfavorable comments. > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) No threats. No discontent. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? All checks made. > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. References split. No downrefs. > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC2434]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? This is an Informational I-D. A null IANA section is present. > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? No such sections. > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up? Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: > > Technical Summary > Relevant content can frequently be found in the abstract > and/or introduction of the document. If not, this may be > an indication that there are deficiencies in the abstract > or introduction. 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 (ships in the night). 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. An 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. > Working Group Summary > Was there anything in WG process that is worth noting? For > example, was there controversy about particular points or > were there decisions where the consensus was particularly > rough? Nothing of note. > Document Quality > Are there existing implementations of the protocol? Have a > significant number of vendors indicated their plan to > implement the specification? Are there any reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? If > there was a MIB Doctor, Media Type or other expert review, > what was its course (briefly)? In the case of a Media Type > review, on what date was the request posted? This is an Informational I-D with no protocol specifications. The authors list demonstrates interest from providers in this mode of network operation. Much of the material in this document was based on draft-kumaki-ccamp- mpls-gmpls-interworking-01.txt that had input from Cisco Systems. Several vendors are believed to implement MPLS-TE over GMPLS in this way and GMPLS interoperablity events are usually achieved using this model. ------=_NextPart_000_040E_01C7FF5B.429BC4C0-- From owner-ccamp@ops.ietf.org Tue Sep 25 05:17:06 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia6XR-0004MT-Ue for ccamp-archive@ietf.org; Tue, 25 Sep 2007 05:17:05 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ia6XR-0001Ol-1e for ccamp-archive@ietf.org; Tue, 25 Sep 2007 05:17:05 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Ia6Mq-0008Mz-MJ for ccamp-data@psg.com; Tue, 25 Sep 2007 09:06:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [212.23.3.27] (helo=doppler.zen.co.uk) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Ia6Mj-0008L2-2x for ccamp@ops.ietf.org; Tue, 25 Sep 2007 09:06:06 +0000 Received: from [212.23.3.142] (helo=rutherford.zen.co.uk) by doppler.zen.co.uk with esmtp (Exim 4.50) id 1Ia6Mg-0002C1-9E for ccamp@ops.ietf.org; Tue, 25 Sep 2007 09:05:58 +0000 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1Ia6Mf-0006Lp-1A for ccamp@ops.ietf.org; Tue, 25 Sep 2007 09:05:57 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Sep 2007 10:05:56 +0100 Message-ID: <041101c7ff53$45fbb240$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Brungard, Deborah A, ALABS" , "'Jean Philippe Vasseur'" , "Jean-Louis Le Roux" References: Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-07.txt Date: Tue, 25 Sep 2007 09:55:21 +0100 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-OriginalArrivalTime: 25 Sep 2007 09:05:56.0655 (UTC) FILETIME=[487823F0:01C7FF53] X-Originating-Rutherford-IP: [88.96.235.138] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Hi, This new revision addresses two IESG DISCUSSes. The first, from Sam Hartman, gives rise to a new paragraph (the first paragraph in section 8) to point out certain security concerns with RSVP-TE. The second, from Russ Housley, introduces the GenArt review by Eric Gray and gives rise to a good number of editorial changes. Nearly all of these are of no technical substance comprising the addition of text for clarification (especially where the old text said "SHOULD" and there was no description of why or how an implementation might vary from the SHOULD). In section 3.1 there is, however, a set of changes that, while they don't change the intent of the authors, do make practical changes to the interpretation of the protocol procedures - essentially, we have changed some of the RFC 2119 language. In my opinion, these changes don't warrant a further working group last call, although I would encourage interested parties to read carefully. However, on this I-D I need to recuse myself from the decision process and hand over to Deborah. Thanks, Adrian ----- Original Message ----- From: To: Cc: Sent: Monday, September 24, 2007 9:15 PM Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-07.txt >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Common Control and Measurement Plane > Working Group of the IETF. > > Title : Inter domain Multiprotocol Label Switching (MPLS) and Generalized > MPLS (GMPLS) Traffic Engineering - RSVP-TE extensions > Author(s) : A. Ayyangar, et al. > Filename : draft-ietf-ccamp-inter-domain-rsvp-te-07.txt > Pages : 22 > Date : 2007-9-24 > > This document describes procedures and protocol extensions for the > use of Resource ReserVation Protocol Traffic Engineering (RSVP-TE) > signaling in Multiprotocol Label Switching Traffic Engineering > (MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and > non-packet networks to support the establishment and maintenance of > Label Switched Paths that cross domain boundaries. > > For the purpose of this document, a domain is considered to be any > collection of network elements within a common realm of address space > or path computation responsibility. Examples of such domains include > Autonomous Systems, IGP routing areas, and GMPLS overlay networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-te-07.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-inter-domain-rsvp-te-07.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-inter-domain-rsvp-te-07.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. > From owner-ccamp@ops.ietf.org Tue Sep 25 05:17:25 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia6Xl-0005BZ-06 for ccamp-archive@ietf.org; Tue, 25 Sep 2007 05:17:25 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ia6Xk-0001Pe-0h for ccamp-archive@ietf.org; Tue, 25 Sep 2007 05:17:24 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Ia6Mz-0008Og-FV for ccamp-data@psg.com; Tue, 25 Sep 2007 09:06:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.1 Received: from [212.23.3.27] (helo=doppler.zen.co.uk) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Ia6Ml-0008MK-0r for ccamp@ops.ietf.org; Tue, 25 Sep 2007 09:06:07 +0000 Received: from [212.23.3.141] (helo=heisenberg.zen.co.uk) by doppler.zen.co.uk with esmtp (Exim 4.50) id 1Ia6Mk-0002Fw-Cn for ccamp@ops.ietf.org; Tue, 25 Sep 2007 09:06:02 +0000 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1Ia6Mh-0001c6-Hl for ccamp@ops.ietf.org; Tue, 25 Sep 2007 09:06:01 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Sep 2007 10:05:59 +0100 Message-ID: <041401c7ff53$46cd8130$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Ross Callon" Cc: , "Brungard, Deborah A, ALABS" , , "WG Milestone Tracker" Subject: Please publish draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04 Date: Tue, 25 Sep 2007 10:01:42 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0408_01C7FF5B.1288A3C0" 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-OriginalArrivalTime: 25 Sep 2007 09:05:59.0217 (UTC) FILETIME=[49FF1210:01C7FF53] X-Originating-Heisenberg-IP: [88.96.235.138] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 This is a multi-part message in MIME format. ------=_NextPart_000_0408_01C7FF5B.1288A3C0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi Ross, Please take draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04.txt through the IESG process for publication as an Informational RFC. The proto-shepherd-write-up (TM) is attached. Cheers, Adrian ------=_NextPart_000_0408_01C7FF5B.1288A3C0 Content-Type: text/plain; format=flowed; name="draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04-write-up.txt"; reply-type=original Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04-write-up.txt" Proto-write-up for draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04 Suggest that this I-D is progressed in parallel with draft-ietf-ccamp-mpls-gmpls-interwork-reqts > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? Adrian Farrel is the document shepherd. He has personally reviewed the I-D and believes it is ready for forwarding to the IESG for publication. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? This is a fairly old document. In its early days it had substantial review and discussion. More recently the level of input has tailed off probably because the draft was largely complete. Although the I-D has had no explicit review from the MPLS working group most of the people concerned with the migration of MPLS-TE to GMPLS are participants in CCAMP. > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? No concerns. > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. The document is sound. The document filename is easily confused with draft-ietf-ccamp-mpls-gmpls-interwork-reqts that is also going to the IESG for publication at this time. But the document titles are sufficiently different to avoid confusion. > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? The working group has indicated is understanding and support for the requirements expressed in this I-D. The solution models described have not drawn any unfavorable comments except as noted in the I-D. > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) No threats. No discontent. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? All checks made. > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. References split. No downrefs. > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC2434]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? This is an Informational I-D. A null IANA section is present. > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? No such sections. > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up? Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: > > Technical Summary > Relevant content can frequently be found in the abstract > and/or introduction of the document. If not, this may be > an indication that there are deficiencies in the abstract > or introduction. 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. > Working Group Summary > Was there anything in WG process that is worth noting? For > example, was there controversy about particular points or > were there decisions where the consensus was particularly > rough? Nothing of note. > Document Quality > Are there existing implementations of the protocol? Have a > significant number of vendors indicated their plan to > implement the specification? Are there any reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? If > there was a MIB Doctor, Media Type or other expert review, > what was its course (briefly)? In the case of a Media Type > review, on what date was the request posted? This is an Informational I-D with no protocol specifications. The authors list demonstrates considerable interest from providers in preparing for migration from MPLS-TE to GMPLS. Early versions of this document were founded on significant discussions with Kireeti Kompella resulting in considerable simplification of the ideas put forward. The final versions of this document received detailed review from Adrian Farrel resulting in many small changes. ------=_NextPart_000_0408_01C7FF5B.1288A3C0-- From eply@realitygroup.com Tue Sep 25 08:46:06 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia9ni-0008FT-DV for ccamp-archive@ietf.org; Tue, 25 Sep 2007 08:46:06 -0400 Received: from [41.204.225.141] (helo=oklz) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ia9nR-0006qM-TW for ccamp-archive@ietf.org; Tue, 25 Sep 2007 08:45:50 -0400 Received: from ckokx ([188.120.236.40]) by oklz (8.13.1/8.13.1) with SMTP id l9PCqhHX032813; Thu, 25 Oct 2007 14:52:43 +0200 Message-ID: <472090A1.2060507@realitygroup.com> Date: Thu, 25 Oct 2007 14:48:33 +0200 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: Trader Report Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.2 (++++) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 SREA Is Going To Expo And Investors Are Going To The Bank! SCORE ONE INC (S R E A . O B) Current Price: $0.155 SREA premiering at Nov Expo for international exposure. Investors are moving on SREA following news release, pushing shares up 50%. Move one SREA first thing Tuesday. From somubiochem@gsicommerce.com Tue Sep 25 08:47:06 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia9og-0002hN-A6 for ccamp-archive@megatron.ietf.org; Tue, 25 Sep 2007 08:47:06 -0400 Received: from [41.204.225.141] (helo=oklz) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ia9oX-0004J7-9C for ccamp-archive@megatron.ietf.org; Tue, 25 Sep 2007 08:46:59 -0400 Received: from lwg ([137.156.67.207]) by oklz (8.13.4/8.13.4) with SMTP id l9PCrIjD032813; Thu, 25 Oct 2007 14:53:18 +0200 Message-ID: <472090AF.7060304@gsicommerce.com> Date: Thu, 25 Oct 2007 14:48:47 +0200 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ccamp-archive@megatron.ietf.org Subject: Trader Alert Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Investors Enjoy 50% Increase On SREA. Score One (SREA) Price: $0.155 SREA announces their premier at the Chinas Largest International Auto Expo. Investors love this release as shares rocket UP 50% already. Get in fast and grab SREA at opening bell Tues. From owner-ccamp@ops.ietf.org Tue Sep 25 09:21:33 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaAM1-0006IT-RA for ccamp-archive@ietf.org; Tue, 25 Sep 2007 09:21:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaALt-000595-DU for ccamp-archive@ietf.org; Tue, 25 Sep 2007 09:21:31 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IaA8D-0005Xx-Q3 for ccamp-data@psg.com; Tue, 25 Sep 2007 13:07:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-101.8 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, MIME_QP_LONG_LINE,RDNS_NONE,USER_IN_ALL_SPAM_TO autolearn=no version=3.2.1 Received: from [155.53.12.9] (helo=prattle.redback.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IaA8A-0005XS-Lo for ccamp@ops.ietf.org; Tue, 25 Sep 2007 13:07:16 +0000 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 5023726E65; Tue, 25 Sep 2007 06:07:14 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06171-06; Tue, 25 Sep 2007 06:07:14 -0700 (PDT) Received: from [jR??O??IPv6???1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 6F6D426E60; Tue, 25 Sep 2007 06:07:13 -0700 (PDT) In-Reply-To: <028601c7ff4d$6d677590$4f0c6f0a@china.huawei.com> References: <028601c7ff4d$6d677590$4f0c6f0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/alternative; boundary=Apple-Mail-53--182531231 Message-Id: Cc: OSPF List , Vishwas Manral , Alan Davey , CCAMP List From: Acee Lindem Subject: Re: [OSPF] Fwd: Posting of draft-ietf-ospf-ospfv3-traffic-09.txt Date: Tue, 25 Sep 2007 09:05:49 -0400 To: Mach Chen X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new at redback.com Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.2 (--) X-Scan-Signature: ed68cc91cc637fea89623888898579ba --Apple-Mail-53--182531231 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Hi Mach, Thanks for reviewing. On Sep 25, 2007, at 4:24 AM, Mach Chen wrote: > Hi Acee and other authors, > > > > Some questions to ospfv3-traffic > > > > 1. In this ospfv3-traffic document, a new LSA, Intra-Area-TE =20 > LSA, is defined to advertise IPv6 TE information. =46rom name of this =20= > new LSA, IMHO, it is limited to be used for Intra-Area TE only. So, =20= > if there are some underlying extensions to ospfv3-traffic, e.g. =20 > Inter-AS TE, it is a little bit strange to re-use the Intra-Area-TE =20= > LSA, or it has to define a new LSA. So, can we change its name to =20 > something like =93OSPFv3 TE LSA=94? It would be if we had intended it to carry AS wide information. =20 However, it was not initially intended for this. The initial thought =20 was that we would do a better job for OSPFv3 and define separate LSA =20 types for intra-area, inter-area, and AS external TE LSAs. Thoughts =20 on this (copied ccamp as well)? I guess, IMHO, this discrepancy =20 exposes the choice of a new link type for inter-AS connectivity as a =20 bit of a hack. > > > 2. Section 2. > > =93The format of the TLVs within the body of a router information LSA =20= > is the same as the format used by the Traffic Engineering =20 > Extensions to OSPF [TE].=94 > > > > What=92s =93a router information LSA=94? Or should it be =93an = Intra-Area-=20 > TE LSA=94 ? Yes. Good catch. I'll fix this. Thanks, Acee --Apple-Mail-53--182531231 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 Hi Mach,=A0
    Thanks for = reviewing.=A0

    On Sep 25, 2007, at 4:24 AM, Mach = Chen wrote:

    Hi Acee and other authors,=A0

    Some questions to ospfv3-traffic=A0

    1.=A0=A0=A0=A0=A0= =A0



    =A0

    2.=A0=A0=A0=A0=A0= =A0

    =93The format of the TLVs within the body of = a router = information LSA is the same as the format = used by the Traffic Engineering Extensions to OSPF [TE].=94=A0=A0

    What=92s =93a router information LSA=94?=A0 Or = should it be =93an Intra-Area-TE LSA=94 = ?

    <= /BLOCKQUOTE>

    Yes. = Good catch. I'll fix this.=A0

    Thanks,
    Acee
    <= DIV>

    In-Reply-To: <041101c7ff53$45fbb240$0200a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-07.txt Thread-Index: Acf/U08EODVTrmqEReyl7biQI8t9VAALh3SA References: <041101c7ff53$45fbb240$0200a8c0@your029b8cecfe> From: "BRUNGARD, DEBORAH A, ATTLABS" To: "Adrian Farrel" , Cc: "Jean Philippe Vasseur" , "Jean-Louis Le Roux" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Agree, I don't think another WG Last Call is necessary. As Adrian notes, interested parties should review the updated document. Thanks for all the editing- Deborah=20 -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Tuesday, September 25, 2007 4:55 AM To: ccamp@ops.ietf.org Cc: BRUNGARD, DEBORAH A, ATTLABS; 'Jean Philippe Vasseur'; Jean-Louis Le Roux Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-07.txt=20 Hi, This new revision addresses two IESG DISCUSSes. The first, from Sam Hartman, gives rise to a new paragraph (the first=20 paragraph in section 8) to point out certain security concerns with RSVP-TE. The second, from Russ Housley, introduces the GenArt review by Eric Gray and=20 gives rise to a good number of editorial changes. Nearly all of these are of=20 no technical substance comprising the addition of text for clarification (especially where the old text said "SHOULD" and there was no description of=20 why or how an implementation might vary from the SHOULD). In section 3.1 there is, however, a set of changes that, while they don't change the intent=20 of the authors, do make practical changes to the interpretation of the=20 protocol procedures - essentially, we have changed some of the RFC 2119=20 language. In my opinion, these changes don't warrant a further working group last=20 call, although I would encourage interested parties to read carefully.=20 However, on this I-D I need to recuse myself from the decision process and=20 hand over to Deborah. Thanks, Adrian ----- Original Message -----=20 From: To: Cc: Sent: Monday, September 24, 2007 9:15 PM Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-07.txt >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Common Control and Measurement Plane=20 > Working Group of the IETF. > > Title : Inter domain Multiprotocol Label Switching (MPLS) and Generalized=20 > MPLS (GMPLS) Traffic Engineering - RSVP-TE extensions > Author(s) : A. Ayyangar, et al. > Filename : draft-ietf-ccamp-inter-domain-rsvp-te-07.txt > Pages : 22 > Date : 2007-9-24 > > This document describes procedures and protocol extensions for the > use of Resource ReserVation Protocol Traffic Engineering (RSVP-TE) > signaling in Multiprotocol Label Switching Traffic Engineering > (MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and > non-packet networks to support the establishment and maintenance of > Label Switched Paths that cross domain boundaries. > > For the purpose of this document, a domain is considered to be any > collection of network elements within a common realm of address space > or path computation responsibility. Examples of such domains include > Autonomous Systems, IGP routing areas, and GMPLS overlay networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-t e-07.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-inter-domain-rsvp-te-07.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-inter-domain-rsvp-te-07.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. >=20 From dismas@ppmusic.com Tue Sep 25 11:38:43 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaCUl-00070T-9D for ccamp-archive@ietf.org; Tue, 25 Sep 2007 11:38:43 -0400 Received: from fibhost-175-161.fibernet.bacs-net.hu ([85.66.175.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaCUk-0002xb-G1 for ccamp-archive@ietf.org; Tue, 25 Sep 2007 11:38:43 -0400 Received: from [85.66.175.161] by ns2.lax.propagation.net; Tue, 25 Sep 2007 15:38:02 +0000 Message-ID: <000701c7ff8a$0460e405$e0590d86@ydeapi> From: "frasco gilmore" To: Subject: Serious business in a sphere of financial services. No investment reqired. Date: Tue, 25 Sep 2007 13:50:40 +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.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 0.3 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Currently, the gate length, the characteristic length parameter in transistors, has hit about 90 nm. The shorter the gate length, the faster transistors can switch on and off. In fact, the transistors have gotten so fast, that the delay as electrons flow through the skinnier and longer wires needed to cross larger, complex chips is on track to become the limiting factora in speed. This delay is just one of the fundamental problems that threatens to make the nanoscale regime of electronics unfaithful to Moore's Law and demands the design of new materials and structures or a complete shift in chip architecture. Big international commercial organization is looking for talented, honest, reliable representatives from different regions. The ideal candidate will be an intelligent person, someone who can work autonomously with a high degree of enthusiasm. We are looking for highly motivated professionals, with experience in marketing field. The position is home-based. We offer a part-time position with flexible working hours. And we would be happy to consider a full-time job share candidate. Our Company offers a very competitive salary to the successful candidate, along with an unrivalled career progression opportunity. If you think you have what it takes to take on this challenge and would like to apply please send the following information to: BonitaStaffordLM@gmail.com 1) Full name 2) Contact phone numbers 3) Part time job/Full time You do not need to invest any sum of money and we do not ask you to provide us with your bank account requisites! We are engaged in completely legal activity. The preference is given to employees with knowledge of foreign languages. Thank you and we are looking forward to cooperate in long term base with you. If you received this message in error, or would like to unsubscribe, please send a blank email to: NoraChurchEI@gmail.com 18 Stanford Scientific Review successfully demonstrated their use as highly sensitive toxic gas sensors, and with Professor Calvin Quate (Electrical Engineering), has commercialized nanotubes as scanning probe tips to increase probe resolution and tip durability. An area that Dai has just begun exploring is the drug delivery potential of carbon nanotubes. "The tube has a large surface area and is empty inside. So either you can attach the drug to the outer surface, or fill it up like a test tube," says Dai. Furthermore, multiple functional molecules can be attached to the surface: "Say, a molecule that fluoresces to tell you where the drug is in the cell and an antibody that specifically targets the site of drug delivery." So far, Dai reports that his research finds nanotubes to be quite "biologically friendly." From Gasoizss@adaminnenausbau.de Tue Sep 25 12:16:52 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaD5g-0004Ka-4j for ccamp-archive@ietf.org; Tue, 25 Sep 2007 12:16:52 -0400 Received: from host82-186-dynamic.56-82-r.retail.telecomitalia.it ([82.56.186.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaD5b-0004Sm-Hf for ccamp-archive@ietf.org; Tue, 25 Sep 2007 12:16:47 -0400 Received: from pc by adaminnenausbau.de with ASMTP id 3547E0C7 for ; Tue, 25 Sep 2007 18:17:03 +0200 Received: from pc ([154.191.162.190]) by adaminnenausbau.de with ESMTP id E575D0C848A0 for ; Tue, 25 Sep 2007 18:17:03 +0200 Message-ID: <000601c7ff8f$76c55ac0$52ba3852@pc> From: "Daan Gasoi" To: Subject: isling Date: Tue, 25 Sep 2007 18:16:44 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C7FFA0.3A4E2AC0" 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.2 (+++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0005_01C7FFA0.3A4E2AC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.lamancay.com/ Morning ccamp-archive With a larger p*enis you penetrate more sensitive areas of the woman Daan Gasoi ------=_NextPart_000_0005_01C7FFA0.3A4E2AC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    http://www.lamancay.com/
    Morning ccamp-archive
    With a larger p*enis you penetrate more = sensitive areas=20 of the woman
    Daan Gasoi
    ------=_NextPart_000_0005_01C7FFA0.3A4E2AC0-- From Hancock@vanscyocs.com Tue Sep 25 12:46:29 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaDYK-0002kj-V0 for ccamp-archive@megatron.ietf.org; Tue, 25 Sep 2007 12:46:29 -0400 Received: from [201.229.210.69] (helo=tdev210-69.codetel.net.do) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaDY5-0005ET-Dl for ccamp-archive@megatron.ietf.org; Tue, 25 Sep 2007 12:46:13 -0400 Received: by 10.191.42.192 with SMTP id cujTGoraYHhxh; Tue, 25 Sep 2007 12:46:19 -0400 (GMT) Received: by 192.168.113.27 with SMTP id PDULzSeOhRMzri.3550627645302; Tue, 25 Sep 2007 12:46:17 -0400 (GMT) Message-ID: <000901c7ff93$95e4e570$45d2e5c9@bovensae833387> From: "gallan Hancock" To: Subject: ugoiiduk Date: Tue, 25 Sep 2007 12:46:14 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C7FF72.0ED34570" 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 000776-1, 24/09/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0005_01C7FF72.0ED34570 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.kurraba.com/ Evening ccamp-archive wow, its so much bigger now gallan Hancock ------=_NextPart_000_0005_01C7FF72.0ED34570 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    http://www.kurraba.com/
    Evening ccamp-archive
    wow, its so much bigger now
    gallan Hancock
    ------=_NextPart_000_0005_01C7FF72.0ED34570-- From mpatience@jmjbaking.com Tue Sep 25 13:04:23 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaDpf-00052v-Jm for ccamp-archive@ietf.org; Tue, 25 Sep 2007 13:04:23 -0400 Received: from [80.48.164.20] (helo=jmjbaking.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IaDpV-0002yl-40 for ccamp-archive@ietf.org; Tue, 25 Sep 2007 13:04:19 -0400 Received: (qmail 4655 invoked from network); Tue, 25 Sep 2007 19:04:19 +0200 Received: from unknown (HELO amapc) (mpatience@jmjbaking.com@205.63.70.85) by 14a43050jmjbaking.com with SMTP; Tue, 25 Sep 2007 19:04:19 +0200 Message-ID: <001501c7ffa6$e02f78d0$061bb3f4@amapc> From: Oliver Gleason To: ccamp-archive@ietf.org Subject: Not ridge Date: Tue, 25 Sep 2007 19:04:19 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C7FFA6.E02F78D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.2963 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.2969 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C7FFA6.E02F78D0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable for the Artist to adopt. Be it push button or voice-command, know where com= puter stimulus will lead, but certainly it is images can only be viewed via the computer and nowhere else. It ------=_NextPart_000_0012_01C7FFA6.E02F78D0 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable

    public to the media? How many people are unaware of the biases

    Are you wanting a bigger p >e n _i s?

    As se -e -n on TV

    Over 752,000 Men around the world are already satisfied
    Gain 4+ Inches In Leng _th
    Increase Your P _en -is Wi _dth (Girth) By up _to 29%
    100% Safe To Take, With NO Side Effects
    No Pum ps! No Surg ery! No Ex ercises!
    *3 FREE Bottles

    products, or real estate. They would not find it useful to
    ------=_NextPart_000_0012_01C7FFA6.E02F78D0-- From Hatfield@93collections.com.au Tue Sep 25 14:31:29 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaFBx-0002lr-G7 for ccamp-archive@megatron.ietf.org; Tue, 25 Sep 2007 14:31:29 -0400 Received: from host187-247-dynamic.12-87-r.retail.telecomitalia.it ([87.12.247.187]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaFBi-0000Ob-VY for ccamp-archive@megatron.ietf.org; Tue, 25 Sep 2007 14:31:15 -0400 Received: from xp-6z2irp2mads0 ([172.140.145.114]:26874 "EHLO xp-6z2irp2mads0" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by host187-247-dynamic.12-87-r.retail.telecomitalia.it with ESMTP id S22PRVEBEAQMQYZW (ORCPT ); Tue, 25 Sep 2007 20:36:10 +0200 Message-ID: <000201c7ffa2$e96d0790$bbf70c57@xp6z2irp2mads0> From: "aron Hatfield" To: Subject: girippeh Date: Tue, 25 Sep 2007 20:35:56 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C7FFB3.ACF5D790" 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_01C7FFB3.ACF5D790 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.ksngames.com/ Compliments ccamp-archive My cock is soooo big now, thanks to these doctors aron Hatfield ------=_NextPart_000_0006_01C7FFB3.ACF5D790 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    http://www.ksngames.com/
    Compliments ccamp-archive
    My cock is soooo big now, thanks to these = doctors
    aron Hatfield
    ------=_NextPart_000_0006_01C7FFB3.ACF5D790-- From Gebert@pinpointpages.com Tue Sep 25 15:36:48 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaGDA-0001tu-QK for ccamp-archive@ietf.org; Tue, 25 Sep 2007 15:36:48 -0400 Received: from 10001354438.0000081569.acesso.oni.pt ([89.26.148.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaGD8-0002vl-1h for ccamp-archive@ietf.org; Tue, 25 Sep 2007 15:36:46 -0400 Received: from paulorios ([108.102.77.162] helo=paulorios) by 10001354438.0000081569.acesso.oni.pt ( sendmail 8.13.3/8.13.1) with esmtpa id 1hAVeo-000PPF-iG for ccamp-archive@ietf.org; Tue, 25 Sep 2007 20:36:50 +0100 Message-ID: <000d01c7ffab$55beb300$3b941a59@paulorios> From: "Heather Gebert" To: Subject: sirarref Date: Tue, 25 Sep 2007 20:36:14 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C7FFB3.B7831B00" 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.1 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0009_01C7FFB3.B7831B00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://kvhawks.com/ regards ccamp-archive My peni*s grew 3=D2=D2 after 5 months of use Heather Gebert ------=_NextPart_000_0009_01C7FFB3.B7831B00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    http://kvhawks.com/
    regards ccamp-archive
    My peni*s grew 3=D2=D2 after 5 months of = use
    Heather Gebert
    ------=_NextPart_000_0009_01C7FFB3.B7831B00-- From owner-ccamp@ops.ietf.org Tue Sep 25 17:20:42 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaHpi-0008Af-F4 for ccamp-archive@ietf.org; Tue, 25 Sep 2007 17:20:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaHph-0002JW-8R for ccamp-archive@ietf.org; Tue, 25 Sep 2007 17:20:42 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IaHg8-0009VY-Hu for ccamp-data@psg.com; Tue, 25 Sep 2007 21:10:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [212.23.8.67] (helo=fizeau.zen.co.uk) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IaHg5-0009VC-SA for ccamp@ops.ietf.org; Tue, 25 Sep 2007 21:10:47 +0000 Received: from [212.23.3.142] (helo=rutherford.zen.co.uk) by fizeau.zen.co.uk with esmtp (Exim 4.50) id 1IaHg4-00041u-V0 for ccamp@ops.ietf.org; Tue, 25 Sep 2007 21:10:44 +0000 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1IaHg3-0004Sp-IH for ccamp@ops.ietf.org; Tue, 25 Sep 2007 21:10:43 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Sep 2007 22:10:43 +0100 Message-ID: <003801c7ffb8$86c94070$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Kohei Shiomoto" , "Dimitri Papadimitriou" , "Jean-Louis Le Roux" , "Martin Vigoureux" , "Brungard, Deborah A, ALABS" Subject: Last call completed on draft-ietf-ccamp-gmpls-mln-reqs-05.txt Date: Tue, 25 Sep 2007 22:10:30 +0100 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-OriginalArrivalTime: 25 Sep 2007 21:10:43.0212 (UTC) FILETIME=[887A24C0:01C7FFB8] X-Originating-Rutherford-IP: [88.96.235.138] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Hi, Working group last call completed on draft-ietf-ccamp-gmpls-mln-reqs-05.txt and draft-ietf-ccamp-gmpls-mln-eval-03.txt with a few comments to consider. The question was raised about the naming of "virtual TE links." It was suggested that "potential" be considered as a more appropriate word, partly because of the existing overload of "virtual" in various contexts, and partly to tie in with the ASON use of terminology. Could the authors please think about this and propose a resolution. We also received some comments from the ITU-T in their liaison https://datatracker.ietf.org/liaison/368/. They raise some issues for our consideration and the authors need to address these points so that they can update the I-D if necessary, and so we can respond to the ITU-T as necessary. Adaptation - They suggest that we should include a definition of Adaptation. - They suggest advertising the adaptation capability/ies of a link in place of the switching capabilities. I am confused by this because I would have thought that both pieces of information are needed. It may be that the ITU-T are assuming that the technology layer is known a priori. It is certainly the case that multiple switching or adaptation capabilities should be able to be advertised on a single link, and I think this is in the I-Ds, but maybe it needs clarification. - Abstract representations of layers and adaptations may be advantageous. Although this might be a solution-specific issue, if there are requirements they should be drawn out. Virtual Node The ITU-T suggests that the virtual node model might be applied as a solution architecture alongside the virtual links. Maybe the requirements draft could include some comments on this. Thanks, Adrian From bachman@alumni.washington.edu Tue Sep 25 17:27:53 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaHwf-0003Jx-09; Tue, 25 Sep 2007 17:27:53 -0400 Received: from [190.1.133.146] (helo=[190.1.133.146]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaHwb-000655-Ct; Tue, 25 Sep 2007 17:27:49 -0400 Received: from [190.1.133.146] by mxe8.u.washington.edu; Mon, 24 Sep 2007 16:25:56 -0500 Message-ID: <01c7fef1$7e480110$928501be@bachman> From: "Joann Benson" To: Subject: Hot Talk Date: Mon, 24 Sep 2007 16:25:56 -0500 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Score: 1.7 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 CHINA VOICE HOLDING Hot Momentum play for the week OTC : CHVC This company is nasdaq bound China Voice is on a roll earning Contract after contract This is not a Fly By Night Real Market Cap, Real Earnings Here are some of the latest news on CHVC - China Voice Holding Corp. Wins Contract for Command Center Monitoring and Video Conferencing System from Beijing Municipal Water Bureau - China Voice Holding Corp. Awarded Video Conferencing Contract from Sofitel Wanda Beijing, a Platinum 5 Star Hotel - China Voice Holding Corp. Announces $8 Million Dollar Commitment from InterEdge Technologies - China Voice Holding Corp. Announces Fifth Chinese Government Contract; Company Expects Additional Contracts Find out more and get in on CHVC before it takes off From cornelljewellub@netscape.net Tue Sep 25 18:29:13 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaIu1-00078F-MD; Tue, 25 Sep 2007 18:29:13 -0400 Received: from [218.66.50.96] (helo=tin.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaItu-0004NQ-P5; Tue, 25 Sep 2007 18:29:13 -0400 Date: Tue, 25 Sep 2007 22:13:37 +0000 To: capwap-archive@ietf.org, ccamp-archive@ietf.org Message-ID: <1190758417.1102@netscape.net> Subject: I selling Rolexes and other watches do you want ? 6e89 MIME-Version: 1.0 From: "Cornell A. Jewell" Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit X-Spam-Score: 3.6 (+++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Dear capwap-archive@ietf.org http://sueywh.com What is Prestige Replica store? At Prestige 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 Prestige Replica Shop! http://sueywh.com Thanks Ann Anniston capwap-archive@ietf.org wrote: > By Rolex for 250$ or less stqni73p4b- out me now http://sueywh.com/remove/ From sruparelia@yumeht.com Tue Sep 25 21:01:37 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaLHV-0007PR-2A; Tue, 25 Sep 2007 21:01:37 -0400 Received: from mnsr-4db5be66.pool.einsundeins.de ([77.181.190.102]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaLHQ-0003qm-Bn; Tue, 25 Sep 2007 21:01:32 -0400 Received: from [77.181.190.102] by yumeht.com; Wed, 26 Sep 2007 02:00:20 +0100 Message-ID: <01c7ffd8$9c3c6110$66beb54d@sruparelia> From: "Clarence Andrews" To: Subject: Fast Shipping WorldWide. Date: Wed, 26 Sep 2007 02:00:20 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7FFD8.9C3C6110" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C7FFD8.9C3C6110 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable When you are sexually aroused, your brain releases a hormone causing blood = to enter the penis and fill your erectile tissue (Corpora Cavernosa). The c= ells in the Corpora Cavernosa are filled with blood until an erection is ac= hieved. You can have a BIGGER PENIS! Fast Shipping WorldWide. Doctor Approv= ed And Recommended. No Pumps! No Surgery! No Exercises! Very discrete shipp= ing and billing. 100% Money Back Guarantee. *3 FREE Bottles Of Manster !! H= ighly secure 128bit order processing.http://kaokaowo.comManster Pills are a= unique blend of all natural and FDA approved ingredients. ------=_NextPart_000_0007_01C7FFD8.9C3C6110 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    When you are sexually aroused, your brain = releases a hormone causing blood to enter the penis and fill your erectile = tissue (Corpora Cavernosa). The cells in the Corpora Cavernosa are filled w= ith blood until an erection is achieved. You can have a BIGGER PENIS! Fast = Shipping WorldWide. Doctor Approved And Recommended. No Pumps! No Surgery! = No Exercises! Very discrete shipping and billing. 100% Money Back Guarantee= *3 FREE Bottles Of Manster !! Highly secure 128bit order processing.
    Manster Pills are a unique blend of all na= tural and FDA approved ingredients.
     
    ------=_NextPart_000_0007_01C7FFD8.9C3C6110-- From Kilmisterzzg@communityeconomies.org Wed Sep 26 05:39:26 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaTMc-0002lL-6t for ccamp-archive@megatron.ietf.org; Wed, 26 Sep 2007 05:39:26 -0400 Received: from 223-dom-2.acn.waw.pl ([82.210.141.223]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaTMO-0000n2-K7 for ccamp-archive@megatron.ietf.org; Wed, 26 Sep 2007 05:39:12 -0400 Received: by 10.235.159.137 with SMTP id wvForvGfeMPCB; Wed, 26 Sep 2007 11:39:20 +0200 (GMT) Received: by 192.168.199.151 with SMTP id zKGXfOhOuhajtQ.9134604558560; Wed, 26 Sep 2007 11:39:18 +0200 (GMT) Message-ID: <000401c80021$1a876220$df8dd252@micha3874ecfa9> From: "Roch Kilmister" To: ccamp-archive@megatron.ietf.org Subject: mmattini Date: Wed, 26 Sep 2007 11:39:15 +0200 Message-ID: <000401c80021$1a876220$df8dd252@micha3874ecfa9> 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.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Antivirus: avast! (VPS 000777-0, 2007-09-26), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 4.2 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Hello ccamp-archive I have a successful career, great friends, and own my own home. My sex life was the only area where I was lacking Roch Kilmister http://ckbooty.com/ From owner-ccamp@ops.ietf.org Wed Sep 26 06:26:07 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaU5n-0005fi-1J for ccamp-archive@ietf.org; Wed, 26 Sep 2007 06:26:07 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaU5h-0002Ib-Ku for ccamp-archive@ietf.org; Wed, 26 Sep 2007 06:26:01 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IaTry-000D8f-OZ for ccamp-data@psg.com; Wed, 26 Sep 2007 10:11:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-101.3 required=5.0 tests=AWL,BAYES_00, MIME_BASE64_BLANKS,MIME_BASE64_TEXT,RDNS_NONE,USER_IN_ALL_SPAM_TO autolearn=no version=3.2.1 Received: from [61.144.161.53] (helo=szxga01-in.huawei.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IaTrv-000D86-3z for ccamp@ops.ietf.org; Wed, 26 Sep 2007 10:11:48 +0000 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JOZ00BLL0ALI6@szxga01-in.huawei.com> for ccamp@ops.ietf.org; Wed, 26 Sep 2007 18:11:10 +0800 (CST) Received: from M55527 ([10.111.12.79]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JOZ003PT0AIV7@szxga01-in.huawei.com> for ccamp@ops.ietf.org; Wed, 26 Sep 2007 18:11:09 +0800 (CST) Date: Wed, 26 Sep 2007 18:10:52 +0800 From: Mach Chen Subject: Re: Re: [OSPF] Fwd: Posting of draft-ietf-ospf-ospfv3-traffic-09.txt To: Acee Lindem Cc: OSPF List , Vishwas Manral , Alan Davey , CCAMP List Message-id: <0JOZ003PZ0AKV7@szxga01-in.huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 5.0 [en] Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 2.8 (++) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 SGkgQWNlZSwNCg0KUGxzIHNlZSBpbmxpbmUNCg0KICANCk9uIDIwMDctMDktMjUsIGF0IDIxOjA1 OjQ5IEFjZWUgTGluZGVtIHdyb3RlOg0KDQo+SGkgTWFjaCwNCj5UaGFua3MgZm9yIHJldmlld2lu Zy4NCj4NCj5PbiBTZXAgMjUsIDIwMDcsIGF0IDQ6MjQgQU0sIE1hY2ggQ2hlbiB3cm90ZToNCj4N Cj4+IEhpIEFjZWUgYW5kIG90aGVyIGF1dGhvcnMsDQo+Pg0KPj4NCj4+DQo+PiBTb21lIHF1ZXN0 aW9ucyB0byBvc3BmdjMtdHJhZmZpYw0KPj4NCj4+DQo+Pg0KPj4gMS4gICAgICAgSW4gdGhpcyBv c3BmdjMtdHJhZmZpYyBkb2N1bWVudCwgYSBuZXcgTFNBLCBJbnRyYS1BcmVhLVRFICANCj4+IExT QSwgaXMgZGVmaW5lZCB0byBhZHZlcnRpc2UgSVB2NiBURSBpbmZvcm1hdGlvbi4gRnJvbSBuYW1l IG9mIHRoaXMgIA0KPj4gbmV3IExTQSwgSU1ITywgaXQgaXMgbGltaXRlZCB0byBiZSB1c2VkIGZv ciBJbnRyYS1BcmVhIFRFIG9ubHkuIFNvLCAgDQo+PiBpZiB0aGVyZSBhcmUgc29tZSB1bmRlcmx5 aW5nIGV4dGVuc2lvbnMgdG8gb3NwZnYzLXRyYWZmaWMsIGUuZy4gIA0KPj4gSW50ZXItQVMgVEUs IGl0IGlzIGEgbGl0dGxlIGJpdCBzdHJhbmdlIHRvIHJlLXVzZSB0aGUgSW50cmEtQXJlYS1URSAg DQo+PiBMU0EsIG9yIGl0IGhhcyB0byBkZWZpbmUgYSBuZXcgTFNBLiBTbywgY2FuIHdlIGNoYW5n ZSBpdHMgbmFtZSB0byAgDQo+PiBzb21ldGhpbmcgbGlrZSChsE9TUEZ2MyBURSBMU0GhsT8NCj5J dCB3b3VsZCBiZSBpZiB3ZSBoYWQgaW50ZW5kZWQgaXQgdG8gY2FycnkgQVMgd2lkZSBpbmZvcm1h dGlvbi4gIA0KPkhvd2V2ZXIsIGl0IHdhcyBub3QgaW5pdGlhbGx5IGludGVuZGVkIGZvciB0aGlz LiBUaGUgaW5pdGlhbCB0aG91Z2h0ICANCj53YXMgdGhhdCB3ZSB3b3VsZCBkbyBhIGJldHRlciBq b2IgZm9yIE9TUEZ2MyBhbmQgZGVmaW5lIHNlcGFyYXRlIExTQSAgDQo+dHlwZXMgZm9yIGludHJh LWFyZWEsIGludGVyLWFyZWEsIGFuZCBBUyBleHRlcm5hbCBURSBMU0FzLiBUaG91Z2h0cyAgDQo+ b24gdGhpcyAoY29waWVkIGNjYW1wIGFzIHdlbGwpPw0KDQpTbywgdGhlIGNvbmNsdXNpb24gaXMg dGhhdCBhIG5ldyBMU0EobWF5IGJlIGNhbGxlZCBJbnRlci1BUy1URSBMU0EpIGhhcyB0byBiZSBk ZWZpbmVkIGZvciBhZHZlcnRpc2luZyBpbnRlci1BUyBURSBpbmZvcm1hdGlvbiBpbiBzdXBwb3J0 IG9mIE9TUEZ2MyBURSwgYW0gSSByaWdodD8NCiANCj4gSSBndWVzcywgSU1ITywgdGhpcyBkaXNj cmVwYW5jeSAgDQo+ZXhwb3NlcyB0aGUgY2hvaWNlIG9mIGEgbmV3IGxpbmsgdHlwZSBmb3IgaW50 ZXItQVMgY29ubmVjdGl2aXR5IGFzIGEgIA0KPmJpdCBvZiBhIGhhY2suDQo+DQoNCkZvciBPU1BG djMgVEUoc2VwYXJhdGUgTFNBcyBhcmUgdXNlZCkgaXMgWUVTLiBCdXQgYXMgdG8gT1NQRnYyIFRF LCBJTUhPLCB0aGVyZSBzaG91bGQgYmUgYSBuZXcgbGluayB0eXBlIHRvIGlkZW50aWZ5IGFuIGlu dGVyLUFTIGxpbmssIG9yIHdlIG5lZWQgYW5vdGhlciBuZXcgTFNBLg0KDQo+DQo+DQo+Pg0KPj4N Cj4+IDIuICAgICAgIFNlY3Rpb24gMi4NCj4+DQo+PiChsFRoZSBmb3JtYXQgb2YgdGhlIFRMVnMg d2l0aGluIHRoZSBib2R5IG9mIGEgcm91dGVyIGluZm9ybWF0aW9uIExTQSAgDQo+PiBpcyB0aGUg c2FtZSBhcyB0aGUgZm9ybWF0IHVzZWQgYnkgdGhlIFRyYWZmaWMgRW5naW5lZXJpbmcgIA0KPj4g RXh0ZW5zaW9ucyB0byBPU1BGIFtURV0uobENCj4+DQo+Pg0KPj4NCj4+IFdoYXShr3MgobBhIHJv dXRlciBpbmZvcm1hdGlvbiBMU0GhsT8gIE9yIHNob3VsZCBpdCBiZSChsGFuIEludHJhLUFyZWEt IA0KPj4gVEUgTFNBobEgPw0KPg0KPlllcy4gR29vZCBjYXRjaC4gSSdsbCBmaXggdGhpcy4NCg0K VGhhbmtzLg0KDQo+DQo+VGhhbmtzLA0KPkFjZWUNCg0KDQpCZXN0IHJlZ2FyZHMsCQkJDQpNYWNo IENoZW4NCg0K From chene704@artpasifikrim.co.nz Wed Sep 26 06:50:39 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaUTX-00086M-4m for ccamp-archive@megatron.ietf.org; Wed, 26 Sep 2007 06:50:39 -0400 Received: from host224-152-static.24-87-b.business.telecomitalia.it ([87.24.152.224]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaUTM-0002zP-11 for ccamp-archive@megatron.ietf.org; Wed, 26 Sep 2007 06:50:28 -0400 Received: from server ([105.127.151.2] helo=server) by [87.24.152.224] ( sendmail 8.13.3/8.13.1) with esmtpa id 1Acuci-000UVG-IX for ccamp-archive@megatron.ietf.org; Wed, 26 Sep 2007 12:58:35 +0200 Message-ID: <000b01c8002c$1af5b350$e0981857@server> From: "chene garling" To: Subject: ieksmerk Date: Wed, 26 Sep 2007 12:58:01 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C8003C.DE7E8350" 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.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0005_01C8003C.DE7E8350 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.clannnn.com/ Good day ccamp-archive Before Manster i had no women, now i have 3 going at once =3D ) chene garling ------=_NextPart_000_0005_01C8003C.DE7E8350 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    http://www.clannnn.com/
    Good day ccamp-archive
    Before Manster i had no women, now i have 3 = going at=20 once =3D )
    chene garling
    ------=_NextPart_000_0005_01C8003C.DE7E8350-- From cup@mynmail.com Wed Sep 26 07:17:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaUts-0004Lb-Vk for ccamp-archive@megatron.ietf.org; Wed, 26 Sep 2007 07:17:52 -0400 Received: from [125.187.32.248] (helo=m11.mailyes.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaUtr-0007J8-FV for ccamp-archive@megatron.ietf.org; Wed, 26 Sep 2007 07:17:52 -0400 Received: (qmail 26655 invoked by uid 0); 26 Sep 2007 19:13:22 +0900 Message-ID: <20070926101322.26654.qmail@m11.mailyes.net> To: ccamp-archive Subject: =?ISO-2022-JP?B?GyRCJDQ2YT1qJEdCKCUiJV0bKEI=?= From: infomail Reply-to: delivery_rt Date: 2007-09-26 19:00:02 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: GOOD Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20070925172624_cbur Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 4.7 (++++) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab $B!v!v(B================================================$B!v!v(B $B!!!!!z%+%i%@$@$1$N4X78!"!{Hk$NNx!"(B $BBg?M$NNx!";d$?$A$N4jK>$r3p$($F!z(B $B!v!v(B================================================$B!v!v(B $B!y%l%G%#%3%_!"=w@-;(;o!"%/%A%3%_!"%$%s%?!<%M%C%H$J$I$G(B $B!!9-$^$C$?!"CK=w40A4L5NA%5%$%H!y(B $B!!!!!!!!!!!!!z!!K~B-$9$k$J$i%3%3$7$+$J$$!!!z(B $B!!(B $B!!!!!!(Bhttp://xxxx-69.org.uk/pc/index3.php? $B!!"(Bg?M$N8r:]$r4uK>$5$l$kJ}$N$?$a$K(B $B!!!!:#$J$i2q0wHq!&G/2qHqEy0l@ZL5NA$G$*3Z$7$_D:$1$^$9!#(B $B!!!!EvA3$G$9$,!":#F~2q$5$l$?J}$ONA6b$,0l@Z$+$+$j$^$;$s!*(B $B!!!!EPO?$KI,MW$J$N$O$"$J$?$N%a!<%k%"%I%l%9$@$1!#(B $B!!!!40A4F?L>$G$4MxMQ$,=PMh$^$9!#(B $B!!!!(B $B!!!!!!"'!!Bg!!?M!!$N!!4X!!78!!$O(B $B$3(B $B$3(B $B$+(B $B$i!!"'(B $B!!(B $B!!(B http://xxxx-69.org.uk/pc/index3.php? $B!!!y!!!!!y(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!!y!!(B $B!y(B $B!!!z!y;38}!!H~M35*!y!z(B $B!!(B28$B:P!!(B157cm $B!!3d@Z$C$?46$8$G$9$0$K$G$b!"2q$($l$P$$$$$G$9$M!)(B $B!!$b$A$m$s$*Ni$b9M$($F$$$^$9$h!#4uK>$,$"$l$P65$($F$/$@$5$$(B $B!!7n#3#0$^$G$J$i$9$0$K$G$bMQ0U$G$-$^$9!#(B $B!!Aj$G!#(B http://xxxx-69.org.uk/pc/index3.php? $B!!!y!!!!!y(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!!y!!(B $B!y(B $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!($(B $B:G9bJv=P2q$$%5%$%H!*!X$46a=j8!:w!Y(B URL $B!'(B http://xxxx-69.org.uk/pc/index3.php? $B$3$N%a!<%k$K=q$+$l$?FbMF$NL5CG7G:\!"L5CGJ#@=$r6X$8$^$9!#(B Copyright (C) 2007 gokinjo All Rights Reserved. $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(%(B $B"(G[?.Dd;_$O$3$A$i$+$i(B notmail@gmail.com From liang@sianalexander.net Wed Sep 26 07:37:27 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaVCp-0004qA-ON for ccamp-archive@ietf.org; Wed, 26 Sep 2007 07:37:27 -0400 Received: from [200.231.63.138] (helo=200231063138.provale.com.br) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaVCk-00040s-Sr for ccamp-archive@ietf.org; Wed, 26 Sep 2007 07:37:23 -0400 Received: by 10.109.207.185 with SMTP id UCXlmgPlyLFqu; Wed, 26 Sep 2007 08:36:49 -0300 (GMT) Received: by 192.168.107.21 with SMTP id kpfklfWTvIGPNR.0464402661994; Wed, 26 Sep 2007 08:36:47 -0300 (GMT) Message-ID: Date: Wed, 26 Sep 2007 08:36:44 -0300 From: "liang erere" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: tvrijere Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Evening ccamp-archive Girls actually use to laugh at me! liang erere http://goingles.com/ From cup@mynmail.com Wed Sep 26 07:46:03 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaVL9-0007Oz-P3 for ccamp-archive@ietf.org; Wed, 26 Sep 2007 07:46:03 -0400 Received: from [125.187.32.248] (helo=m11.mailyes.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaVL8-0004Do-Q8 for ccamp-archive@ietf.org; Wed, 26 Sep 2007 07:46:03 -0400 Received: (qmail 6755 invoked by uid 0); 26 Sep 2007 19:05:55 +0900 Message-ID: <20070926100555.6754.qmail@m11.mailyes.net> To: ccamp-archive Subject: =?ISO-2022-JP?B?GyRCJDQ2YT1qJEdCKCUiJV0bKEI=?= From: infomail Reply-to: delivery_rt Date: 2007-09-26 19:00:02 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: GOOD Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20070925172624_cbur Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 3.6 (+++) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab $B!v!v(B================================================$B!v!v(B $B!!!!!z%+%i%@$@$1$N4X78!"!{Hk$NNx!"(B $BBg?M$NNx!";d$?$A$N4jK>$r3p$($F!z(B $B!v!v(B================================================$B!v!v(B $B!y%l%G%#%3%_!"=w@-;(;o!"%/%A%3%_!"%$%s%?!<%M%C%H$J$I$G(B $B!!9-$^$C$?!"CK=w40A4L5NA%5%$%H!y(B $B!!!!!!!!!!!!!z!!K~B-$9$k$J$i%3%3$7$+$J$$!!!z(B $B!!(B $B!!!!!!(Bhttp://xxxx-69.org.uk/pc/index3.php? $B!!"(Bg?M$N8r:]$r4uK>$5$l$kJ}$N$?$a$K(B $B!!!!:#$J$i2q0wHq!&G/2qHqEy0l@ZL5NA$G$*3Z$7$_D:$1$^$9!#(B $B!!!!EvA3$G$9$,!":#F~2q$5$l$?J}$ONA6b$,0l@Z$+$+$j$^$;$s!*(B $B!!!!EPO?$KI,MW$J$N$O$"$J$?$N%a!<%k%"%I%l%9$@$1!#(B $B!!!!40A4F?L>$G$4MxMQ$,=PMh$^$9!#(B $B!!!!(B $B!!!!!!"'!!Bg!!?M!!$N!!4X!!78!!$O(B $B$3(B $B$3(B $B$+(B $B$i!!"'(B $B!!(B $B!!(B http://xxxx-69.org.uk/pc/index3.php? $B!!!y!!!!!y(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!!y!!(B $B!y(B $B!!!z!y;38}!!H~M35*!y!z(B $B!!(B28$B:P!!(B157cm $B!!3d@Z$C$?46$8$G$9$0$K$G$b!"2q$($l$P$$$$$G$9$M!)(B $B!!$b$A$m$s$*Ni$b9M$($F$$$^$9$h!#4uK>$,$"$l$P65$($F$/$@$5$$(B $B!!7n#3#0$^$G$J$i$9$0$K$G$bMQ0U$G$-$^$9!#(B $B!!Aj$G!#(B http://xxxx-69.org.uk/pc/index3.php? $B!!!y!!!!!y(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!!y!!(B $B!y(B $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!($(B $B:G9bJv=P2q$$%5%$%H!*!X$46a=j8!:w!Y(B URL $B!'(B http://xxxx-69.org.uk/pc/index3.php? $B$3$N%a!<%k$K=q$+$l$?FbMF$NL5CG7G:\!"L5CGJ#@=$r6X$8$^$9!#(B Copyright (C) 2007 gokinjo All Rights Reserved. $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(%(B $B"(G[?.Dd;_$O$3$A$i$+$i(B notmail@gmail.com From owner-ccamp@ops.ietf.org Wed Sep 26 07:56:59 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaVVj-0006ki-KT for ccamp-archive@ietf.org; Wed, 26 Sep 2007 07:56:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaVVi-0008BU-4b for ccamp-archive@ietf.org; Wed, 26 Sep 2007 07:56:59 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IaVLk-000OJX-IG for ccamp-data@psg.com; Wed, 26 Sep 2007 11:46:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [192.26.91.6] (helo=mandala.kddilabs.jp) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IaVLh-000OJ6-GQ for ccamp@ops.ietf.org; Wed, 26 Sep 2007 11:46:39 +0000 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id D8745ECB55; Wed, 26 Sep 2007 20:46:35 +0900 (JST) Received: from platinum.inc.kddilabs.jp (unknown [2001:200:601:1300:20a:48ff:fe12:3f1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 6E95EECAD9; Wed, 26 Sep 2007 20:46:33 +0900 (JST) Received: from [IPv6:::1] (unknown [IPv6:2001:200:601:1300:8f9:6cdb:e306:f3e0]) by platinum.inc.kddilabs.jp (Postfix) with ESMTP id 75227578111; Wed, 26 Sep 2007 20:46:30 +0900 (JST) Message-ID: <46FA469A.5090708@cn.kddilabs.jp> Date: Wed, 26 Sep 2007 20:46:34 +0900 From: ogaki User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: ccamp@ops.ietf.org Cc: Adrian Farrel , Ross Callon , Tomohiro Otani Subject: Re: Plans for GELS work in CCAMP References: <0428AC48A879ED46A94F39D5665DF684A57990@esealmw110.eemea.ericsson.se> In-Reply-To: <0428AC48A879ED46A94F39D5665DF684A57990@esealmw110.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Hi All, Sorry for this late reply. We are interesd in this activity and can support this work as an operator= . Regards, Kenichi Diego Caviglia (GA/ERI) wrote: >Hi Adrian hi Deborah, > I think that this is a very good way to proceed I a= lso think the people in the DT are the right ones. > >I'd like to contribute this work so DT guys please fill free to contact = me. > >Best Regards > >Diego > =20 > >>-----Original Message----- >>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Beh= alf >>Of Adrian Farrel >>Sent: mercoled=EC 5 settembre 2007 11.51 >>To: ccamp@ops.ietf.org >>Cc: Ross Callon >>Subject: Plans for GELS work in CCAMP >> >>Hi, >> >>We owe you a plan for starting the GELS work in CCAMP. >> >>As you may have seen, we have just sent a request to the ADs to push >>through >>our recharter as discussed on the mailing list. The ADs have already >>indicated their support, so hopefully this will be fairly smooth. >> >>We have also been talking with Don and Loa about starting work on the G= ELS >>drafts that we will accept into the working group as a starting point. >>(Other drafts can be added as needed.) >> >>1. "GMPLS Extensions for PE to PE Ethernet Label Switched Paths(LSPs)" >>This document is the generic work: >>- Introduction >>- Rationale for GMPLS Control of Ethernet >>- Generic functional requirements (no data plane specifics!) >>- Applicability of existing protocol elements >>- New generic protocol elements (nothing specific to the data plane) >> >>2. "GMPLS control of P2P TE for PBB-TE (802.1Qay)" >>Mainly references to the generic document. >>Some protocol specifics: >>- Code points (i.e. IANA section) >>- Label allocation and swapping rules >>Not a large document. >> >>Other drafts that we might also see: >> >>3. "GMPLS control of P2P TE for IEEE802.1Q" >>Another data plane-specific draft, like 2, but for a different data pla= ne >> >>4. Applicability Statement >>A concise description of how and why to apply GMPLS to Ethernet. >>Probably not written until after the protocol work is done. >> >>We propose a relatively small design team to get this work started. >> Loa Andersson >> Lou Berger >> Don Fedyk >> George Swallow >> >>We are NOT trying to exclude anyone from the work, and we make a couple= of >>observations: >> >>- A design team is just a group of people working on a >> draft. >>- Anyone and everyone is welcome to write a draft. >>- We feel that an initial design should be small to make >> rapid initial progress. >>- We welcome (and expect!) full and detailed contribution >> on the mailing list as this work progresses. >>- Everyone who contributes to a draft should be appropriately >> recognised in the draft. >> >>Last point: >>I propose to close the GELS mailing list now. >> >>Hope this is all satisfactory to you. >> >>Regards, >>Adrian and Deborah >> >> >> =20 >> > > > > > =20 > From akstcadvanciamnsdgs@advancia.com Wed Sep 26 08:22:34 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaVuU-0003VF-PH; Wed, 26 Sep 2007 08:22:34 -0400 Received: from 55.user50.tvujnet.cz ([213.192.50.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaVuP-0005H2-Dy; Wed, 26 Sep 2007 08:22:29 -0400 Received: from [213.192.50.55] by arcm2.advancia.com; Wed, 26 Sep 2007 13:22:13 +0100 Message-ID: <01c80037$de48bf90$3732c0d5@akstcadvanciamnsdgs> From: "Dominique Baldwin" To: Subject: wow what a cool watch Date: Wed, 26 Sep 2007 13:22:13 +0100 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.3338.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3338.1 X-Spam-Score: 1.0 (+) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed www.oeieuwu.com 15% off when you buy 2 or more watches We can guarantee you that ordering from our site is safer than ordering in real life. From balded@autotechnics-ltd.com Wed Sep 26 09:47:08 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaXEK-0006So-57; Wed, 26 Sep 2007 09:47:08 -0400 Received: from [201.228.53.189] (helo=[201.228.53.189]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaXE9-0007WH-00; Wed, 26 Sep 2007 09:46:57 -0400 Received: from [201.228.53.189] by ismtp.easyspace.everyone.net; Wed, 26 Sep 2007 08:46:45 -0500 Date: Wed, 26 Sep 2007 08:46:45 -0500 From: "Cathy Coon" X-Mailer: The Bat! (v2.00.7) Personal Reply-To: balded@autotechnics-ltd.com X-Priority: 3 (Normal) Message-ID: <242988950.05982132999416@autotechnics-ltd.com> To: ccamp-archive@ietf.org Subject: China Voice Holding Corp. Wins Contract for Command Center Monitoring and Video Conferencing System from Beijing Municipal Water Bureau MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c China Voice Holding Corp. Announces Fifth Chinese Government Contract; Company Expects Additional Contracts CHINA VOICE HOLDING Hot Momentum play for the week OTC : CHVC This company is nasdaq bound China Voice is on a roll earning Contract after contract This is not a Fly By Night Real Market Cap, Real Earnings China Voice Holding Corp. Announces $8 Million Dollar Commitment from InterEdge Technologies From owner-ccamp@ops.ietf.org Wed Sep 26 10:30:15 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaXu3-00019K-1X for ccamp-archive@ietf.org; Wed, 26 Sep 2007 10:30:15 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaXu0-0000PS-FG for ccamp-archive@ietf.org; Wed, 26 Sep 2007 10:30:12 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IaXgN-000FbA-J9 for ccamp-data@psg.com; Wed, 26 Sep 2007 14:16:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.1 Received: from [155.53.12.9] (helo=prattle.redback.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IaXgH-000FaZ-Qq for ccamp@ops.ietf.org; Wed, 26 Sep 2007 14:16:06 +0000 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 5941E74D921; Wed, 26 Sep 2007 07:16:01 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22158-10; Wed, 26 Sep 2007 07:16:00 -0700 (PDT) Received: from [ZJ??O??IPv6???1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 2BA8C74D91F; Wed, 26 Sep 2007 07:16:00 -0700 (PDT) In-Reply-To: <0JOZ003PZ0AKV7@szxga01-in.huawei.com> References: <0JOZ003PZ0AKV7@szxga01-in.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Cc: OSPF List , Vishwas Manral , Alan Davey , CCAMP List Content-Transfer-Encoding: quoted-printable From: Acee Lindem Subject: Re: [OSPF] Fwd: Posting of draft-ietf-ospf-ospfv3-traffic-09.txt Date: Wed, 26 Sep 2007 10:14:36 -0400 To: Mach Chen X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new at redback.com Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Hi Mach, On Sep 26, 2007, at 6:10 AM, Mach Chen wrote: > Hi Acee, > > Pls see inline > > > On 2007-09-25, at 21:05:49 Acee Lindem wrote: > >> Hi Mach, >> Thanks for reviewing. >> >> On Sep 25, 2007, at 4:24 AM, Mach Chen wrote: >> >>> Hi Acee and other authors, >>> >>> >>> >>> Some questions to ospfv3-traffic >>> >>> >>> >>> 1. In this ospfv3-traffic document, a new LSA, Intra-Area-TE >>> LSA, is defined to advertise IPv6 TE information. =46rom name of = this >>> new LSA, IMHO, it is limited to be used for Intra-Area TE only. So, >>> if there are some underlying extensions to ospfv3-traffic, e.g. >>> Inter-AS TE, it is a little bit strange to re-use the Intra-Area-TE >>> LSA, or it has to define a new LSA. So, can we change its name to >>> something like =93OSPFv3 TE LSA=94? >> It would be if we had intended it to carry AS wide information. >> However, it was not initially intended for this. The initial thought >> was that we would do a better job for OSPFv3 and define separate LSA >> types for intra-area, inter-area, and AS external TE LSAs. Thoughts >> on this (copied ccamp as well)? > > So, the conclusion is that a new LSA(may be called Inter-AS-TE LSA) =20= > has to be defined for advertising inter-AS TE information in =20 > support of OSPFv3 TE, am I right? > >> I guess, IMHO, this discrepancy >> exposes the choice of a new link type for inter-AS connectivity as a >> bit of a hack. >> > > For OSPFv3 TE(separate LSAs are used) is YES. But as to OSPFv2 TE, =20 > IMHO, there should be a new link type to identify an inter-AS link, =20= > or we need another new LSA. It seems to me that if we do add the link in your draft, then it =20 should be done the same in OSPFv2 and OSPFv3. Advertising it as a new =20= link type is one way to advertise inter-AS connectivity. However, it =20 isn't necessarily a link. This seems to me to be more of a semantical =20= discrepancy than the name of the LSA. In section 4, I notice that at =20 least for OSPFv2 the draft says the new link may be advertised in =20 either a type 11 opaque LSA or type 10 opaque LSA. Given the maturity =20= of RFC 3630, it almost seems to me that we should allocate a new LSA =20 opaque type for this purpose. What is the status of draft-ietf-ccamp-ospf-interas-te-=20 extension-01.txt? I know at the OSPF meeting there were a number of =20 people who questioned whether or not it was necessary. Thanks, Acee > >> >> >>> >>> >>> 2. Section 2. >>> >>> =93The format of the TLVs within the body of a router information = LSA >>> is the same as the format used by the Traffic Engineering >>> Extensions to OSPF [TE].=94 >>> >>> >>> >>> What=92s =93a router information LSA=94? Or should it be =93an = Intra-Area- >>> TE LSA=94 ? >> >> Yes. Good catch. I'll fix this. > > Thanks. > >> >> Thanks, >> Acee > > > Best regards, =09 > Mach Chen > From Jeppe-nicholson@armygear.net Wed Sep 26 14:24:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IabYH-0001KV-KW for ccamp-archive@ietf.org; Wed, 26 Sep 2007 14:24:01 -0400 Received: from h35.162.40.69.ip.alltel.net ([69.40.162.35]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IabYC-0001TZ-7F for ccamp-archive@ietf.org; Wed, 26 Sep 2007 14:23:56 -0400 Received: by 10.114.10.74 with SMTP id wJKEldqRaMcFl; Wed, 26 Sep 2007 14:23:19 -0400 (GMT) Received: by 192.168.157.86 with SMTP id cypDZCJqBBxWsM.5174457065336; Wed, 26 Sep 2007 14:23:17 -0400 (GMT) Message-ID: <000401c8006a$4d3dfaa0$23a22845@Schroeder> From: "Jeppe nicholson" To: Subject: palmammo Date: Wed, 26 Sep 2007 14:23:14 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C80048.C62C5AA0" 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.0 (+++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0005_01C80048.C62C5AA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://ckbooty.com/ regards ccamp-archive The demand for these pills is so high .. prices will go up soon Jeppe nicholson ------=_NextPart_000_0005_01C80048.C62C5AA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    http://ckbooty.com/
    regards ccamp-archive
    The demand for these pills is so high .. = prices will go=20 up soon
    Jeppe nicholson
    ------=_NextPart_000_0005_01C80048.C62C5AA0-- From Eziojaneen@2daysign.com Wed Sep 26 15:50:42 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IacuA-0000j1-4M for ccamp-archive@megatron.ietf.org; Wed, 26 Sep 2007 15:50:42 -0400 Received: from anice-751-1-8-71.w90-4.abo.wanadoo.fr ([90.4.219.71]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iacu3-0005Ny-6K for ccamp-archive@megatron.ietf.org; Wed, 26 Sep 2007 15:50:35 -0400 Received: from microlan ([162.167.44.196]:21521 "EHLO microlan" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by ANice-751-1-8-71.w90-4.abo.wanadoo.fr with ESMTP id S22XFCQKUEPUNZCP (ORCPT ); Wed, 26 Sep 2007 21:51:44 +0200 Message-ID: <000d01c80076$975218e0$47db045a@microlan> From: "Ezio janeen" To: Subject: auhepet Date: Wed, 26 Sep 2007 21:51:12 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C80087.5ADC6F80" 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.5 (+++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0007_01C80087.5ADC6F80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://chbit.com/ regards ccamp-archive people are so shocked when they find out these herbal pills actually = work Ezio janeen ------=_NextPart_000_0007_01C80087.5ADC6F80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    http://chbit.com/
    regards ccamp-archive
    people are so shocked when they find out these = herbal=20 pills actually work
    Ezio janeen
    ------=_NextPart_000_0007_01C80087.5ADC6F80-- From ewritten@cravegames.com Wed Sep 26 16:05:44 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iad8i-0005nK-Gk; Wed, 26 Sep 2007 16:05:44 -0400 Received: from cerber.lastnet.pl ([62.233.163.182] helo=dxq154.internetdsl.tpnet.pl) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iad8K-0005nl-C8; Wed, 26 Sep 2007 16:05:20 -0400 Received: from gazbasin5s2sxz ([165.118.209.146]:9468 "HELO gazbasin5s2sxz" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 9a2a0e53cravegames.com with ESMTP id 051681337E9BD (ORCPT ); Wed, 26 Sep 2007 22:06:46 +0200 Message-ID: <001801c80089$877b6670$06b266f4@gazbasin5s2sxz> From: Jessica U. Godwin To: ccamp-archive@ietf.org Subject: cinsertion Date: Wed, 26 Sep 2007 22:06:46 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C80089.877B6670" 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.0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C80089.877B6670 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable touch with a few. Friendships grow and you learn from each other. slaves to entertainment when no such preposterous phenomena has most of the= m will never be realized. Virtual reality is already a ------=_NextPart_000_0015_01C80089.877B6670 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    expression and acknowledges art to be more interactive. The

    Are you wanting a bigger p >e n _i s?

    As se -e -n on TV

    Over 768,000 Men around the world are already satisfied
    Gain 3+ Inches In Leng _th
    Increase Your P _en -is Wi _dth (Girth) By up _to 21%
    100% Safe To Take, With NO Side Effects
    No Pum ps! No Surg ery! No Ex ercises!
    *3 FREE Bottles

    booth with VR equipment and attachments. Inside the VR world
    ------=_NextPart_000_0015_01C80089.877B6670-- From cup@mynmail.com Wed Sep 26 16:16:07 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IadIl-0006CI-7k for ccamp-archive@ietf.org; Wed, 26 Sep 2007 16:16:07 -0400 Received: from [125.187.32.241] (helo=m01.mailyes.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IadIj-0007NV-Bb for ccamp-archive@ietf.org; Wed, 26 Sep 2007 16:16:07 -0400 Received: (qmail 16636 invoked by uid 0); 27 Sep 2007 05:05:51 +0900 Message-ID: <20070926200551.16635.qmail@m01.mailyes.net> To: ccamp-archive Subject: =?ISO-2022-JP?B?GyRCJDQ2YT1qMGxILzghOncbKEI=?= =?ISO-2022-JP?B?GyRCJEdMNU5BQiglIiVdGyhC?= From: sokuapomail Reply-to: delivery_rt Date: 2007-09-27 05:01:02 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: GOOD Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20070926190645_cbur Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 3.6 (+++) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab $B!v!v(B================================================$B!v!v(B $B!!!!!z%+%i%@$@$1$N4X78!"!{Hk$NNx!"(B $BBg?M$NNx!";d$?$A$N4jK>$r3p$($F!z(B $B!v!v(B================================================$B!v!v(B $B!y%l%G%#%3%_!"=w@-;(;o!"%/%A%3%_!"%$%s%?!<%M%C%H$J$I$G(B $B!!9-$^$C$?!"CK=w40A4L5NA%5%$%H!y(B $B!!!!!!!!!!!!!z!!K~B-$9$k$J$i%3%3$7$+$J$$!!!z(B $B!!(B $B!!!!!!(Bhttp://xxxx-69.org.uk/pc/index3.php?u9psp4 $B!!"(Bg?M$N8r:]$r4uK>$5$l$kJ}$N$?$a$K(B $B!!!!:#$J$i2q0wHq!&G/2qHqEy0l@ZL5NA$G$*3Z$7$_D:$1$^$9!#(B $B!!!!EvA3$G$9$,!":#F~2q$5$l$?J}$ONA6b$,0l@Z$+$+$j$^$;$s!*(B $B!!!!EPO?$KI,MW$J$N$O$"$J$?$N%a!<%k%"%I%l%9$@$1!#(B $B!!!!40A4F?L>$G$4MxMQ$,=PMh$^$9!#(B $B!!!!(B $B!!!!!!"'!!Bg!!?M!!$N!!4X!!78!!$O(B $B$3(B $B$3(B $B$+(B $B$i!!"'(B $B!!(B $B!!(B http://xxxx-69.org.uk/pc/index3.php?u9psp4 $B!!!y!!!!!y(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!!y!!(B $B!y(B $B!!!z!y;38}!!H~M35*!y!z(B $B!!(B28$B:P!!(B157cm $B!!3d@Z$C$?46$8$G$9$0$K$G$b!"2q$($l$P$$$$$G$9$M!)(B $B!!$b$A$m$s$*Ni$b9M$($F$$$^$9$h!#4uK>$,$"$l$P65$($F$/$@$5$$(B $B!!7n#3#0$^$G$J$i$9$0$K$G$bMQ0U$G$-$^$9!#(B $B!!Aj$G!#(B http://xxxx-69.org.uk/pc/index3.php?u9psp4 $B!!!y!!!!!y(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!!y!!(B $B!y(B $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!($(B $B:G9bJv=P2q$$%5%$%H!*!X$46a=j8!:w!Y(B URL $B!'(B http://xxxx-69.org.uk/pc/index3.php?u9psp4 $B$3$N%a!<%k$K=q$+$l$?FbMF$NL5CG7G:\!"L5CGJ#@=$r6X$8$^$9!#(B Copyright (C) 2007 gokinjo All Rights Reserved. $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(%(B $B"(G[?.Dd;_$O$3$A$i$+$i(B notmail@gmail.com From balboas@astaweb.com Wed Sep 26 17:20:15 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaeIo-0002as-VC; Wed, 26 Sep 2007 17:20:14 -0400 Received: from [201.226.52.32] (helo=[201.226.52.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaeIe-00015x-Ih; Wed, 26 Sep 2007 17:20:05 -0400 Received: from [201.226.52.32] by INBOUND.ASTAWEB.COM.NETSOLMAIL.NET; Wed, 26 Sep 2007 16:17:20 -0500 Date: Wed, 26 Sep 2007 16:17:20 -0500 From: "Morris Richey" X-Mailer: The Bat! (v3.71.01) Professional Reply-To: balboas@astaweb.com X-Priority: 3 (Normal) Message-ID: <159910904.14157825997042@astaweb.com> To: ccamp-archive@ietf.org Subject: Re:FORMAT A DISK MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Have you ever hoped to have a high dollar Watch? We have the problem solved for you! We sell all the expensive brands for a very small fraction of the price. www.arrijjw.com From owner-ccamp@ops.ietf.org Wed Sep 26 20:02:44 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iagq4-0005ou-0a for ccamp-archive@ietf.org; Wed, 26 Sep 2007 20:02:44 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iagq3-0003tE-C1 for ccamp-archive@ietf.org; Wed, 26 Sep 2007 20:02:43 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IaggM-000KLa-KZ for ccamp-data@psg.com; Wed, 26 Sep 2007 23:52:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=BAYES_00,HTML_MESSAGE, RDNS_NONE,USER_IN_ALL_SPAM_TO autolearn=no version=3.2.1 Received: from [66.226.64.2] (helo=pro.abac.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IaggJ-000KL9-LH for ccamp@ops.ietf.org; Wed, 26 Sep 2007 23:52:40 +0000 Received: from [10.71.1.179] (72-255-26-41.client.stsn.net [72.255.26.41]) (authenticated bits=0) by pro.abac.com (8.14.1/8.14.1) with ESMTP id l8QNfXB9024313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Sep 2007 16:41:37 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <46FAEE2C.5040008@grotto-networking.com> Date: Wed, 26 Sep 2007 16:41:32 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ccamp , pce@ietf.org Subject: Some key issues with Wavelength Switched Optical Networks... Content-Type: multipart/alternative; boundary="------------090500030104070206070906" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 This is a multi-part message in MIME format. --------------090500030104070206070906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi folks, I haven't seen too many comments on our draft "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks" ( http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-01.txt). So I figured I'd point out some potentially controversial issues that the draft brings up. (a) The draft brings up models for the following WDM network elements: 1. WDM links 2. Optical transmitters 3. Wavelength Converters and OEO regenerators 4. ROADMs, FOADMs, optical splitters and combiners. For items (3) and (4) we are taking the modeling lead rather than some other SDO. And for ROADMs, in particular, we going beyond the classic ITU-T "fabric" model (M.3100) which has been the mainstay of any connection oriented switch (TDM, ATM, MPLS). (b) The draft brings up three (not one, not two, but three) different computational models for RWA which can impact GMPLS and PCE protocols: 1. A single PCE computing both the path and wavelength 2. Two distinct PCEs, where one computes the path, and a different PCE computes the wavelength assignment 3. A PCE computes the path and wavelength assignment is accomplished in a distributed fashion via signaling (e.g., using label set objects) Do we really need all three models? (c) G.709 includes the Optical Multiplex Section and Optical Channels. RFC4238 was aimed at GMPLS extensions for G.709 (Optical Transport Network) control. Weren't we finished with all this optical stuff years ago? I'd like to think the draft answers some of these questions. I also think that network element models and the process models are important enough to warrant this separate framework document. Your opinions are solicited. Regards Greg B. -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------090500030104070206070906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi folks, I haven't seen too many comments on our draft "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks" ( http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-01.txt). So I figured I'd point out some potentially controversial issues that the draft brings up.

    (a) The draft brings up models for the following WDM network elements:
    1. WDM links
    2. Optical transmitters
    3. Wavelength Converters and OEO regenerators
    4. ROADMs, FOADMs, optical splitters and combiners.
        For items (3) and (4) we are taking the modeling lead rather than some other SDO.  And for ROADMs, in particular, we going beyond the classic ITU-T "fabric" model (M.3100) which has been the mainstay of any connection oriented switch (TDM, ATM, MPLS).

    (b) The draft brings up three (not one, not two, but three) different computational models for RWA which can impact GMPLS and PCE protocols:
    1. A single PCE computing both the path and wavelength
    2. Two distinct PCEs, where one computes the path, and a different PCE computes the wavelength assignment
    3. A PCE computes the path and wavelength assignment is accomplished in a distributed fashion via signaling (e.g., using label set objects)
        Do we really need all three models?

    (c) G.709 includes the Optical Multiplex Section and Optical Channels.  RFC4238 was aimed at GMPLS extensions for G.709  (Optical Transport Network) control.  Weren't we finished with all this optical stuff years ago?

    I'd like to think the draft answers some of these questions.  I also think that network element models and the process models are important enough to warrant this separate framework document.  Your opinions are solicited.

    Regards

    Greg B.
    -- 
    ===================================================
    Dr Greg Bernstein, Grotto Networking (510) 573-2237
    
    
    --------------090500030104070206070906-- From akstcadvanisharesmnsdgs@advanishares.com Thu Sep 27 01:50:21 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IamGT-0005b6-CL; Thu, 27 Sep 2007 01:50:21 -0400 Received: from [81.215.233.30] (helo=dsl.dynamic8121523330.ttnet.net.tr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IamGM-0003Cn-Li; Thu, 27 Sep 2007 01:50:14 -0400 Received: from [81.215.233.30] by inbound.us.mailhostingserver.com; Thu, 27 Sep 2007 07:49:38 +0200 From: "Barney Major" To: Subject: SCHURE Date: Thu, 27 Sep 2007 07:49:38 +0200 Message-ID: <01c800ca$30d2bc10$1ee9d751@akstcadvanisharesmnsdgs> 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.2900.2527 Importance: Normal X-Spam-Score: 3.3 (+++) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db SHURE www.oprwtts.com Sale on Rolex From owner-ccamp@ops.ietf.org Thu Sep 27 06:02:50 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaqCn-0000lF-QS for ccamp-archive@ietf.org; Thu, 27 Sep 2007 06:02:50 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaqCn-0002b7-2s for ccamp-archive@ietf.org; Thu, 27 Sep 2007 06:02:49 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Iaq0W-000JHI-Uu for ccamp-data@psg.com; Thu, 27 Sep 2007 09:50:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.1 Received: from [192.91.191.4] (helo=smtp.dataconnection.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Iaq0Q-000JEJ-5Q for ccamp@ops.ietf.org; Thu, 27 Sep 2007 09:50:03 +0000 Received: from enfimail2.datcon.co.uk ([172.19.14.250]) by smtp.dataconnection.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Sep 2007 10:49:00 +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: [OSPF] Fwd: Posting of draft-ietf-ospf-ospfv3-traffic-09.txt Date: Thu, 27 Sep 2007 10:48:59 +0100 Message-ID: <52A0FF47062B0B4C80862F2526E02409049197A1@enfimail2.datcon.co.uk> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] Fwd: Posting of draft-ietf-ospf-ospfv3-traffic-09.txt Thread-Index: AcgAR8TFF8MyefNJSeiCAiwv8kJx2gAlOmGA References: <0JOZ003PZ0AKV7@szxga01-in.huawei.com> From: "Alan Davey" To: "Acee Lindem" , "Mach Chen" Cc: "OSPF List" , "Vishwas Manral" , "CCAMP List" X-OriginalArrivalTime: 27 Sep 2007 09:49:00.0468 (UTC) FILETIME=[A15E3740:01C800EB] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Guys Apologies for the late response. =20 I basically agree with Acee. * It makes sense to define a new OSPFv3-TE LSA type to carry the AS connectivity information. I think that this would probably provide a better and more back compatible way to identify the new advertisements than defining a new link type value. * It also makes sense to use the same approach in OSPFv2 and OSPFv3 and so a new OSPFv2 opaque type may be the way to go.=20 My other comments on the draft, from an OSPFv3 TE perspective, are as follows. * On the subject of identifying the other end of the inter-AS link. - The Link ID sub-TLV is not suitable as it SHOULD be ignored on receipt by an OSPFv3 TE implementation. =20 - The Neighbor ID sub-TLV MUST be used instead. This sub-TLV contains the neighbor's interface ID and the neighbor's 32-bit Router ID (note that this is NOT the TE Router ID). - Use of the Neighbor ID sub-TLV requires configuration at the ASBR of the remote ASBR's interface ID and the 32-bit Router ID. - You may want to advertise a global-scope IPv6 address for the router at the other end of an inter-AS link in a Remote Interface IPv6 Address Sub-TLV. This would also need to be configured. * As Acee pointed out, there is currently no OSPFv3 TE equivalent to the Type 11 Opaque LSA, that is, there is no defined LSA for flooding AS scope TE information. * The wording needs to be changed for OSPFv3 TE when describing the contents of a "proxy" advertisement for the backward direction of an inter-AD TE link. Regards Alan Davey ------------------------------------ Alan Davey Data Connection Ltd Tel: +44 20 8366 1177 Fax: +44 20 8363 1039 Email: Alan.Davey@dataconnection.com Web: http://www.dataconnection.com > -----Original Message----- > From: Acee Lindem [mailto:acee@redback.com]=20 > Sent: 26 September 2007 15:15 > To: Mach Chen > Cc: OSPF List; Vishwas Manral; Alan Davey; CCAMP List > Subject: Re: [OSPF] Fwd: Posting of=20 > draft-ietf-ospf-ospfv3-traffic-09.txt >=20 > Hi Mach, >=20 > On Sep 26, 2007, at 6:10 AM, Mach Chen wrote: >=20 > > Hi Acee, > > > > Pls see inline > > > > > > On 2007-09-25, at 21:05:49 Acee Lindem wrote: > > > >> Hi Mach, > >> Thanks for reviewing. > >> > >> On Sep 25, 2007, at 4:24 AM, Mach Chen wrote: > >> > >>> Hi Acee and other authors, > >>> > >>> > >>> > >>> Some questions to ospfv3-traffic > >>> > >>> > >>> > >>> 1. In this ospfv3-traffic document, a new LSA, Intra-Area-TE > >>> LSA, is defined to advertise IPv6 TE information. From=20 > name of this=20 > >>> new LSA, IMHO, it is limited to be used for Intra-Area TE=20 > only. So,=20 > >>> if there are some underlying extensions to ospfv3-traffic, e.g. > >>> Inter-AS TE, it is a little bit strange to re-use the=20 > Intra-Area-TE=20 > >>> LSA, or it has to define a new LSA. So, can we change its name to=20 > >>> something like "OSPFv3 TE LSA"? > >> It would be if we had intended it to carry AS wide information. > >> However, it was not initially intended for this. The=20 > initial thought=20 > >> was that we would do a better job for OSPFv3 and define=20 > separate LSA=20 > >> types for intra-area, inter-area, and AS external TE LSAs.=20 > Thoughts=20 > >> on this (copied ccamp as well)? > > > > So, the conclusion is that a new LSA(may be called Inter-AS-TE LSA)=20 > > has to be defined for advertising inter-AS TE information=20 > in support=20 > > of OSPFv3 TE, am I right? > > > >> I guess, IMHO, this discrepancy > >> exposes the choice of a new link type for inter-AS=20 > connectivity as a=20 > >> bit of a hack. > >> > > > > For OSPFv3 TE(separate LSAs are used) is YES. But as to OSPFv2 TE,=20 > > IMHO, there should be a new link type to identify an=20 > inter-AS link, or=20 > > we need another new LSA. >=20 >=20 > It seems to me that if we do add the link in your draft, then=20 > it should be done the same in OSPFv2 and OSPFv3. Advertising=20 > it as a new link type is one way to advertise inter-AS=20 > connectivity. However, it isn't necessarily a link. This=20 > seems to me to be more of a semantical discrepancy than the=20 > name of the LSA. In section 4, I notice that at least for=20 > OSPFv2 the draft says the new link may be advertised in=20 > either a type 11 opaque LSA or type 10 opaque LSA. Given the=20 > maturity of RFC 3630, it almost seems to me that we should=20 > allocate a new LSA opaque type for this purpose. >=20 > What is the status of draft-ietf-ccamp-ospf-interas-te-=20 > extension-01.txt? I know at the OSPF meeting there were a=20 > number of people who questioned whether or not it was necessary. >=20 > Thanks, > Acee >=20 >=20 >=20 >=20 >=20 > > > >> > >> > >>> > >>> > >>> 2. Section 2. > >>> > >>> "The format of the TLVs within the body of a router=20 > information LSA=20 > >>> is the same as the format used by the Traffic Engineering=20 > Extensions=20 > >>> to OSPF [TE]." > >>> > >>> > >>> > >>> What's "a router information LSA"? Or should it be "an=20 > Intra-Area-=20 > >>> TE LSA" ? > >> > >> Yes. Good catch. I'll fix this. > > > > Thanks. > > > >> > >> Thanks, > >> Acee > > > > > > Best regards, =09 > > Mach Chen > > >=20 >=20 From Gorinich@speedydomainregistration.com Thu Sep 27 08:37:58 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iascw-0003NC-06 for ccamp-archive@ietf.org; Thu, 27 Sep 2007 08:37:58 -0400 Received: from 87-126-114-178.btc-net.bg ([87.126.114.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iascg-0006yD-6k for ccamp-archive@ietf.org; Thu, 27 Sep 2007 08:37:42 -0400 Received: from somat by speedydomainregistration.com with ASMTP id 72688905 for ; Thu, 27 Sep 2007 15:38:04 +0300 Received: from somat ([131.169.48.126]) by speedydomainregistration.com with ESMTP id 3358C372C164 for ; Thu, 27 Sep 2007 15:38:04 +0300 Message-ID: Date: Thu, 27 Sep 2007 15:37:50 +0300 From: "darwin Gorinich" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: aps-ynam Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Yo yo yo ccamp-archive here is how to score all the ladies... darwin Gorinich http://www.mirujula.com/ From AvaGrigor@akenclark.com Thu Sep 27 09:20:09 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IatHl-0005Ln-Bk for ccamp-archive@megatron.ietf.org; Thu, 27 Sep 2007 09:20:09 -0400 Received: from cust.cito512.806592-162.bih.net.ba ([80.65.92.162]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IatHX-0005oh-0y for ccamp-archive@megatron.ietf.org; Thu, 27 Sep 2007 09:20:03 -0400 Received: by 10.30.172.41 with SMTP id JMJHbxhFyyILN; Thu, 27 Sep 2007 15:19:28 +0200 (GMT) Received: by 192.168.67.69 with SMTP id jVLtIqpWruDZIj.4707500902692; Thu, 27 Sep 2007 15:19:26 +0200 (GMT) Message-ID: <000301c80109$058a6af0$a25c4150@JAV4> From: "Ava Grigor" To: Subject: formasse Date: Thu, 27 Sep 2007 15:19:23 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C80119.C9133AF0" 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.8 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0004_01C80119.C9133AF0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable http://gilltete.com/ Hi there ccamp-archive ladies like em big, so i enlarged my cock just to please them.. Ava Grigor ------=_NextPart_000_0004_01C80119.C9133AF0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
    http://gilltete.com/
    Hi there ccamp-archive
    ladies like em big, so i enlarged my cock just = to please them..
    Ava Grigor
    ------=_NextPart_000_0004_01C80119.C9133AF0-- From owner-ccamp@ops.ietf.org Thu Sep 27 09:31:12 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IatSS-0005V0-Nc for ccamp-archive@ietf.org; Thu, 27 Sep 2007 09:31:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IatSR-0006CB-GD for ccamp-archive@ietf.org; Thu, 27 Sep 2007 09:31:12 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IatDZ-000Ejq-Pz for ccamp-data@psg.com; Thu, 27 Sep 2007 13:15:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [212.23.3.27] (helo=doppler.zen.co.uk) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IatDW-000EjX-UW for ccamp@ops.ietf.org; Thu, 27 Sep 2007 13:15:48 +0000 Received: from [212.23.3.141] (helo=heisenberg.zen.co.uk) by doppler.zen.co.uk with esmtp (Exim 4.50) id 1IatDW-0003FZ-0q for ccamp@ops.ietf.org; Thu, 27 Sep 2007 13:15:46 +0000 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1IatDU-0004Bh-Pr for ccamp@ops.ietf.org; Thu, 27 Sep 2007 13:15:44 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Sep 2007 14:15:44 +0100 Message-ID: <01ce01c80108$8122b240$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Magnus Westerlund" Subject: Fw: Guidelines for protocol designers using UDP Date: Thu, 27 Sep 2007 14:15:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 27 Sep 2007 13:15:44.0489 (UTC) FILETIME=[82BD9D90:01C80108] X-Originating-Heisenberg-IP: [88.96.235.138] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Hi, Those of you who are LMP implementers and deployers may want to look at this I-D and make comments: - on the I-D direct to the tsvwg - on RFC4204 to CCAMP Thanks, Adrian ----- Original Message ----- From: "Magnus Westerlund" To: "Internet Area" ; ; ; ; "SAAG" Cc: "tsvwg" Sent: Thursday, September 27, 2007 12:33 PM Subject: Guidelines for protocol designers using UDP > Hi, > > In the TSVWG we have been developing a guidelines document for UDP. It > is intended for protocol designers that consider using UDP in their > protocol. We do hope that it will help remove some of the misconception > that UDP is a simple protocol to use. It might look that way because > most of the features necessary for being acceptable to deploy on the > general internet needs to be specified by the one using UDP. It is also > something that the Transport ADs already started using as help in > explaining why and what to fix when we put a DISCUSS on your document > that is using UDP. > > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-udp-guidelines-03.txt > > So TSVWG is still working on this document but we are now considering it > quite complete. So we are looking for feedback from you. Are there > things that are unclear, missing, wrong, etc. Please provide your > feedback to TSVWG (tsvwg@ietf.org). > > Thanks > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From blaise@mixmail.com Thu Sep 27 11:54:59 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iavhb-0005yR-ER for ccamp-archive@ietf.org; Thu, 27 Sep 2007 11:54:59 -0400 Received: from cm72.omega88.maxonline.com.sg ([218.186.88.72]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iavha-0005rV-EM for ccamp-archive@ietf.org; Thu, 27 Sep 2007 11:54:59 -0400 Received: from [218.186.88.72] by dns.ya.com; Thu, 27 Sep 2007 15:54:55 +0000 Message-ID: <000501c8011e$016a48f3$fb7f03b8@lxnacueb> From: "laird cloud" To: Subject: Best investment opportunity. Your chance to multiply your invest. Date: Thu, 27 Sep 2007 14:07:33 +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.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 1.6 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Hello Investor We are pleased to invite you to an excellent investment opportunity. Make your money work today and tomorrow you will start to receive profits. In connection with a mortgage crisis in the real estate of the USA market, bank deposits became risky; investments in investment funds do not provide the desired return. Stock markets fall. Stop depend on the dollar rate and invest your money in a high profit financial instruments. Since the beginning of the year the American currency has lost about 15%, and it continues to fall. For The United States stock market is not the best time. Europe is also facing an economic crisis. In the difficult times of economic chaos you have to look for other investment instruments. Our investment company offers high profit investments with maximum impact. We are working on the market since 2005 and during the work we confirmed our impeccable reputation with regular payments and the performance of our profitability. Our clients receive 350% annual returns. We accept any amount of investments, and you can invest a small amount so as to see the quality of our work. We make our profit by day-trading on the American stock and bonds market. So, we are ready to provide individual Trading Platform for our clients. And you have an excellent opportunity to try your forces in the day-trading. Our best specialists will be pleased to provide you with investment advice and help you to choose an investment portfolio, which will be fully compatible with the chosen level of risk and return. If you are interested in this proposal please contact your personal manager to: BenMeadowsNF@gmail.com If you received this message in error please send a blank email to: ShermanFaulknerJF@gmail.com From Ketterer@bradenconstruction.com Thu Sep 27 13:24:06 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iax5q-0005eC-OJ for ccamp-archive@ietf.org; Thu, 27 Sep 2007 13:24:06 -0400 Received: from e180244092.adsl.alicedsl.de ([85.180.244.92]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iax5e-00005K-2U for ccamp-archive@ietf.org; Thu, 27 Sep 2007 13:23:54 -0400 Received: from michputer ([152.126.160.144] helo=michputer) by e180244092.adsl.alicedsl.de ( sendmail 8.13.3/8.13.1) with esmtpa id 1iJFoT-000CEV-LM for ccamp-archive@ietf.org; Thu, 27 Sep 2007 19:21:18 +0200 Message-ID: <000c01c8012a$ba8dd290$5cf4b455@michputer> From: "necdet Ketterer" To: Subject: strontit Date: Thu, 27 Sep 2007 19:20:41 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C8013B.7E182930" 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_0007_01C8013B.7E182930 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.mjespace.com/ Good night ccamp-archive Unsatisfied with your penis size? necdet Ketterer ------=_NextPart_000_0007_01C8013B.7E182930 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    http://www.mjespace.com/
    Good night ccamp-archive
    Unsatisfied with your penis size?
    necdet Ketterer
    ------=_NextPart_000_0007_01C8013B.7E182930-- From fazeel@mooo.nl Thu Sep 27 14:52:46 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IayTe-00050f-JL for ccamp-archive@megatron.ietf.org; Thu, 27 Sep 2007 14:52:46 -0400 Received: from arennes-357-1-116-29.w90-12.abo.wanadoo.fr ([90.12.99.29] helo=ARennes-357-1-106-157.w90-12.abo.wanadoo.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IayTS-0003GI-Mz for ccamp-archive@megatron.ietf.org; Thu, 27 Sep 2007 14:52:35 -0400 Received: by 10.130.171.85 with SMTP id ZffqMRuToBnnf; Thu, 27 Sep 2007 20:52:59 +0200 (GMT) Received: by 192.168.9.19 with SMTP id zCrHudHKwmSlGZ.1139904003595; Thu, 27 Sep 2007 20:52:57 +0200 (GMT) Message-ID: <000c01c80137$9c921eb0$9d590c5a@a39acd8dadd749a> From: "fazeel luc" To: Subject: nekkerpo Date: Thu, 27 Sep 2007 20:52:54 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C80148.601AEEB0" 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 000777-1, 26/09/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 3.5 (+++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0003_01C80148.601AEEB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.chbit.com/ Wassup ccamp-archive All i want for christmas is a big phat pe@nis to please my girl fazeel luc ------=_NextPart_000_0003_01C80148.601AEEB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    http://www.chbit.com/
    Wassup ccamp-archive
    All i want for christmas is a big phat pe@nis = to please=20 my girl
    fazeel luc
    ------=_NextPart_000_0003_01C80148.601AEEB0-- From owner-ccamp@ops.ietf.org Thu Sep 27 15:43:20 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IazGa-0002KT-OK for ccamp-archive@ietf.org; Thu, 27 Sep 2007 15:43:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IazGZ-0000bB-Hn for ccamp-archive@ietf.org; Thu, 27 Sep 2007 15:43:20 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Iaz8P-00064H-Sy for ccamp-data@psg.com; Thu, 27 Sep 2007 19:34:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [212.23.3.141] (helo=heisenberg.zen.co.uk) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Iaz8N-00063u-7T for ccamp@ops.ietf.org; Thu, 27 Sep 2007 19:34:52 +0000 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1Iaz8K-0006Tj-6A for ccamp@ops.ietf.org; Thu, 27 Sep 2007 19:34:48 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Sep 2007 20:34:47 +0100 Message-ID: <02f801c8013d$74ed4a00$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Hamid Ould-Brahim" , Subject: Fw: Four L1VPN working group last calls Date: Thu, 27 Sep 2007 20:34:36 +0100 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.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 27 Sep 2007 19:34:47.0899 (UTC) FILETIME=[76DE92B0:01C8013D] X-Originating-Heisenberg-IP: [88.96.235.138] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Hi CCAMP working group, The L1VPN working group is holding a last call on several drafts. This is clearly all related to the work of CCAMP and we would welcome any further thoughts during the last call. By preference, please send comments to the L1VPN list, but anything sent to the CCAMP list will be forwarded. Thanks, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Thursday, September 27, 2007 8:17 PM Subject: [L1vpn] Four working group last calls > Hi, > > Now that there is a bit of peace and quiet on the CCAMP last calls, we > would like to hold L1VPN last calls on four I-Ds: > > http://www.ietf.org/internet-drafts/draft-ietf-l1vpn-applicability-basic-mode-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-l1vpn-basic-mode-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-l1vpn-bgp-auto-discovery-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-l1vpn-ospf-auto-discovery-03.txt > > Since there are four drafts, we will make this a three week last call. It > will complete at 12 noon GMT on 18th October 2007. > > We will be notifying the IDR, OSPF, and CCAMP working groups about this > last call. > > Thanks, > Adrian, Hamid, and Tomonori > > > _______________________________________________ > L1vpn mailing list > L1vpn@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/l1vpn > From baillio@ambthair.com Thu Sep 27 15:43:24 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IazGe-0001Oa-BE; Thu, 27 Sep 2007 15:43:24 -0400 Received: from abordeaux-256-1-163-240.w86-201.abo.wanadoo.fr ([86.201.18.240]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IazGD-0004fx-IQ; Thu, 27 Sep 2007 15:42:57 -0400 Received: from [86.201.18.240] by relay2.pncl.co.uk; Thu, 27 Sep 2007 20:42:55 +0100 Message-ID: <01c8013e$995b8090$f012c956@baillio> From: "Casey Webster" To: Subject: Do it right Date: Thu, 27 Sep 2007 20:42:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2173.0 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Have you ever wished for a pricey Watch? We have the problem solved for you! We carry all the big names for a low precentage of the expense. www.arriehuu.com From owner-ccamp@ops.ietf.org Thu Sep 27 18:43:14 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib24g-0004Zv-Ju for ccamp-archive@ietf.org; Thu, 27 Sep 2007 18:43:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ib24a-0004Tg-4b for ccamp-archive@ietf.org; Thu, 27 Sep 2007 18:43:14 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Ib1xF-000PMM-L9 for ccamp-data@psg.com; Thu, 27 Sep 2007 22:35:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=BAYES_00,HTML_MESSAGE, RDNS_NONE,USER_IN_ALL_SPAM_TO autolearn=no version=3.2.1 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Ib1xB-000PLr-2Q for ccamp@ops.ietf.org; Thu, 27 Sep 2007 22:35:31 +0000 X-IronPort-AV: E=Sophos;i="4.21,205,1188770400"; d="scan'208,217";a="154359577" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 28 Sep 2007 00:35:28 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8RMZRPh023440; Fri, 28 Sep 2007 00:35:27 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8RMZRWo018762; Thu, 27 Sep 2007 22:35:27 GMT Received: from xmb-ams-338.cisco.com ([144.254.231.83]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Sep 2007 00:35:27 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80156.B32B3353" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Pce] Some key issues with Wavelength Switched Optical Networks... Date: Fri, 28 Sep 2007 00:36:52 +0200 Message-ID: <1F2FBF50FB955441A11316BAE835CED4042D142B@xmb-ams-338.emea.cisco.com> In-Reply-To: <46FAEE2C.5040008@grotto-networking.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Some key issues with Wavelength Switched Optical Networks... Thread-Index: AcgAl5KnD0dbOEQxQX+EILfgiGPP2AAvoJ3A From: "Giovanni Martinelli (giomarti)" To: "Greg Bernstein" , "ccamp" , X-OriginalArrivalTime: 27 Sep 2007 22:35:27.0093 (UTC) FILETIME=[B3885250:01C80156] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12905; t=1190932527; x=1191796527; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=giomarti@cisco.com; z=From:=20=22Giovanni=20Martinelli=20(giomarti)=22=20 |Subject:=20RE=3A=20[Pce]=20Some=20key=20issues=20with=20Wavelength=20Swi tched=20Optical=20Networks... |Sender:=20; bh=DVSVM/lyQYCVwvpXDNQvzMD7PDXvhPJ3F+kbzoEhFv8=; b=RiTZRfNKJeM8Wya4YGaAZCDzSqMsjswHoSEQlpz1f8IuKENELSo5qMGQKS00VwQaWic6Nwzu wevg9lvRVaR1WCJJcnIMVz4I2GzPNQmCmztuSrhvJHlbl4IxH1A4WfK7; Authentication-Results: ams-dkim-1; header.From=giomarti@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c This is a multi-part message in MIME format. ------_=_NextPart_001_01C80156.B32B3353 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Greg, =20 Sorry for the delay in replying. I'm working on this topic since a while = so yes, it's interesting. Before going on specific issue I would have = some question/clarification regarding the draft itself.=20 =20 =20 * Within Abstract and the following. You don't talk about Optical Cross Connects (OXC) is something missing = or understated somewhere? =20 =20 * Section 3.1 where you state:=20 "A fixed mapping between the=20 GMPLS label space and these ITU-T WDM grids as proposed in [Otani] " Does it implies a sort of network level label space? How relate with = usual local label significance? =20 =20 * Section 3.4 Wavelength Converters=20 "Current or envisioned contexts for wavelength converters are : ..." Could we think to a description/model for wavelength converter that is = technology agnostic? Simply something like: full conversion capability, = partial conversion capability with some constrains, and may be others. =20 =20 * Section 3.4. the following:=20 "4. Wavelength converters that are O-E-O based will have a restriction=20 based on the modulation format and transmission speed"=20 Not clear to me the type of restriction here when OEO happens... = probably I'm missing what you mean here. =20 =20 * Section 4.1 when you talk about Lightpath temporal characteristics: "Lightpath connection duration has typically been thought of as=20 approximately three time frames: "=20 and the following you define: dynamics, pseudo-static, static. Why there's a need of this classification? When you us Short/long is = compared to what? =20 =20 minor typo on your mail below: point (c) rfc4328 (not 4238) right? =20 Thanks, Giovanni =20 ________________________________ From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: gioved=EC 27 settembre 2007 1.42 To: ccamp; pce@ietf.org Subject: [Pce] Some key issues with Wavelength Switched Optical = Networks... =09 =09 Hi folks, I haven't seen too many comments on our draft "Framework for = GMPLS and PCE Control of Wavelength Switched Optical Networks" ( = http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swit= ched-01.txt). So I figured I'd point out some potentially controversial = issues that the draft brings up.=20 =09 (a) The draft brings up models for the following WDM network elements: =09 1. WDM links=20 2. Optical transmitters =09 3. Wavelength Converters and OEO regenerators=20 4. ROADMs, FOADMs, optical splitters and combiners.=20 For items (3) and (4) we are taking the modeling lead rather than = some other SDO. And for ROADMs, in particular, we going beyond the = classic ITU-T "fabric" model (M.3100) which has been the mainstay of any = connection oriented switch (TDM, ATM, MPLS). =09 (b) The draft brings up three (not one, not two, but three) different = computational models for RWA which can impact GMPLS and PCE protocols: =09 1. A single PCE computing both the path and wavelength=20 2. Two distinct PCEs, where one computes the path, and a different PCE = computes the wavelength assignment=20 3. A PCE computes the path and wavelength assignment is accomplished in = a distributed fashion via signaling (e.g., using label set objects)=20 Do we really need all three models? =09 (c) G.709 includes the Optical Multiplex Section and Optical Channels. = RFC4238 was aimed at GMPLS extensions for G.709 (Optical Transport = Network) control. Weren't we finished with all this optical stuff years = ago? =09 I'd like to think the draft answers some of these questions. I also = think that network element models and the process models are important = enough to warrant this separate framework document. Your opinions are = solicited. =09 Regards =09 Greg B. =09 --=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 =09 ------_=_NextPart_001_01C80156.B32B3353 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Hi = Greg,
     
    Sorry for the=20 delay in replying. I'm working on this topic since a while so yes, it's=20 interesting. Before going on specific issue I would have some=20 question/clarification regarding the draft itself.
     
     
    * Within = Abstract and=20 the following.
    You = don't talk about=20 Optical Cross Connects (OXC) is something missing or understated=20 somewhere?
     
     
    * = Section 3.1=20 where you state:
    "A = fixed mapping=20 between the
    GMPLS = label space and=20 these ITU-T WDM grids as proposed in [Otani] "
    Does it = implies a sort=20 of network level label space? How relate with usual local label=20 significance?
     
     
    * = Section 3.4=20 Wavelength Converters
    "Current = or envisioned=20 contexts for wavelength converters are : ..."
    Could = we think to a description/model for = wavelength=20 converter that is technology agnostic? Simply=20 something like: full conversion capability, partial conversion = capability=20 with some constrains, and may be others.
     
     
    * = Section 3.4. the=20 following:
    "4. Wavelength=20 converters that are O-E-O based will have a restriction =
    based on the=20 modulation format and transmission speed"
    Not = clear to me the type=20 of restriction here when OEO happens... probably I'm missing what you = mean=20 here.
     
     
    * = Section 4.1 when you=20 talk about Lightpath temporal characteristics:
    "Lightpath=20 connection duration has typically been thought of as =
    approximately=20 three time frames: "
    and the = following you=20 define: dynamics, pseudo-static, static.
    Why = there=92s a need of=20 this classification? When you us Short/long is compared to = what?
     
     
    minor typo on your mail below: point (c) rfc4328 (not 4238)=20 right?
     
    Thanks,
    Giovanni


     


    From: Greg Bernstein=20 [mailto:gregb@grotto-networking.com]
    Sent: gioved=EC 27 = settembre=20 2007 1.42
    To: ccamp; pce@ietf.org
    Subject: [Pce] = Some key=20 issues with Wavelength Switched Optical = Networks...

    Hi folks, I haven't seen too many comments on our draft = "Framework=20 for GMPLS and PCE Control of Wavelength Switched Optical Networks" ( = http://www.ietf.org/internet-drafts/draft-bernstein-= ccamp-wavelength-switched-01.txt).=20 So I figured I'd point out some potentially controversial issues that = the=20 draft brings up.

    (a) The draft brings up models for the = following WDM=20 network elements:
    1. WDM links=20
    2. Optical transmitters
    3. Wavelength Converters and OEO regenerators=20
    4. ROADMs, FOADMs, optical splitters and combiners.=20
        For items (3) and (4) we are taking the = modeling=20 lead rather than some other SDO.  And for ROADMs, in particular, = we going=20 beyond the classic ITU-T "fabric" model (M.3100) which has been the = mainstay=20 of any connection oriented switch (TDM, ATM, MPLS).

    (b) The = draft=20 brings up three (not one, not two, but three) different computational = models=20 for RWA which can impact GMPLS and PCE protocols:
    1. A single PCE computing both the path and wavelength=20
    2. Two distinct PCEs, where one computes the path, and a different = PCE=20 computes the wavelength assignment=20
    3. A PCE computes the path and wavelength assignment is = accomplished in a=20 distributed fashion via signaling (e.g., using label set objects)=20
        Do we really need all three = models?

    (c)=20 G.709 includes the Optical Multiplex Section and Optical = Channels. =20 RFC4238 was aimed at GMPLS extensions for G.709  (Optical = Transport=20 Network) control.  Weren't we finished with all this optical = stuff years=20 ago?

    I'd like to think the draft answers some of these = questions. =20 I also think that network element models and the process models are = important=20 enough to warrant this separate framework document.  Your = opinions are=20 solicited.

    Regards

    Greg B.
    --=20
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
    =3D
    Dr Greg Bernstein, Grotto Networking (510) 573-2237
    
    
    ------_=_NextPart_001_01C80156.B32B3353-- From markhuu-shipman@berkeling.nl Fri Sep 28 01:04:34 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib81i-0004Pw-Nx for ccamp-archive@megatron.ietf.org; Fri, 28 Sep 2007 01:04:34 -0400 Received: from dialup-gulshan-182.bdonline.com ([203.190.35.248]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ib81e-0001lm-AQ for ccamp-archive@megatron.ietf.org; Fri, 28 Sep 2007 01:04:34 -0400 Received: from abc ([185.144.102.8] helo=abc) by [203.190.35.248] ( sendmail 8.13.3/8.13.1) with esmtpa id 1lQJBA-000LUC-za for ccamp-archive@megatron.ietf.org; Fri, 28 Sep 2007 11:04:54 +0600 Message-ID: <7B3E7175.3CC9EAAA@berkeling.nl> Date: Fri, 28 Sep 2007 11:04:27 +0600 From: "markhuu shipman" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ccamp-archive@megatron.ietf.org Subject: aprilgek Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Mining Sector --- Delta Mining UPDATE HOT SECTOR: Additional information on (O_T_C: D M X C) D M X C is expected to arrive soon. For those of you who currently own this company this will be great news. For those that don't currently own this company, you need to get in on this now. The company recently traded as high as .13 and with any significant news should be able to see (if not exceed) those prices again. Contact your broker now, don't miss this opportunity in D M X C! From badders@asg-architects.com Fri Sep 28 05:20:43 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbC1b-0004Xq-28; Fri, 28 Sep 2007 05:20:43 -0400 Received: from [81.213.136.13] (helo=dsl.dynamic8121313613.ttnet.net.tr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbC1W-00005t-Ku; Fri, 28 Sep 2007 05:20:38 -0400 Received: from [81.213.136.13] by MAIL.GLOBAL.FRONTBRIDGE.com; Fri, 28 Sep 2007 11:19:01 +0200 From: "Gerardo Albert" To: Subject: No one will know Date: Fri, 28 Sep 2007 11:19:01 +0200 Message-ID: <01c801b0$9b5e2790$0d88d551@badders> 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.2180 Importance: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Have you ever wished for a expensive Watch? We have the piece for you! We sell all the high scale for a very small fraction of the price. www.speoewkk.com From kairies@heftruckcentrale.nl Fri Sep 28 07:47:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbEJB-0006rh-2d for ccamp-archive@megatron.ietf.org; Fri, 28 Sep 2007 07:47:01 -0400 Received: from 71.1.220.87.dynamic.jazztel.es ([87.220.1.71] helo=[87.220.1.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbEJ3-0003i9-V6 for ccamp-archive@megatron.ietf.org; Fri, 28 Sep 2007 07:46:54 -0400 Received: from Portatil ([176.155.0.15] helo=Portatil) by [87.220.1.33] ( sendmail 8.13.3/8.13.1) with esmtpa id 1xAKpH-000EBO-xq for ccamp-archive@megatron.ietf.org; Fri, 28 Sep 2007 13:47:22 +0200 Message-ID: <000b01c801c5$4776c410$2101dc57@Portatil> From: "Cang kairies" To: Subject: amayut Date: Fri, 28 Sep 2007 13:46:59 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C801D6.0AFF9410" 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.7 (+) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 ------=_NextPart_000_0003_01C801D6.0AFF9410 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mining Sector --- Delta Mining UPDATE HOT SECTOR: Additional information on (O_T_C: D M X C) D M X C is = expected to arrive soon. For those of you who currently own this company this will be great news. For those that don't currently own this company, you need to get in on = this now. The company recently traded as high as .13 and with any significant news = should be able to see (if not exceed) those prices again. Contact your broker now, = don't miss this opportunity in D M X C! ------=_NextPart_000_0003_01C801D6.0AFF9410 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Mining Sector --- Delta Mining = UPDATE
    HOT SECTOR: Additional information on (O_T_C: = D M X C) D=20 M X C is expected to arrive soon.
    For those of you who currently own this = company this=20 will be great news.
    For those that don't currently own this = company, you=20 need to get in on this now.
    The company recently traded as high as .13 and = with any=20 significant news should be able
    to see (if not exceed) those prices again. = Contact your=20 broker now, don't miss this
    opportunity in D M X = C!
    ------=_NextPart_000_0003_01C801D6.0AFF9410-- From Cesiliecarstens@FEDERICOPRATO.COM.AR Fri Sep 28 07:59:44 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbEVU-0003BI-1d for ccamp-archive@ietf.org; Fri, 28 Sep 2007 07:59:44 -0400 Received: from host131-162-static.28-87-b.business.telecomitalia.it ([87.28.162.131] helo=host133-162-static.28-87-b.business.telecomitalia.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbEVL-00041E-3r for ccamp-archive@ietf.org; Fri, 28 Sep 2007 07:59:35 -0400 Received: from PC12 by FEDERICOPRATO.COM.AR with ASMTP id BDC593C6 for ; Fri, 28 Sep 2007 13:59:23 +0200 Received: from PC12 ([182.153.180.106]) by FEDERICOPRATO.COM.AR with ESMTP id 20FBEB43C7C4 for ; Fri, 28 Sep 2007 13:59:23 +0200 Message-ID: <000401c801c6$f89c14b0$85a21c57@PC12> From: "Cesilie carstens" To: Subject: iccillep Date: Fri, 28 Sep 2007 13:59:06 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C801D7.BC24E4B0" 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.7 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0006_01C801D7.BC24E4B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://ghostorg.com/ regards ccamp-archive Ladies, here is the ultimate gift for your men, used by p0rnstarrs = worldwide Cesilie carstens ------=_NextPart_000_0006_01C801D7.BC24E4B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    http://ghostorg.com/
    regards ccamp-archive
    Ladies, here is the ultimate gift for your = men, used by=20 p0rnstarrs worldwide
    Cesilie carstens
    ------=_NextPart_000_0006_01C801D7.BC24E4B0-- From turpinhmtm@SEX-MIX.RU Fri Sep 28 08:17:40 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbEmq-0000xf-Cu for ccamp-archive@ietf.org; Fri, 28 Sep 2007 08:17:40 -0400 Received: from [151.63.186.219] (helo=[151.63.186.219]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbEmh-0004PA-MG for ccamp-archive@ietf.org; Fri, 28 Sep 2007 08:17:32 -0400 Received: by 10.86.24.209 with SMTP id FlXjCJnAHIYaU; Fri, 28 Sep 2007 14:20:10 +0200 (GMT) Received: by 192.168.86.221 with SMTP id KKsdQyzMDklPAj.7405751329799; Fri, 28 Sep 2007 14:20:08 +0200 (GMT) Message-ID: <000d01c801c9$e73fee00$dbba3f97@sandrini77a512> From: "IRINA turpin" To: Subject: s{{ti|it Date: Fri, 28 Sep 2007 14:20:05 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C801DA.AAC8BE00" 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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 ------=_NextPart_000_0005_01C801DA.AAC8BE00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable M,ining Sec tor ---+- Delt a Min,ing UPDA,TE H,O.T SE CTOR: Ad,diti'onal informa'ti-on on (O_T_,C: DMX,C) D*M.X'C is = ex*p ected to a'rrive s,o*o'n-. F o,r th_ose of y_o u w,h+o cur*rent ly o.w,n t h+i.s c,ompany t.h+i.s = w'i l l be g+reat n_e-w's'. F_o*r th ose t_h-a't d_on't current'l y o'w*n t.h_i s comp-a ny, y'o*u = n,e-e-d to g e.t in on t*h'i-s n'o_w-. T h*e compa_ny re'centl,y trade'd as h+i_g+h as . 1*3 a*n.d w,i_t h a = n*y s'ignif+icant n'e*w*s sho,uld be a'b_l-e to s'e e (_i'f n_o t exc_eed) t-hose price_s agai'n. Con*tact y'o*u'r = broke_r n,o-w', don.'t m,i_s.s t'h i*s opport_uni'ty in D.M,X*C*! ------=_NextPart_000_0005_01C801DA.AAC8BE00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    M,ining Sec tor ---+- Delt a Min,ing UPDA,TE =
    H,O.T SE CTOR: Ad,diti'onal informa'ti-on on = (O_T_,C:=20 DMX,C) D*M.X'C is ex*p ected to a'rrive s,o*o'n-.
    F o,r th_ose of y_o u w,h+o cur*rent ly o.w,n = t h+i.s=20 c,ompany t.h+i.s w'i l l be g+reat n_e-w's'.
    F_o*r th ose t_h-a't d_on't current'l y o'w*n = t.h_i s=20 comp-a ny, y'o*u n,e-e-d to g e.t in on t*h'i-s n'o_w-.
    T h*e compa_ny re'centl,y trade'd as h+i_g+h = as . 1*3=20 a*n.d w,i_t h a n*y s'ignif+icant n'e*w*s sho,uld be a'b_l-e =
    to s'e e (_i'f n_o t exc_eed) t-hose price_s = agai'n. C on*tact y'o*u'r broke_r n,o-w', don.'t m,i_s.s t'h i*s
    opport_uni'ty in D.M,X*C*! =
    ------=_NextPart_000_0005_01C801DA.AAC8BE00-- From akstcachetenlignemnsdgs@achetenligne.com Fri Sep 28 09:31:20 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbFw8-0002EU-Nb; Fri, 28 Sep 2007 09:31:20 -0400 Received: from opt-125-215-107-33.client.pikara.ne.jp ([125.215.107.33] helo=FM-286072627) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbFw4-0000Cc-V8; Fri, 28 Sep 2007 09:31:18 -0400 Received: from [125.215.107.33] by achetenligne.com; Fri, 28 Sep 2007 22:29:58 +0900 Date: Fri, 28 Sep 2007 22:29:58 +0900 From: "Reynaldo Porter" X-Mailer: The Bat! (v2.10.03) Educational Reply-To: akstcachetenlignemnsdgs@achetenligne.com X-Priority: 3 (Normal) Message-ID: <418900515.76244705222551@achetenligne.com> To: ccamp-archive@ietf.org Subject: SWIMMID MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Score: 4.5 (++++) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db EARDEOR http://ppwllk.com life without a watch From oylo4vvti@egroups.com Fri Sep 28 09:44:47 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbG99-00032U-KN; Fri, 28 Sep 2007 09:44:47 -0400 Received: from 85.red-88-14-173.dynamicip.rima-tde.net ([88.14.173.85]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IbG8i-00076z-Ko; Fri, 28 Sep 2007 09:44:21 -0400 To: ldapext-archive@ietf.org From: "Dionne Rosaura" Subject: Rep1icaRolex, Omega, Cartier, IWC, Swiss QualityWatches usedto Message-ID: <008u42084.10951e04625043@soundrevolution.net> Date: Fri, 28 Sep 2007 08:44:14 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--rkmuyfvalqmy41s4pq8pczvjk56ko1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 ----rkmuyfvalqmy41s4pq8pczvjk56ko1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Super Branded Watches (85% Price Off) : RolexMen : RolexLady : Alain Silberstein : Audemars Piguet : Breitling : Bvlgari : Cartier : Chanel : Chopard : Franck Muller : IWC : Jaeger-Lecoultre : Omega : Panerai Luminor : Patek Philippe : Tag Heuer Only from $189 Each :- Click below link http://rjkpnu.lknketchi.com http://ruha.lknketchi.com ----rkmuyfvalqmy41s4pq8pczvjk56ko1 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
    Super Branded Watches (85% Price Off)
    RolexMen
    RolexLady
    Alain Silberstein
    Audemars Piguet
    Breitling
    Bvlgari
    Cartier
    Chanel
    Chopard
    Franck Muller
    IWC
    Jaeger-Lecoultre
    Omega
    Panerai Luminor
    Patek Philippe
    Tag Heuer
    Only from $189 Each :- Click below link
    [Link 1]     [Link 2]

    besides god repeated science.
    ----rkmuyfvalqmy41s4pq8pczvjk56ko1-- From tex@suturex-renodex.com Fri Sep 28 11:40:51 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbHxT-0007oF-3C for ccamp-archive@ietf.org; Fri, 28 Sep 2007 11:40:51 -0400 Received: from [200.142.117.106] (helo=mvx-200-142-117-106.mundivox.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbHxS-0002LK-4i for ccamp-archive@ietf.org; Fri, 28 Sep 2007 11:40:51 -0400 Received: from [200.142.117.106] by ns1.oleane.net; Fri, 28 Sep 2007 15:41:18 +0000 Message-ID: <000601c801e6$03afbb15$0ceadeb5@djvmkiv> From: "connie bang" To: Subject: Best investment opportunity. Your chance to multiply your invest. Date: Fri, 28 Sep 2007 13:53:56 +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.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 0.6 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Hello Investor We are pleased to invite you to an excellent investment opportunity. Make your money work today and tomorrow you will start to receive profits. In connection with a mortgage crisis in the real estate of the USA market, bank deposits became risky; investments in investment funds do not provide the desired return. Stock markets fall. Stop depend on the dollar rate and invest your money in a high profit financial instruments. Since the beginning of the year the American currency has lost about 15%, and it continues to fall. For The United States stock market is not the best time. Europe is also facing an economic crisis. In the difficult times of economic chaos you have to look for other investment instruments. Our investment company offers high profit investments with maximum impact. We are working on the market since 2005 and during the work we confirmed our impeccable reputation with regular payments and the performance of our profitability. Our clients receive 350% annual returns. We accept any amount of investments, and you can invest a small amount so as to see the quality of our work. We make our profit by day-trading on the American stock and bonds market. So, we are ready to provide individual Trading Platform for our clients. And you have an excellent opportunity to try your forces in the day-trading. Our best specialists will be pleased to provide you with investment advice and help you to choose an investment portfolio, which will be fully compatible with the chosen level of risk and return. If you are interested in this proposal please contact your personal manager to: BenMeadowsNF@gmail.com If you received this message in error please send a blank email to: ShermanFaulknerJF@gmail.com From cup@mynmail.com Fri Sep 28 13:06:18 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbJIA-0005qt-Jy for ccamp-archive@ietf.org; Fri, 28 Sep 2007 13:06:18 -0400 Received: from [125.187.32.241] (helo=m01.mailyes.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbJI3-0006tV-RE for ccamp-archive@ietf.org; Fri, 28 Sep 2007 13:06:18 -0400 Received: (qmail 5763 invoked by uid 0); 29 Sep 2007 02:03:10 +0900 Message-ID: <20070928170310.5762.qmail@m01.mailyes.net> To: ccamp-archive Subject: =?ISO-2022-JP?B?GyRCJDQ2YT1qQiglIiVdOCEbKEI=?= =?ISO-2022-JP?B?GyRCOnchKkE0OXEzRkNPJE49d0AtJCxCPz90RVBPPxsoQg==?= From: kinjomail Reply-to: delivery_rt Date: 2007-09-29 02:00:02 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: GOOD Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20070927171325_cbur Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 4.9 (++++) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 $B!!!!!!(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B!!!!!!!!!z!!$46a=j=P2q$$$+$i$N!!$*!!F@!!>p!!Js!!!z(B $B!!!!!!(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B!!!!!!!!!!!!"v(BVIP$B=w@-$N$4>R2p"v!AB(2q$$$X$NF;!A(B $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!(B $B!?!@!?!@!?!@!?!@!?!@!?!@!?!@!?!@!?!@!?!@!?!@!?!@!?!@!?!@!?!@!?!@!?(B $B!@!?:G=*9pCN(B!!$B!!%3%l$rF($7$?$i5.J}$NL$Mh$O!&!&!&L5$$(B!! $B(#!=!=($WD(B $B!C!@!?('!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=(B $B(&!=!=(%(B $B!!%2%j%i%$%Y%s%H=*N;$^$G$"$H$o$:$+!*(B $B!!4JC1EPO?!u7G<(HD=q$-9~$_$G4JC1$K!_!_$,!*#2=54VJg=8$7$F$*$j$^$9!#%.%j%.%jEPO?$G!!$b==J,;q3J$OF@$i$l$^$9(B? $B!!(Bhttp://xxxx-69.org.uk/pc/index3.php?u9psp4 $B!!(B $B!!LGB?$K$*L\$K$+$+$l$J$$(BVIP$B2q0wMM$H$N$*IU$-9g$$$H%P%C%/%"%C%W$r"v(B> $B!~(,(,(,(,"!(,!~(,"!(,!~(,"!(,!~(B -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- $B"#"""#(B http://xxxx-69.org.uk/pc/index3.php?u9psp4 $B"#"""#(B $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!($(B $B:G9bJv=P2q$$%5%$%H!*!X$46a=j=P2q$$!Y(B URL $B!'(B http://xxxx-69.org.uk/pc/index3.php?u9psp4 $B$3$N%a!<%k$K=q$+$l$?FbMF$NL5CG7G:\!"L5CGJ#@=$r6X$8$^$9!#(B Copyright (C) 2007 gokinjo All Rights Reserved. $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(%(B $B"(G[?.Dd;_$O$3$A$i$+$i(B givemail@gmail.com From owner-ccamp@ops.ietf.org Fri Sep 28 15:22:12 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbLPg-0007e1-EC for ccamp-archive@ietf.org; Fri, 28 Sep 2007 15:22:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbLPe-0002Cq-Qw for ccamp-archive@ietf.org; Fri, 28 Sep 2007 15:22:12 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IbLF9-000BpV-By for ccamp-data@psg.com; Fri, 28 Sep 2007 19:11:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE,USER_IN_ALL_SPAM_TO autolearn=no version=3.2.1 Received: from [66.226.64.2] (helo=pro.abac.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IbLF5-000Bok-EJ for ccamp@ops.ietf.org; Fri, 28 Sep 2007 19:11:17 +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 l8SJAoPg037228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Sep 2007 12:10:54 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <46FD51B9.9060909@grotto-networking.com> Date: Fri, 28 Sep 2007 12:10:49 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Igor Bryskin CC: ccamp , pce@ietf.org Subject: Re: [Pce] Some key issues with Wavelength Switched Optical Networks... References: <46FAEE2C.5040008@grotto-networking.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090301070903080006080809" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 6379955759c38e2371a49573a0932fc7 This is a multi-part message in MIME format. --------------090301070903080006080809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Igor, see comments below. Igor Bryskin wrote: > > Greg, > > > > I believe the draft is very useful. > --> Thanks! > > > > I have a couple of questions comments: > > > > 1. Section : 4.4. Traffic Grooming: Combining WSON and Higher Layer Network > > Optimization > > > > How the problem of grooming of higher layer network traffic over > optical trails is any different from the problem of traffic grooming > in TDM (e.g. VC12 over VC4)? I mean this is a general problem of > inter-layer relationship. I suggest moving all higher layer network > considerations out of scope of the draft and focusing on specifics of > the OCh layer. > --> Some of my co-authors agree with you on moving this section out. The reason that I put it in was that the optical "Traffic Grooming" problem has received a fair amount of attention in the research and general technical literature and is also a driver for the use of ROADMs (optical bypass). I guess in general we've got the following inter-related problems: (a) virtual network topology design, (b) lower layer connection routing, (c) higher layer flow routing. In our case (b) is the RWA problem, which is fairly difficult in its own right. I guess I should look closely at the MLN/MRN work and see if a specific example that includes RWA is mentioned. If so then I'd feel fine removing this section from the document. > > > > 2. Considering wavelength conversion inevitably brings to the problem > of looped paths, which is a completely new ball game in path > computation, and I am surprised that the issue was never mentioned in > the draft. > --> How is this different from the "looping" that can occur with a TDM multiplexer in a drop and continue mode? Also in these two circuit cases (TDM, and optical) do we have the same danger as in the packet case where looping traffic can greatly degrade other flows. Was there some general looping concerns already published for GMPLS with respect to circuits? > > > > Cheers, > > Igor > > > > ------------------------------------------------------------------------ > > *From:* Greg Bernstein [mailto:gregb@grotto-networking.com] > *Sent:* Wednesday, September 26, 2007 7:42 PM > *To:* ccamp; pce@ietf.org > *Subject:* [Pce] Some key issues with Wavelength Switched Optical > Networks... > > > > Hi folks, I haven't seen too many comments on our draft "Framework for > GMPLS and PCE Control of Wavelength Switched Optical Networks" ( > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-01.txt). > So I figured I'd point out some potentially controversial issues that > the draft brings up. > > (a) The draft brings up models for the following WDM network elements: > > 1. WDM links > 2. Optical transmitters > 3. Wavelength Converters and OEO regenerators > 4. ROADMs, FOADMs, optical splitters and combiners. > > For items (3) and (4) we are taking the modeling lead rather than > some other SDO. And for ROADMs, in particular, we going beyond the > classic ITU-T "fabric" model (M.3100) which has been the mainstay of > any connection oriented switch (TDM, ATM, MPLS). > > (b) The draft brings up three (not one, not two, but three) different > computational models for RWA which can impact GMPLS and PCE protocols: > > 1. A single PCE computing both the path and wavelength > 2. Two distinct PCEs, where one computes the path, and a different > PCE computes the wavelength assignment > 3. A PCE computes the path and wavelength assignment is > accomplished in a distributed fashion via signaling (e.g., using > label set objects) > > Do we really need all three models? > > (c) G.709 includes the Optical Multiplex Section and Optical > Channels. RFC4238 was aimed at GMPLS extensions for G.709 (Optical > Transport Network) control. Weren't we finished with all this optical > stuff years ago? > > I'd like to think the draft answers some of these questions. I also > think that network element models and the process models are important > enough to warrant this separate framework document. Your opinions are > solicited. > > Regards > > Greg B. > > -- > =================================================== > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------090301070903080006080809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Igor, see comments below.

    Igor Bryskin wrote:

    Greg,

     

    I believe the draft is very useful.

    --> Thanks!

     

    I have a couple of questions comments:

     

    1. Section : 4.4. Traffic Grooming: Combining WSON and Higher Layer Network 

       Optimization

     

    How the problem of grooming of higher layer network traffic over optical trails is any different from the problem of traffic grooming in TDM (e.g. VC12 over VC4)? I mean this is a general problem of inter-layer relationship. I suggest moving all higher layer network considerations out of scope of the draft and focusing on specifics of the OCh layer.

    --> Some of my co-authors agree with you on moving this section out.  The reason that I put it in was that the optical "Traffic Grooming" problem has received a fair amount of attention in the research and general technical literature and is also a driver for the use of ROADMs (optical bypass).  I guess in general we've got the following inter-related problems: (a) virtual network topology design, (b) lower layer connection routing, (c) higher layer flow routing. In our case (b) is the RWA problem, which is fairly difficult in its own right. I guess I should look closely at the MLN/MRN work and see if a specific example that includes RWA is mentioned.  If so then I'd feel fine removing this section from the document.

     

    2. Considering wavelength conversion inevitably brings to the problem of looped paths, which is a completely new ball game in path computation, and I am surprised that the issue was never mentioned in the draft.

    --> How is this different from the "looping" that can occur with a TDM multiplexer in a drop and continue mode?  Also in these two circuit cases (TDM, and optical) do we have the same danger as in the packet case where looping traffic can greatly degrade other flows.  Was there some general looping concerns already published for GMPLS with respect to circuits? 

     

    Cheers,

    Igor

     


    From: Greg Bernstein [mailto:gregb@grotto-networking.com]
    Sent: Wednesday, September 26, 2007 7:42 PM
    To: ccamp; pce@ietf.org
    Subject: [Pce] Some key issues with Wavelength Switched Optical Networks...

     

    Hi folks, I haven't seen too many comments on our draft "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks" ( http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-01.txt). So I figured I'd point out some potentially controversial issues that the draft brings up.

    (a) The draft brings up models for the following WDM network elements:

    1. WDM links
    2. Optical transmitters
    3. Wavelength Converters and OEO regenerators
    4. ROADMs, FOADMs, optical splitters and combiners.

        For items (3) and (4) we are taking the modeling lead rather than some other SDO.  And for ROADMs, in particular, we going beyond the classic ITU-T "fabric" model (M.3100) which has been the mainstay of any connection oriented switch (TDM, ATM, MPLS).

    (b) The draft brings up three (not one, not two, but three) different computational models for RWA which can impact GMPLS and PCE protocols:

    1. A single PCE computing both the path and wavelength
    2. Two distinct PCEs, where one computes the path, and a different PCE computes the wavelength assignment
    3. A PCE computes the path and wavelength assignment is accomplished in a distributed fashion via signaling (e.g., using label set objects)

        Do we really need all three models?

    (c) G.709 includes the Optical Multiplex Section and Optical Channels.  RFC4238 was aimed at GMPLS extensions for G.709  (Optical Transport Network) control.  Weren't we finished with all this optical stuff years ago?

    I'd like to think the draft answers some of these questions.  I also think that network element models and the process models are important enough to warrant this separate framework document.  Your opinions are solicited.

    Regards

    Greg B.

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

    -- 
    ===================================================
    Dr Greg Bernstein, Grotto Networking (510) 573-2237
    
    
    --------------090301070903080006080809-- From ebanner@sandytennies.com Fri Sep 28 15:50:42 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbLrG-0001BB-Ip; Fri, 28 Sep 2007 15:50:42 -0400 Received: from [213.17.223.230] (helo=ip-213-17-223-230.netia.com.pl) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IbLrD-0002T0-Kl; Fri, 28 Sep 2007 15:50:40 -0400 Received: from policjagn8g3ks ([179.21.4.37]:46939 "HELO policjagn8g3ks" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by e6df11d5sandytennies.com with ESMTP id C91761043A1A4 (ORCPT ); Fri, 28 Sep 2007 21:52:26 +0200 Message-ID: <001901c80219$dbf5b4d0$06e470ec@policjagn8g3ks> From: reproduce To: ccamp-archive@ietf.org Subject: Is electrical Date: Fri, 28 Sep 2007 21:52:26 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C80219.DBF5B4D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.1158 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.4682 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C80219.DBF5B4D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable will be mentally visualized as a small world, more intense than course I have been able to "go" all around the world. I have that I have be= en reminded of thrice during the writing if this ------=_NextPart_000_0016_01C80219.DBF5B4D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    of examples of tools to choose from and the ability to combine a

    Are you wanting a bigger p >e n _i s?

    As se -e -n on TV

    Over 785,000 Men around the world are already satisfied
    Gain 2+ Inches In Leng _th
    Increase Your P _en -is Wi _dth (Girth) By up _to 22%
    100% Safe To Take, With NO Side Effects
    No Pum ps! No Surg ery! No Ex ercises!
    *3 FREE Bottles

    these drawings and designs would have been more artistic and
    ------=_NextPart_000_0016_01C80219.DBF5B4D0-- From owner-ccamp@ops.ietf.org Fri Sep 28 15:56:49 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbLxB-0006AU-QO for ccamp-archive@ietf.org; Fri, 28 Sep 2007 15:56:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbLx9-0003K3-Ku for ccamp-archive@ietf.org; Fri, 28 Sep 2007 15:56:49 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IbLnv-000Gdu-4R for ccamp-data@psg.com; Fri, 28 Sep 2007 19:47:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE,USER_IN_ALL_SPAM_TO autolearn=no version=3.2.1 Received: from [66.226.64.2] (helo=pro.abac.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IbLnl-000GdF-Sl for ccamp@ops.ietf.org; Fri, 28 Sep 2007 19:47:10 +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 l8SJkWZm061808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Sep 2007 12:46:35 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <46FD5A18.2080505@grotto-networking.com> Date: Fri, 28 Sep 2007 12:46:32 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Giovanni Martinelli (giomarti)" CC: ccamp , pce@ietf.org Subject: Re: [Pce] Some key issues with Wavelength Switched Optical Networks... References: <1F2FBF50FB955441A11316BAE835CED4042D142B@xmb-ams-338.emea.cisco.com> In-Reply-To: <1F2FBF50FB955441A11316BAE835CED4042D142B@xmb-ams-338.emea.cisco.com> Content-Type: multipart/alternative; boundary="------------030001070104060803010707" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 85e99493ec37f9acef29c7843dbf2e68 This is a multi-part message in MIME format. --------------030001070104060803010707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Giovanni, thanks for the close read. Looks like you caught some problems with the text. See below for comments. Giovanni Martinelli (giomarti) wrote: > Hi Greg, > > Sorry for the delay in replying. I'm working on this topic since a > while so yes, it's interesting. Before going on specific issue I would > have some question/clarification regarding the draft itself. > > > * Within Abstract and the following. > You don't talk about Optical Cross Connects (OXC) is something missing > or understated somewhere? -->Whoops. We were trying to find a more general term to include both ROADM (usually a highly asymmetric fabric) and an OXC (a completely symmetric fabric, e.g., any ingress to any egress), but we seemed to have gone with using the ROADM terminology to include both cases. Talked with some equipment makers that planned/make "switches" that seemed to incorporate both so we made sure the model could deal with both sparse and dense potential connectivity. Diego had some terminology ideas but lately his e-mails have been bouncing back to me. Any suggestions are appreciated, but we are including both ROADM and OXCs. > > > * Section 3.1 where you state: > "A fixed mapping between the > GMPLS label space and these ITU-T WDM grids as proposed in [Otani] " > Does it implies a sort of network level label space? How relate with > usual local label significance? --> This mapping gives a mapping between labels and wavelengths/lambda, just like in the SONET/SDH case we mapped the ITU-T G.707 "S, U, K, L, M " identification of SDH time slots to a label format in RFC4606 and again this was done in RFC4328 to map G.709 digital wrapper time slot identification into a technology specific label format. In RFC3471 for lambda switching we just get a 32 bit integer with no meaning attached. Every network and every node could potentially map labels to lambdas in a different way. In [Otani] they are following the RFC4606 and RFC4328 lead and using the ITU-T DWDM and CWDM lambda grid standards to give a fixed association between labels and lambdas just like between labels and TDM time slots in the SDH/ODU case. This doesn't change the local significance of labels. In the wavelength switched optical case that is influenced by the presence or absence of wavelength converters. > > > * Section 3.4 Wavelength Converters > "Current or envisioned contexts for wavelength converters are : ..." > Could we think to a description/model for wavelength converter that is > technology agnostic? Simply something like: full conversion > capability, partial conversion capability with some constrains, and > may be others. --> The difference, between the all optical techniques and the OEO based techniques makes that difficult. > > > * Section 3.4. the following: > "4. Wavelength converters that are O-E-O based will have a restriction > based on the modulation format and transmission speed" > Not clear to me the type of restriction here when OEO happens... > probably I'm missing what you mean here. --> For example a typical O-E-O based wavelength converter would be build around a 3R regenerator with a tunable laser. A 3R regenerator cares about the modulation type say NRZ or RZ (and which flavor), and the symbol rate since its also doing retiming. An all optical wavelength converter will be fairly independent of these issues (except when we look at impairment factors). Hence the OEO wavelength is going to be more signal specific than the all optical. > > > * Section 4.1 when you talk about Lightpath temporal characteristics: > "Lightpath connection duration has typically been thought of as > approximately three time frames: " > and the following you define: dynamics, pseudo-static, static. > Why there's a need of this classification? When you us Short/long is > compared to what? --> In most of the research literature and in optimization practice different techniques are typically used in the dynamic versus static (or psuedo static cases). In MPLS there is minimum interference routing optimization techniques for the dynamic case. For the static case I could apply multi-commodity flow optimization techniques to a batch of connections. In the RWA literature there is a similar differentiation. Exactly what information could be sent to help PCE differentiate I'm not sure. In the case of static, batch optimization we can just use the existing concurrent optimization hooks in PCE. For an individual lightpath request it seemed that it would be helpful to know how long the connection would last so we'd know how much computational effort we might want to put into optimize it. > > > minor typo on your mail below: point (c) rfc4328 (not 4238) right? --> Yes. The G.709 signaling extensions RFC. > > Thanks, > Giovanni > > > > > ------------------------------------------------------------------------ > *From:* Greg Bernstein [mailto:gregb@grotto-networking.com] > *Sent:* giovedì 27 settembre 2007 1.42 > *To:* ccamp; pce@ietf.org > *Subject:* [Pce] Some key issues with Wavelength Switched Optical > Networks... > > Hi folks, I haven't seen too many comments on our draft "Framework > for GMPLS and PCE Control of Wavelength Switched Optical Networks" > ( > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-01.txt). > So I figured I'd point out some potentially controversial issues > that the draft brings up. > > (a) The draft brings up models for the following WDM network elements: > > 1. WDM links > 2. Optical transmitters > 3. Wavelength Converters and OEO regenerators > 4. ROADMs, FOADMs, optical splitters and combiners. > > For items (3) and (4) we are taking the modeling lead rather > than some other SDO. And for ROADMs, in particular, we going > beyond the classic ITU-T "fabric" model (M.3100) which has been > the mainstay of any connection oriented switch (TDM, ATM, MPLS). > > (b) The draft brings up three (not one, not two, but three) > different computational models for RWA which can impact GMPLS and > PCE protocols: > > 1. A single PCE computing both the path and wavelength > 2. Two distinct PCEs, where one computes the path, and a > different PCE computes the wavelength assignment > 3. A PCE computes the path and wavelength assignment is > accomplished in a distributed fashion via signaling (e.g., > using label set objects) > > Do we really need all three models? > > (c) G.709 includes the Optical Multiplex Section and Optical > Channels. RFC4238 was aimed at GMPLS extensions for G.709 > (Optical Transport Network) control. Weren't we finished with all > this optical stuff years ago? > > I'd like to think the draft answers some of these questions. I > also think that network element models and the process models are > important enough to warrant this separate framework document. > Your opinions are solicited. > > Regards > > Greg B. > > -- > =================================================== > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------030001070104060803010707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Giovanni, thanks for the close read.  Looks like you caught some problems with the text.  See below for comments.

    Giovanni Martinelli (giomarti) wrote:
    Hi Greg,
     
    Sorry for the delay in replying. I'm working on this topic since a while so yes, it's interesting. Before going on specific issue I would have some question/clarification regarding the draft itself.
     
     
    * Within Abstract and the following.
    You don't talk about Optical Cross Connects (OXC) is something missing or understated somewhere?
    -->Whoops.  We were trying to find a more general term to include both ROADM (usually a highly asymmetric fabric) and an OXC (a completely symmetric fabric, e.g., any ingress to any egress), but we seemed to have gone with using the ROADM terminology to include both cases.  Talked with some equipment makers that planned/make "switches" that seemed to incorporate both so we made sure the model could deal with both sparse and dense potential connectivity. Diego had some terminology ideas but lately his e-mails have been bouncing back to me.  Any suggestions are appreciated, but we are including both ROADM and OXCs.
     
     
    * Section 3.1 where you state:
    "A fixed mapping between the
    GMPLS label space and these ITU-T WDM grids as proposed in [Otani] "
    Does it implies a sort of network level label space? How relate with usual local label significance?
    --> This mapping gives a mapping between labels and wavelengths/lambda, just like in the SONET/SDH case we mapped the ITU-T G.707 "S, U, K, L, M " identification of SDH time slots to a label format in RFC4606 and again this was done in RFC4328 to map G.709 digital wrapper time slot identification into a technology specific label format.  In RFC3471 for lambda switching we just get a 32 bit integer with no meaning attached. Every network and every node could potentially map labels to lambdas in a different way. In [Otani] they are following the RFC4606 and RFC4328 lead and using the ITU-T DWDM and CWDM lambda grid standards to give a fixed association between labels and lambdas just like between labels and TDM time slots in the SDH/ODU case.

    This doesn't change the local significance of labels. In the wavelength switched optical case that is influenced by the presence or absence of wavelength converters.
     
     
    * Section 3.4 Wavelength Converters
    "Current or envisioned contexts for wavelength converters are : ..."
    Could we think to a description/model for wavelength converter that is technology agnostic? Simply something like: full conversion capability, partial conversion capability with some constrains, and may be others.
    --> The difference, between the all optical techniques and the OEO based techniques makes that difficult.
     
     
    * Section 3.4. the following:
    "4. Wavelength converters that are O-E-O based will have a restriction
    based on the modulation format and transmission speed"
    Not clear to me the type of restriction here when OEO happens... probably I'm missing what you mean here.
    --> For example a typical O-E-O based wavelength converter would be build around a 3R regenerator with a tunable laser. A 3R regenerator cares about the modulation type say NRZ or RZ (and which flavor), and the symbol rate since its also doing retiming. An all optical wavelength converter will be fairly independent of these issues (except when we look at impairment factors). Hence the OEO wavelength is going to be more signal specific than the all optical.
     
     
    * Section 4.1 when you talk about Lightpath temporal characteristics:
    "Lightpath connection duration has typically been thought of as
    approximately three time frames: "
    and the following you define: dynamics, pseudo-static, static.
    Why there’s a need of this classification? When you us Short/long is compared to what?
    --> In most of the research literature and in optimization practice different techniques are typically used in the dynamic versus static (or psuedo static cases).  In MPLS there is minimum interference routing optimization techniques for the dynamic case. For the static case I could apply multi-commodity flow optimization techniques to a batch of connections.  In the RWA literature there is a similar differentiation.  Exactly what information could be sent to help PCE differentiate I'm not sure. In the case of static, batch optimization we can just use the existing concurrent optimization hooks in PCE. For an individual lightpath request it seemed that it would be helpful to know how long the connection would last so we'd know how much computational effort we might want to put into optimize it.
     
     
    minor typo on your mail below: point (c) rfc4328 (not 4238) right?
    --> Yes.  The G.709 signaling extensions RFC.
     
    Thanks,
    Giovanni


     


    From: Greg Bernstein [mailto:gregb@grotto-networking.com]
    Sent: giovedì 27 settembre 2007 1.42
    To: ccamp; pce@ietf.org
    Subject: [Pce] Some key issues with Wavelength Switched Optical Networks...

    Hi folks, I haven't seen too many comments on our draft "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks" ( http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-01.txt). So I figured I'd point out some potentially controversial issues that the draft brings up.

    (a) The draft brings up models for the following WDM network elements:
    1. WDM links
    2. Optical transmitters
    3. Wavelength Converters and OEO regenerators
    4. ROADMs, FOADMs, optical splitters and combiners.
        For items (3) and (4) we are taking the modeling lead rather than some other SDO.  And for ROADMs, in particular, we going beyond the classic ITU-T "fabric" model (M.3100) which has been the mainstay of any connection oriented switch (TDM, ATM, MPLS).

    (b) The draft brings up three (not one, not two, but three) different computational models for RWA which can impact GMPLS and PCE protocols:
    1. A single PCE computing both the path and wavelength
    2. Two distinct PCEs, where one computes the path, and a different PCE computes the wavelength assignment
    3. A PCE computes the path and wavelength assignment is accomplished in a distributed fashion via signaling (e.g., using label set objects)
        Do we really need all three models?

    (c) G.709 includes the Optical Multiplex Section and Optical Channels.  RFC4238 was aimed at GMPLS extensions for G.709  (Optical Transport Network) control.  Weren't we finished with all this optical stuff years ago?

    I'd like to think the draft answers some of these questions.  I also think that network element models and the process models are important enough to warrant this separate framework document.  Your opinions are solicited.

    Regards

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

    -- 
    ===================================================
    Dr Greg Bernstein, Grotto Networking (510) 573-2237
    
    
    --------------030001070104060803010707-- From owner-ccamp@ops.ietf.org Fri Sep 28 17:54:15 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbNmp-0001m7-Na for ccamp-archive@ietf.org; Fri, 28 Sep 2007 17:54:15 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbNmi-0000So-TM for ccamp-archive@ietf.org; Fri, 28 Sep 2007 17:54:09 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IbNco-0003qB-4d for ccamp-data@psg.com; Fri, 28 Sep 2007 21:43:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE,USER_IN_ALL_SPAM_TO autolearn=no version=3.2.1 Received: from [66.226.64.2] (helo=pro.abac.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IbNcl-0003pr-6l for ccamp@ops.ietf.org; Fri, 28 Sep 2007 21:43:52 +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 l8SLhcqN035748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Sep 2007 14:43:41 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <46FD7589.10505@grotto-networking.com> Date: Fri, 28 Sep 2007 14:43:37 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Igor Bryskin CC: ccamp , pce@ietf.org Subject: Re: [Pce] Some key issues with Wavelength Switched Optical Networks... References: <46FAEE2C.5040008@grotto-networking.com> <46FD51B9.9060909@grotto-networking.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060109060902070806000707" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 This is a multi-part message in MIME format. --------------060109060902070806000707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Very good catch Igor. See in line. Igor Bryskin wrote: > --snip-- > > > > > > 2. Considering wavelength conversion inevitably brings to the problem > of looped paths, which is a completely new ball game in path > computation, and I am surprised that the issue was never mentioned in > the draft. > > --> How is this different from the "looping" that can occur with a TDM > multiplexer in a drop and continue mode? Also in these two circuit > cases (TDM, and optical) do we have the same danger as in the packet > case where looping traffic can greatly degrade other flows. Was there > some general looping concerns already published for GMPLS with respect > to circuits? > > > > IB>> There is a profound difference. I am not talking here about > accidental looping, rather about deliberate looping: if some nodes can > perform wavelength conversion while others can not, then you will want > to route the connection to one or several conversion points and after > that get it back on the main path. In other words you will > deliberately request, say, a PCE to produce looped path, and then > GMPLS RSVP-TE to signal looped path, which is completely out of normal > paradigm of work for both PCE and RSVP. > --> I thought you were worried about accidental loops. I didn't even consider what you are talking about "looping", but would RSVP processing get fouled up? It sure looks like a loop at the "node" level. In the ERO the "node" subobject (IP4, IP6, AS) could definitely be repeated, but with a different "Label ERO" subobject appended. This is definitely something somebody would not to in the MPLS or TDM case. I'll be sure to add it as an important difference in the next revision. Thanks! > > > > Cheers, > > Igor > > > > ------------------------------------------------------------------------ --snip-- -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------060109060902070806000707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Very good catch Igor. See in line.

    Igor Bryskin wrote:
    --snip--



     

    2. Considering wavelength conversion inevitably brings to the problem of looped paths, which is a completely new ball game in path computation, and I am surprised that the issue was never mentioned in the draft.

    --> How is this different from the "looping" that can occur with a TDM multiplexer in a drop and continue mode?  Also in these two circuit cases (TDM, and optical) do we have the same danger as in the packet case where looping traffic can greatly degrade other flows.  Was there some general looping concerns already published for GMPLS with respect to circuits? 

     

    IB>> There is a profound difference. I am not talking here about accidental looping, rather about deliberate looping: if some nodes can perform wavelength conversion while others can not, then you will want to route the connection to one or several conversion points and after that get it back on the main path. In other words you will deliberately request, say, a PCE to produce looped path, and then GMPLS RSVP-TE to signal looped path, which is completely out of normal paradigm of work for both PCE and RSVP.

    --> I thought you were worried about accidental loops.  I didn't even consider what you are talking about "looping", but would RSVP processing get fouled up? It sure looks like a loop at the "node" level.
    In the ERO the "node" subobject (IP4, IP6, AS) could definitely be repeated, but with a different "Label ERO" subobject appended. This is definitely something somebody would not to in the MPLS or TDM case.  I'll be sure to add it as an important difference in the next revision. Thanks!

     

    Cheers,

    Igor

     


    --snip--
    -- 
    ===================================================
    Dr Greg Bernstein, Grotto Networking (510) 573-2237
    
    
    --------------060109060902070806000707-- From owner-ccamp@ops.ietf.org Fri Sep 28 18:40:47 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbOVr-0006mi-TI for ccamp-archive@ietf.org; Fri, 28 Sep 2007 18:40:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbOVq-0008IX-Gh for ccamp-archive@ietf.org; Fri, 28 Sep 2007 18:40:47 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IbOOc-0008pc-OH for ccamp-data@psg.com; Fri, 28 Sep 2007 22:33:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE,USER_IN_ALL_SPAM_TO autolearn=no version=3.2.1 Received: from [168.127.0.56] (helo=fncnmp03.fnc.fujitsu.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IbOOZ-0008pG-BK for ccamp@ops.ietf.org; Fri, 28 Sep 2007 22:33:17 +0000 X-IronPort-AV: E=Sophos;i="4.21,211,1188795600"; d="scan'208,217";a="192970068" Received: from rchemx01.fnc.net.local ([168.127.134.104]) by fncnmp01.fnc.fujitsu.com with ESMTP; 28 Sep 2007 17:33:12 -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_01C8021F.8D653E47" Subject: RE: [Pce] Some key issues with Wavelength Switched Optical Networks... Date: Fri, 28 Sep 2007 17:33:11 -0500 Message-ID: In-Reply-To: <46FD7589.10505@grotto-networking.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Some key issues with Wavelength Switched Optical Networks... Thread-Index: AcgCGayoFx0FLU33S4uAa4y5kFZHtwAA8mjA From: "Bardalai, Snigdho" To: "Greg Bernstein" , "Igor Bryskin" Cc: "ccamp" , Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: b5299d0955d21ceeb18e25a232290fec This is a multi-part message in MIME format. ------_=_NextPart_001_01C8021F.8D653E47 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, this is an interesting problem within the WSON domain and one way = to solve the RSVP-TE problem is by modeling the node with the loop-back = as a pass-thru node with some sort of indication within the signaling = message identifying which pieces of hardware to use as part of the = loop-back. =20 Snigdho -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On = Behalf Of Greg Bernstein Sent: Friday, September 28, 2007 4:44 PM To: Igor Bryskin Cc: ccamp; pce@ietf.org Subject: Re: [Pce] Some key issues with Wavelength Switched Optical = Networks... Very good catch Igor. See in line. Igor Bryskin wrote:=20 --snip--=20 2. Considering wavelength conversion inevitably brings to the problem of = looped paths, which is a completely new ball game in path computation, = and I am surprised that the issue was never mentioned in the draft. --> How is this different from the "looping" that can occur with a TDM = multiplexer in a drop and continue mode? Also in these two circuit = cases (TDM, and optical) do we have the same danger as in the packet = case where looping traffic can greatly degrade other flows. Was there = some general looping concerns already published for GMPLS with respect = to circuits? =20 IB>> There is a profound difference. I am not talking here about = accidental looping, rather about deliberate looping: if some nodes can = perform wavelength conversion while others can not, then you will want = to route the connection to one or several conversion points and after = that get it back on the main path. In other words you will deliberately = request, say, a PCE to produce looped path, and then GMPLS RSVP-TE to = signal looped path, which is completely out of normal paradigm of work = for both PCE and RSVP. --> I thought you were worried about accidental loops. I didn't even = consider what you are talking about "looping", but would RSVP processing = get fouled up? It sure looks like a loop at the "node" level.=20 In the ERO the "node" subobject (IP4, IP6, AS) could definitely be = repeated, but with a different "Label ERO" subobject appended. This is = definitely something somebody would not to in the MPLS or TDM case. = I'll be sure to add it as an important difference in the next revision. = Thanks! Cheers,=20 Igor _____ =20 --snip-- --=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 ------_=_NextPart_001_01C8021F.8D653E47 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Yes,=20 this is an interesting problem within the WSON domain and one way = to solve=20 the RSVP-TE problem is by modeling the node with the loop-back = as a=20 pass-thru node with some sort of indication within the signaling message = identifying which pieces of hardware to use as part of the=20 loop-back.
     
    Snigdho
    -----Original Message-----
    From: = owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Greg=20 Bernstein
    Sent: Friday, September 28, 2007 4:44 = PM
    To:=20 Igor Bryskin
    Cc: ccamp; pce@ietf.org
    Subject: Re: = [Pce]=20 Some key issues with Wavelength Switched Optical=20 Networks...

    Very good catch Igor. See in = line.

    Igor=20 Bryskin wrote:=20
    --snip--=20



    2. = Considering=20 wavelength conversion inevitably brings to the problem of looped = paths,=20 which is a completely new ball game in path computation, and I am = surprised=20 that the issue was never mentioned in the=20 draft.

    --> How is this different from the = "looping" that=20 can occur with a TDM multiplexer in a drop and continue mode?  = Also in=20 these two circuit cases (TDM, and optical) do we have the same = danger as in=20 the packet case where looping traffic can greatly degrade other = flows. =20 Was there some general looping concerns already published for GMPLS = with=20 respect to circuits? 

    IB>> There is=20 a profound difference. I am not talking here about accidental = looping,=20 rather about deliberate looping: if some nodes can perform = wavelength=20 conversion while others can not, then you will want to route the = connection=20 to one or several conversion points and after that get it back on = the main=20 path. In other words you will deliberately request, say, a PCE to = produce=20 looped path, and then GMPLS RSVP-TE to signal looped path, which is=20 completely out of normal paradigm of work for both PCE and=20 RSVP.

    --> I thought you were = worried=20 about accidental loops.  I didn't even consider what you are = talking=20 about "looping", but would RSVP processing get fouled up? It sure = looks like a=20 loop at the "node" level.
    In the ERO the "node" subobject (IP4, = IP6, AS)=20 could definitely be repeated, but with a different "Label ERO" = subobject=20 appended. This is definitely something somebody would not to in the = MPLS or=20 TDM case.  I'll be sure to add it as an important difference in = the next=20 revision. Thanks!

    Cheers,=20

    Igor


    --snip--
    --=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
    
    
    ------_=_NextPart_001_01C8021F.8D653E47-- From charitymayeszs@cndns.com Fri Sep 28 18:53:20 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbOhz-0004vP-Mf; Fri, 28 Sep 2007 18:53:19 -0400 Received: from tcn054090.tcn-catv.ne.jp ([123.200.50.90] helo=varig.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbOhs-0001zy-JJ; Fri, 28 Sep 2007 18:53:14 -0400 From: "Charity Mayes" Subject: have ShortDick? Safe, effective and 100% natural way to add 1-4 inches di7ity3no7qii26kit Reply-To: "Charity Mayes" MIME-Version: 1.0 Sender: X-Sender: Message-ID: <1191019430.4651@cndns.com> To: hubmib-bounces@ietf.org Bcc: ccamp-archive@ietf.org, ldap-dir-bounces@ietf.org Date: Fri, 28 Sep 2007 15:43:50 -0700 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0085_45F49EAF.282F20BC" X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 This is a multi-part message in MIME format. ------=_NextPart_000_0085_45F49EAF.282F20BC Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit Safe & Effective PenisEnlargement Over 1,500,000 bottles sold worldwide WeOffer Full MoneyBack Guarantee if you are not completely satisfied with the results of Man-XL, you have nothing to lose, just a lot to gain 1) Gain Up to 3+ Inches In Length 2) Increase YourPenis Width (Girth) By upto 20% 3) Help Stop PrematureEjaculation! 4) Produce Stronger, Rock HardErections 5) 100% Safe To Take, With NO Side Effects 6) Fast Shipping WorldWid 7) Doctor Approved And Recommended 8) No Pumps, No Surgery, No Exercises 9) Very discrete shipping and billing 10) Up to 3 FREE Bottles Of Man-XL 11) Highly secure 128bit order processing Buy This herbal EnlargementPills here http://dtr.lonational.com http://diu.lonational.com ------=_NextPart_000_0085_45F49EAF.282F20BC Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: 8bit
    Safe & Effective PenisEnlargement
    Over 1,500,000 bottles sold worldwide
    WeOffer Full MoneyBack Guarantee if you are not completely satisfied with the results of Man-XL, you have nothing to lose, just a lot to gain
    1) Gain Up to 3+ Inches In Length
    2) Increase YourPenis Width (Girth) By upto 20%
    3) Help Stop PrematureEjaculation!
    4) Produce Stronger, Rock HardErections
    5) 100% Safe To Take, With NO Side Effects
    6) Fast Shipping WorldWide
    7) Doctor Approved And Recommended
    8) No Pumps, No Surgery, No Exercises
    9) Very discrete shipping and billing
    10) Up to 3 FREE Bottles Of Man-XL
    11) Highly secure 128bit order processing
    Did you know... Man-XL was featured in leading mens magazines such as FHM, MAXIM, plus many others, and rated No.1 choice forPenisEnlargement Also seen on TV
    Buy This herbal EnlargementPills here (Link 1)
    (Link 2)




    pay bread may hurrying? towards second clear may better god ten? 87rnn93m66n 34iseo1hxud9w1
    ------=_NextPart_000_0085_45F49EAF.282F20BC-- From owner-ccamp@ops.ietf.org Sat Sep 29 01:22:00 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbUm8-0007zc-87 for ccamp-archive@ietf.org; Sat, 29 Sep 2007 01:22:00 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbUm2-000099-Bj for ccamp-archive@ietf.org; Sat, 29 Sep 2007 01:21:54 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IbUcw-000Kry-To for ccamp-data@psg.com; Sat, 29 Sep 2007 05:12:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-101.2 required=5.0 tests=AWL,BAYES_00, MIME_BASE64_BLANKS,MIME_BASE64_TEXT,RDNS_NONE,USER_IN_ALL_SPAM_TO autolearn=no version=3.2.1 Received: from [61.144.161.7] (helo=szxga04-in.huawei.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IbUct-000KrQ-Ai for ccamp@ops.ietf.org; Sat, 29 Sep 2007 05:12:29 +0000 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JP400E0X6GO24@szxga04-in.huawei.com> for ccamp@ops.ietf.org; Sat, 29 Sep 2007 13:12:25 +0800 (CST) Received: from M55527 ([10.111.12.79]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JP40039Z6GMH7@szxga04-in.huawei.com> for ccamp@ops.ietf.org; Sat, 29 Sep 2007 13:12:24 +0800 (CST) Date: Sat, 29 Sep 2007 13:12:08 +0800 From: Mach Chen Subject: Re: [OSPF] Fwd: Posting of draft-ietf-ospf-ospfv3-traffic-09.txt To: Acee Lindem Cc: OSPF List , Vishwas Manral , Alan Davey , CCAMP List Message-id: <0JP4003A46GNH7@szxga04-in.huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 5.0 [en] Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 2.8 (++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 SGkgQWNlZSAsDQoNClNvcnJveSBmb3IgbGF0ZSByZXBseS4NCiAgICAgICANCk9uIDIwMDctMDkt MjYsIGF0IDIyOjE0OjM2IEFjZWUgTGluZGVtIHdyb3RlOg0KDQo+SGkgTWFjaCwNCj4NCj5PbiBT ZXAgMjYsIDIwMDcsIGF0IDY6MTAgQU0sIE1hY2ggQ2hlbiB3cm90ZToNCj4NCj4+IEhpIEFjZWUs DQo+Pg0KPj4gUGxzIHNlZSBpbmxpbmUNCj4+DQo+Pg0KPj4gT24gMjAwNy0wOS0yNSwgYXQgMjE6 MDU6NDkgQWNlZSBMaW5kZW0gd3JvdGU6DQo+Pg0KPj4+IEhpIE1hY2gsDQo+Pj4gVGhhbmtzIGZv ciByZXZpZXdpbmcuDQo+Pj4NCj4+PiBPbiBTZXAgMjUsIDIwMDcsIGF0IDQ6MjQgQU0sIE1hY2gg Q2hlbiB3cm90ZToNCj4+Pg0KPj4+PiBIaSBBY2VlIGFuZCBvdGhlciBhdXRob3JzLA0KPj4+Pg0K Pj4+Pg0KPj4+Pg0KPj4+PiBTb21lIHF1ZXN0aW9ucyB0byBvc3BmdjMtdHJhZmZpYw0KPj4+Pg0K Pj4+Pg0KPj4+Pg0KPj4+PiAxLiAgICAgICBJbiB0aGlzIG9zcGZ2My10cmFmZmljIGRvY3VtZW50 LCBhIG5ldyBMU0EsIEludHJhLUFyZWEtVEUNCj4+Pj4gTFNBLCBpcyBkZWZpbmVkIHRvIGFkdmVy dGlzZSBJUHY2IFRFIGluZm9ybWF0aW9uLiBGcm9tIG5hbWUgb2YgdGhpcw0KPj4+PiBuZXcgTFNB LCBJTUhPLCBpdCBpcyBsaW1pdGVkIHRvIGJlIHVzZWQgZm9yIEludHJhLUFyZWEgVEUgb25seS4g U28sDQo+Pj4+IGlmIHRoZXJlIGFyZSBzb21lIHVuZGVybHlpbmcgZXh0ZW5zaW9ucyB0byBvc3Bm djMtdHJhZmZpYywgZS5nLg0KPj4+PiBJbnRlci1BUyBURSwgaXQgaXMgYSBsaXR0bGUgYml0IHN0 cmFuZ2UgdG8gcmUtdXNlIHRoZSBJbnRyYS1BcmVhLVRFDQo+Pj4+IExTQSwgb3IgaXQgaGFzIHRv IGRlZmluZSBhIG5ldyBMU0EuIFNvLCBjYW4gd2UgY2hhbmdlIGl0cyBuYW1lIHRvDQo+Pj4+IHNv bWV0aGluZyBsaWtlIKGwT1NQRnYzIFRFIExTQaGxPw0KPj4+IEl0IHdvdWxkIGJlIGlmIHdlIGhh ZCBpbnRlbmRlZCBpdCB0byBjYXJyeSBBUyB3aWRlIGluZm9ybWF0aW9uLg0KPj4+IEhvd2V2ZXIs IGl0IHdhcyBub3QgaW5pdGlhbGx5IGludGVuZGVkIGZvciB0aGlzLiBUaGUgaW5pdGlhbCB0aG91 Z2h0DQo+Pj4gd2FzIHRoYXQgd2Ugd291bGQgZG8gYSBiZXR0ZXIgam9iIGZvciBPU1BGdjMgYW5k IGRlZmluZSBzZXBhcmF0ZSBMU0ENCj4+PiB0eXBlcyBmb3IgaW50cmEtYXJlYSwgaW50ZXItYXJl YSwgYW5kIEFTIGV4dGVybmFsIFRFIExTQXMuIFRob3VnaHRzDQo+Pj4gb24gdGhpcyAoY29waWVk IGNjYW1wIGFzIHdlbGwpPw0KPj4NCj4+IFNvLCB0aGUgY29uY2x1c2lvbiBpcyB0aGF0IGEgbmV3 IExTQShtYXkgYmUgY2FsbGVkIEludGVyLUFTLVRFIExTQSkgIA0KPj4gaGFzIHRvIGJlIGRlZmlu ZWQgZm9yIGFkdmVydGlzaW5nIGludGVyLUFTIFRFIGluZm9ybWF0aW9uIGluICANCj4+IHN1cHBv cnQgb2YgT1NQRnYzIFRFLCBhbSBJIHJpZ2h0Pw0KPj4NCj4+PiBJIGd1ZXNzLCBJTUhPLCB0aGlz IGRpc2NyZXBhbmN5DQo+Pj4gZXhwb3NlcyB0aGUgY2hvaWNlIG9mIGEgbmV3IGxpbmsgdHlwZSBm b3IgaW50ZXItQVMgY29ubmVjdGl2aXR5IGFzIGENCj4+PiBiaXQgb2YgYSBoYWNrLg0KPj4+DQo+ Pg0KPj4gRm9yIE9TUEZ2MyBURShzZXBhcmF0ZSBMU0FzIGFyZSB1c2VkKSBpcyBZRVMuIEJ1dCBh cyB0byBPU1BGdjIgVEUsICANCj4+IElNSE8sIHRoZXJlIHNob3VsZCBiZSBhIG5ldyBsaW5rIHR5 cGUgdG8gaWRlbnRpZnkgYW4gaW50ZXItQVMgbGluaywgIA0KPj4gb3Igd2UgbmVlZCBhbm90aGVy IG5ldyBMU0EuDQo+DQo+DQo+SXQgc2VlbXMgdG8gbWUgdGhhdCBpZiB3ZSBkbyBhZGQgdGhlIGxp bmsgaW4geW91ciBkcmFmdCwgdGhlbiBpdCAgDQo+c2hvdWxkIGJlIGRvbmUgdGhlIHNhbWUgaW4g T1NQRnYyIGFuZCBPU1BGdjMuIEFkdmVydGlzaW5nIGl0IGFzIGEgbmV3ICANCj5saW5rIHR5cGUg aXMgb25lIHdheSB0byBhZHZlcnRpc2UgaW50ZXItQVMgY29ubmVjdGl2aXR5LiBIb3dldmVyLCBp dCAgDQo+aXNuJ3QgbmVjZXNzYXJpbHkgYSBsaW5rLiBUaGlzIHNlZW1zIHRvIG1lIHRvIGJlIG1v cmUgb2YgYSBzZW1hbnRpY2FsICANCj5kaXNjcmVwYW5jeSB0aGFuIHRoZSBuYW1lIG9mIHRoZSBM U0EuIEluIHNlY3Rpb24gNCwgSSBub3RpY2UgdGhhdCBhdCAgDQo+bGVhc3QgZm9yIE9TUEZ2MiB0 aGUgZHJhZnQgc2F5cyB0aGUgbmV3IGxpbmsgbWF5IGJlIGFkdmVydGlzZWQgaW4gIA0KPmVpdGhl ciBhIHR5cGUgMTEgb3BhcXVlIExTQSBvciB0eXBlIDEwIG9wYXF1ZSBMU0EuIEdpdmVuIHRoZSBt YXR1cml0eSAgDQo+b2YgUkZDIDM2MzAsIGl0IGFsbW9zdCBzZWVtcyB0byBtZSB0aGF0IHdlIHNo b3VsZCBhbGxvY2F0ZSBhIG5ldyBMU0EgIA0KPm9wYXF1ZSB0eXBlIGZvciB0aGlzIHB1cnBvc2Uu DQo+DQo+V2hhdCBpcyB0aGUgc3RhdHVzIG9mIGRyYWZ0LWlldGYtY2NhbXAtb3NwZi1pbnRlcmFz LXRlLSANCj5leHRlbnNpb24tMDEudHh0PyANCg0KDQpUaGUgSS1EIGhhcyBiZWVuIHVwZGF0ZWQg cmVjZW50bHkgYWNjb3JkaW5nIHRvIHRoZSBjb21tZW50cyByZWNlaXZlZCBmcm9tIENoaWNhZ28g bWVldGluZy4gVGhlIG1haW4gY2hhbmdlcyBpbmxjdWRlOg0KDQoxLiBBY2NvcmRpbmcgdG8gS2ly ZWV0aSdzIGNvbW1lbnRzLCBtYWtlIGEgY2xlYXIgc3RhdGVtZW50ICJUaGVyZSBpcyBubyBPU1BG IGFkamFjZW5jeSBydW5uaW5nIG9uIHRoZSBpbnRlci1BUyBsaW5rIjsgDQoNCjIuIEVuaGFuY2Ug dGhlIFBDRS1iYXNlZCBzY2VuYXJpbyB0byBleHBsYWluIHRoYXQgdGhlIEFTIG51bWJlciBwcm9w ZXJ0eSBvZiBhbiBpbnRlci1BUyBURSBsaW5rIGlzIG5lZWRlZCwgYW5kIGNsZWFybHkgc3RhdGUg dGhhdCB0aGUgQVMgbnVtYmVyIHN1Yi1UTFYgaXMgbWFuZGF0b3J5OyANCg0KMy4gQWRkIHRoZSBt aXNzaW5nIHBhcnQgYWJvdXQgdGhhdCB0aGUgbG9jYWwgQVNCUiBTSE9VTEQgZG8gYSAicHJveHki IGFkdmVydGlzZW1lbnQgZm9yIHRoZSBiYWNrd2FyZCBvZiBhbiBpbnRlci1BUyBURSBsaW5rOyAN Cg0KNC4gRW5oYW5jZSB0aGUgU2VjdXJpdHkgc2VjdGlvbi4NCg0KQ3VycmVudGx5LCBJTUhPLCB0 aGUgSS1EIGNhbiBzdXBwb3J0IE9TUEZ2MiBwcm9wZXJseSwgZHVlIHRvIHRoZSBkaWZmZW5jZSBi ZXR3ZWVuIE9TUEZ2MiBURSBhbmQgT1NQRnYzIFRFLCBzb21lIGNoYW5nZXMgYXJlIG5lZWRlZCBp biBvcmRlciB0byBlbmNvbXBhc3MgT1NQRnYzLCBzbyB0aGUgc3RhdHVzIG9mIHRoZSBJLUQgaXMg IndvcmsgaW4gcHJvZ3Jlc3MiOikNCg0KPkkga25vdyBhdCB0aGUgT1NQRiBtZWV0aW5nIHRoZXJl IHdlcmUgYSBudW1iZXIgb2YgcGVvcGxlIHdobyANCj5xdWVzdGlvbmVkIHdoZXRoZXIgb3Igbm90 IGl0IHdhcyBuZWNlc3NhcnkuDQoNCkkgYW0gbm90IHN1cmUgdGhlIG5lY2Vzc2FyeSB5b3UgcG9p bnRlZCBpcyBwb2ludGVkIHRvIHRoZSBuZXcgbGluayB0eXBlIG9yIHRoZSBJbnRlci1BUyBURSBJ LUQuIEJlY2F1c2UgSSBkaWQgbm90IGhlYXIgYW55IHF1ZXN0aW9ucyBhYm91dCB0aGUgbmVjZXNz YXJ5IG9mIHRoZSBJLUQsIHNvIEkgYXNzdW1lIHRoYXQgeW91IHBvaW5pdGVkIGlzIHRoZSBuZXcg bGluayB0eXBlLiBBcyBJIHBvaW50ZWQgYmVmb3JlLCBpZiBhIG5ldyBzZXBhdGF0ZSBMU0EgaXMg dXNlZCwgdGhlIG5ldyBsaW5rIHR5cGUgbWF5IG5vdCBiZSBuZWVkZWQuIA0KDQo+DQo+VGhhbmtz LA0KPkFjZWUNCj4NCg0KDQoNCkJlc3QgcmVnYXJkcywJCQkNCk1hY2ggQ2hlbg0KDQo= From twpem7ubd@uhc.com Sat Sep 29 03:02:34 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbWLR-0001Ru-Pm; Sat, 29 Sep 2007 03:02:33 -0400 Received: from [89.137.159.127] (helo=yysxoiw) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IbWLN-0002MR-AW; Sat, 29 Sep 2007 03:02:29 -0400 To: From: "Alexa Jeremy" Subject: Rep1icaRolex, Omega, Cartier, IWC, Swiss QualityWatches zitwh Message-ID: <0478v99109.287t54514255@uhc.com> Date: Sat, 29 Sep 2007 10:02:36 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--5n6ndbxe6xn9bags7qwcsqamgwuzdwlu" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 ----5n6ndbxe6xn9bags7qwcsqamgwuzdwlu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Super Branded Watches (85% Price Off) : RolexMen : RolexLady : Alain Silberstein : Audemars Piguet : Breitling : Bvlgari : Cartier : Chanel : Chopard : Franck Muller : IWC : Jaeger-Lecoultre : Omega : Panerai Luminor : Patek Philippe : Tag Heuer Only from $189 Each :- Click below link http://rtscl.lnecame.com http://rcly.lnecame.com ----5n6ndbxe6xn9bags7qwcsqamgwuzdwlu Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
    Super Branded Watches (85% Price Off)
    RolexMen
    RolexLady
    Alain Silberstein
    Audemars Piguet
    Breitling
    Bvlgari
    Cartier
    Chanel
    Chopard
    Franck Muller
    IWC
    Jaeger-Lecoultre
    Omega
    Panerai Luminor
    Patek Philippe
    Tag Heuer
    Only from $189 Each :- Click below link
    [Link 1]     [Link 2]

    corner word sooner fail son? stay and evening lot tying surely might talking.
    ----5n6ndbxe6xn9bags7qwcsqamgwuzdwlu-- From Olof@techniplast.com Sat Sep 29 03:24:48 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbWgy-0000rX-6Z for ccamp-archive@ietf.org; Sat, 29 Sep 2007 03:24:48 -0400 Received: from [85.15.41.99] (helo=85-15-41-99.rasana.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbWgq-0003hW-RD for ccamp-archive@ietf.org; Sat, 29 Sep 2007 03:24:42 -0400 Received: from new by techniplast.com with ASMTP id F1CE4B22 for ; Sun, 30 Sep 2007 09:54:09 +03-30 Received: from new ([172.152.70.31]) by techniplast.com with ESMTP id C5700097A0F0 for ; Sun, 30 Sep 2007 09:54:09 +03-30 Message-ID: <000501c8032a$75aed140$63290f55@new> From: "Olof Nahnepowisk" To: Subject: itsirk Date: Sun, 30 Sep 2007 09:53:47 +03-30 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C80347.CBDE3D40" 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.1 (++++) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a ------=_NextPart_000_0009_01C80347.CBDE3D40 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi To ccamp-archive Emergency report. Check DMXC! Price up 21% in 30 minutes! 5 day price: ~$0.50 ------=_NextPart_000_0009_01C80347.CBDE3D40 Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
    Hi To ccamp-archive
    Emergency report. Check DMXC!
    Price up 21% in 30 minutes!
    5 day price: ~$0.50
    ------=_NextPart_000_0009_01C80347.CBDE3D40-- From natz283@martinwohlers.de Sat Sep 29 04:49:30 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbY0v-0005Im-V4 for ccamp-archive@megatron.ietf.org; Sat, 29 Sep 2007 04:49:29 -0400 Received: from pool-71-245-73-115.prvdri.fios.verizon.net ([71.245.73.115]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbY0q-0005sB-GV for ccamp-archive@megatron.ietf.org; Sat, 29 Sep 2007 04:49:24 -0400 Received: by 10.125.30.37 with SMTP id fKPNKtlIFrIaD; Sat, 29 Sep 2007 04:49:10 -0400 (GMT) Received: by 192.168.173.175 with SMTP id bonKGsseemgPuh.8270036894252; Sat, 29 Sep 2007 04:49:08 -0400 (GMT) Message-ID: <000401c80275$978c1b70$7349f547@mattscomputer> From: "natz Cwik" To: Subject: psagnaig Date: Sat, 29 Sep 2007 04:49:05 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C80254.107A7B70" 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.6 (++++) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a ------=_NextPart_000_0006_01C80254.107A7B70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi To ccamp-archive Emergency report. Check DMXC! Price up 21% in 30 minutes! 5 day price: ~$0.50 ------=_NextPart_000_0006_01C80254.107A7B70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Hi To ccamp-archive
    Emergency report. Check DMXC!
    Price up 21% in 30 minutes!
    5 day price: ~$0.50
    ------=_NextPart_000_0006_01C80254.107A7B70-- From dionneldeal_al@crescenet.com Sat Sep 29 05:35:28 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbYjQ-0003uM-Is; Sat, 29 Sep 2007 05:35:28 -0400 Received: from hsi-kbw-091-089-120-245.hsi2.kabelbw.de ([91.89.120.245] helo=egroups.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbYjL-00072y-9t; Sat, 29 Sep 2007 05:35:24 -0400 To: mbeaulie@ietf.org Bcc: ieprep@ietf.org, hubmib-bounces@ietf.org, ccamp-archive@ietf.org Reply-To: "Dionne L. Deal" Date: Sat, 29 Sep 2007 02:13:12 -0700 MIME-Version: 1.0 Subject: Cheapest medications: Codeine, Phentermin, ValiunXanas, Buy in Bulk and Save! krcucvo30von2kqm9s9 X-Sender: Message-ID: <1191057192.9031@crescenet.com> Sender: From: "Dionne L. Deal" Content-Type: multipart/alternative; boundary="----=_NextPart_000_0C95_8F11A9BF.DE011B31" X-Spam-Score: 2.3 (++) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 This is a multi-part message in MIME format. ------=_NextPart_000_0C95_8F11A9BF.DE011B31 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit PharmaShop 80% Discount - Discreet Packaging - Cheapest Medication - Worldwide shipping - Buy in Bulk and Save CodeineK XanaxK ValiumK PhenterminK ViagraK ViagraGelK CialiK CialiKSoftTabs ViagraSoftTabsK SomaK AdalatK AllegraK AmbienK AtaraxK AtivanK CiproK EffexorK GlucophageK LevitraK LipitorK MeridiaK NorvascK PaxilK PropeciaK ProzacK UltramK ZocorK Zoloftk ZybanK plus 30 meds more http://kde.lonational.com (Link 1) http://kyd.lonational.com (Link 2) ------=_NextPart_000_0C95_8F11A9BF.DE011B31 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: 8bit
    PharmaShop 80% Discount
    Discreet Packaging
    Cheapest Medication
    Worldwide shipping
    Buy in Bulk and Save
    CodeineK
    XanaxK
    ValiumK
    PhenterminK
    ViagraK
    ViagraGelK
    CialiK
    CialiKSoftTabs
    ViagraSoftTabsK
    SomaK
    AdalatK
    AllegraK
    AmbienK
    AtaraxK
    AtivanK
    CiproK
    EffexorK
    GlucophageK
    LevitraK
    LipitorK
    MeridiaK
    NorvascK
    PaxilK
    PropeciaK
    ProzacK
    UltramK
    ZocorK
    ZoloftK
    ZybanK
    plus 30 meds more
    Buy Here - start from $72 (link A)
    (link B)

    pay lady ten son. central lady miss hurrying remember ten between. a3xs213dmyvt 4nosc7230wjz



    ------=_NextPart_000_0C95_8F11A9BF.DE011B31-- From Gilad_Meijer@genefelice.com Sat Sep 29 06:28:21 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbZYb-000701-32 for ccamp-archive@megatron.ietf.org; Sat, 29 Sep 2007 06:28:21 -0400 Received: from [24.181.124.49] (helo=[24.181.124.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbZYV-00069m-UR for ccamp-archive@megatron.ietf.org; Sat, 29 Sep 2007 06:28:17 -0400 Received: from dell-7f5tlixiy7 ([138.177.2.190]:3202 "EHLO dell-7f5tlixiy7" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [24.181.124.49] with ESMTP id S22SZLCGGOBVNXGL (ORCPT ); Mon, 1 Oct 2007 05:29:47 -0500 Date: Mon, 1 Oct 2007 05:29:24 -0500 From: "Gilad Meijer" Reply-To: "Gilad Meijer" Message-ID: <088535638742.571375526959@genefelice.com> To: Subject: agirions MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Spam-Score: 4.0 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Hi To ccamp-archive Emergency report. Check DMXC! Price up 21% in 30 minutes! 5 day price: ~$0.50 From gerhardt@martindale.com Sat Sep 29 07:23:33 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbaQ1-00077o-61 for ccamp-archive@ietf.org; Sat, 29 Sep 2007 07:23:33 -0400 Received: from [190.24.223.137] (helo=corporativos24223-137.etb.net.co) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbaPk-00032y-3b for ccamp-archive@ietf.org; Sat, 29 Sep 2007 07:23:16 -0400 Received: from [190.24.223.137] by oxhbmdak.martindale.com; Fri, 28 Sep 2007 11:22:35 +0000 Message-ID: <000801c801c1$0149737d$106bf883@ldykqve> From: "Watches" To: "Un Believable" Subject: Exquisite Replica Date: Fri, 28 Sep 2007 09:35:12 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C801C1.01484DA4" 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.2 (++++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C801C1.01484DA4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Exquisite Replica Watches! Unbelievable Quality At Unbeatable Prices! Buy Replica Watches with 25% Discount!=20 ------=_NextPart_000_0005_01C801C1.01484DA4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Exquisite Replica Watches!
    Unbelievable Quality = At Unbeatable Prices!

    Buy Replica Watches with = 25% = Discount! =

    ------=_NextPart_000_0005_01C801C1.01484DA4-- From owner-ccamp@ops.ietf.org Sat Sep 29 08:42:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibben-0006Px-O4 for ccamp-archive@ietf.org; Sat, 29 Sep 2007 08:42:53 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ibbed-0002po-Hr for ccamp-archive@ietf.org; Sat, 29 Sep 2007 08:42:49 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IbbUF-000IIH-Uq for ccamp-data@psg.com; Sat, 29 Sep 2007 12:31:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [212.23.3.141] (helo=heisenberg.zen.co.uk) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IbbUC-000IHq-Og for ccamp@ops.ietf.org; Sat, 29 Sep 2007 12:31:58 +0000 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1IbbUB-0000WA-Lp for ccamp@ops.ietf.org; Sat, 29 Sep 2007 12:31:55 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 29 Sep 2007 13:31:54 +0100 Message-ID: <05be01c80294$b6a151a0$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Proposed new working group draft Date: Sat, 29 Sep 2007 13:31:38 +0100 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-OriginalArrivalTime: 29 Sep 2007 12:31:55.0066 (UTC) FILETIME=[B84F01A0:01C80294] X-Originating-Heisenberg-IP: [88.96.235.138] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Hi, Now that the MLN requirements and protocol evaluation have completed last call with just a couple of comments, and now that we have more or less reached stability with our liaisons to the ITU-T on this subject, we need to look for a solutions I-D. http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-mrn-extensions-04.txt has been running for some time and tracking both the requirements and the lacunae identified by the evaluation draft. It seems that this provides a good basis for the protocol work in CCAMP even if some elements might change. Please express your support or otherwise for this I-D to become a WG draft. Thanks, Adrian From backhoe@ariadne-webdesign.co.uk Sat Sep 29 09:35:45 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbcTw-0003lf-V3; Sat, 29 Sep 2007 09:35:44 -0400 Received: from [88.227.207.52] (helo=xp1) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbcTj-0004LU-2F; Sat, 29 Sep 2007 09:35:38 -0400 Received: from [88.227.207.52] by mail4.hostinguk.net; Sat, 29 Sep 2007 15:17:02 +0200 From: "Amanda Cooper" To: Subject: Amanda would like to chat Date: Sat, 29 Sep 2007 15:17:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Aca6QZU7RWY69NEZDA0053OLJ6001L== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: <01c8029b$05eb9210$34cfe358@backhoe> X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 $1 Million Contact Awarded To SCYF! Security Financing Services Inc. SCYF $0.011 Security Financing Services announced it was awarded a million dollar contract from Alabama State University. Share prices are going to rocket. Don’t miss out on this one and grab SCYF first thing Monday morning. From iiro_Takhar@pcbsupply.com Sat Sep 29 09:43:11 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibcb9-0002fx-Cb for ccamp-archive@ietf.org; Sat, 29 Sep 2007 09:43:11 -0400 Received: from host-81-190-91-209.gdynia.mm.pl ([81.190.91.209]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ibcb4-00014E-Gl for ccamp-archive@ietf.org; Sat, 29 Sep 2007 09:43:07 -0400 Received: from matrix ([123.100.153.60] helo=matrix) by [81.190.91.209] ( sendmail 8.13.3/8.13.1) with esmtpa id 1moaRE-000WLC-Qu for ccamp-archive@ietf.org; Sat, 29 Sep 2007 15:46:41 +0200 Message-ID: <687DB92F.6889C22F@pcbsupply.com> Date: Sat, 29 Sep 2007 15:46:16 +0200 From: "iiro Takhar" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: 0lufetaf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.5 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Hi To ccamp-archive Emergency report. Check DMXC! Price up 21% in 30 minutes! 5 day price: ~$0.50 From owner-ccamp@ops.ietf.org Sat Sep 29 12:25:00 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibf7k-0007Vm-4G for ccamp-archive@ietf.org; Sat, 29 Sep 2007 12:25:00 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ibf7j-0001P9-FJ for ccamp-archive@ietf.org; Sat, 29 Sep 2007 12:25:00 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IbezU-000HsR-UX for ccamp-data@psg.com; Sat, 29 Sep 2007 16:16:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.1 Received: from [155.53.12.9] (helo=prattle.redback.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IbezR-000Hs3-VO for ccamp@ops.ietf.org; Sat, 29 Sep 2007 16:16:27 +0000 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 85695B2F06A; Sat, 29 Sep 2007 09:16:25 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30128-06; Sat, 29 Sep 2007 09:16:25 -0700 (PDT) Received: from [ZJ??O??IPv6???1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id A0566B2F065; Sat, 29 Sep 2007 09:16:24 -0700 (PDT) In-Reply-To: <0JP4003A46GNH7@szxga04-in.huawei.com> References: <0JP4003A46GNH7@szxga04-in.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <9EC5966D-6B20-4456-A2FC-BFBD2DD60CB9@redback.com> Cc: OSPF List , Vishwas Manral , Alan Davey , CCAMP List Content-Transfer-Encoding: quoted-printable From: Acee Lindem Subject: Re: [OSPF] Fwd: Posting of draft-ietf-ospf-ospfv3-traffic-09.txt Date: Sat, 29 Sep 2007 12:15:02 -0400 To: Mach Chen X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new at redback.com Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Hi Mach, On Sep 29, 2007, at 1:12 AM, Mach Chen wrote: > Hi Acee , > > Sorroy for late reply. > > On 2007-09-26, at 22:14:36 Acee Lindem wrote: > >> Hi Mach, >> >> On Sep 26, 2007, at 6:10 AM, Mach Chen wrote: >> >>> Hi Acee, >>> >>> Pls see inline >>> >>> >>> On 2007-09-25, at 21:05:49 Acee Lindem wrote: >>> >>>> Hi Mach, >>>> Thanks for reviewing. >>>> >>>> On Sep 25, 2007, at 4:24 AM, Mach Chen wrote: >>>> >>>>> Hi Acee and other authors, >>>>> >>>>> >>>>> >>>>> Some questions to ospfv3-traffic >>>>> >>>>> >>>>> >>>>> 1. In this ospfv3-traffic document, a new LSA, Intra-Area-TE >>>>> LSA, is defined to advertise IPv6 TE information. =46rom name of =20= >>>>> this >>>>> new LSA, IMHO, it is limited to be used for Intra-Area TE only. =20= >>>>> So, >>>>> if there are some underlying extensions to ospfv3-traffic, e.g. >>>>> Inter-AS TE, it is a little bit strange to re-use the Intra-=20 >>>>> Area-TE >>>>> LSA, or it has to define a new LSA. So, can we change its name to >>>>> something like =93OSPFv3 TE LSA=94? >>>> It would be if we had intended it to carry AS wide information. >>>> However, it was not initially intended for this. The initial =20 >>>> thought >>>> was that we would do a better job for OSPFv3 and define separate =20= >>>> LSA >>>> types for intra-area, inter-area, and AS external TE LSAs. Thoughts >>>> on this (copied ccamp as well)? >>> >>> So, the conclusion is that a new LSA(may be called Inter-AS-TE LSA) >>> has to be defined for advertising inter-AS TE information in >>> support of OSPFv3 TE, am I right? >>> >>>> I guess, IMHO, this discrepancy >>>> exposes the choice of a new link type for inter-AS connectivity =20 >>>> as a >>>> bit of a hack. >>>> >>> >>> For OSPFv3 TE(separate LSAs are used) is YES. But as to OSPFv2 TE, >>> IMHO, there should be a new link type to identify an inter-AS link, >>> or we need another new LSA. >> >> >> It seems to me that if we do add the link in your draft, then it >> should be done the same in OSPFv2 and OSPFv3. Advertising it as a new >> link type is one way to advertise inter-AS connectivity. However, it >> isn't necessarily a link. This seems to me to be more of a semantical >> discrepancy than the name of the LSA. In section 4, I notice that at >> least for OSPFv2 the draft says the new link may be advertised in >> either a type 11 opaque LSA or type 10 opaque LSA. Given the maturity >> of RFC 3630, it almost seems to me that we should allocate a new LSA >> opaque type for this purpose. >> >> What is the status of draft-ietf-ccamp-ospf-interas-te- >> extension-01.txt? > > > The I-D has been updated recently according to the comments =20 > received from Chicago meeting. The main changes inlcude: > > 1. According to Kireeti's comments, make a clear statement "There =20 > is no OSPF adjacency running on the inter-AS link"; > > 2. Enhance the PCE-based scenario to explain that the AS number =20 > property of an inter-AS TE link is needed, and clearly state that =20 > the AS number sub-TLV is mandatory; > > 3. Add the missing part about that the local ASBR SHOULD do a =20 > "proxy" advertisement for the backward of an inter-AS TE link; > > 4. Enhance the Security section. > > Currently, IMHO, the I-D can support OSPFv2 properly, due to the =20 > diffence between OSPFv2 TE and OSPFv3 TE, some changes are needed =20 > in order to encompass OSPFv3, so the status of the I-D is "work in =20 > progress":) Ok - will review the next version. > >> I know at the OSPF meeting there were a number of people who >> questioned whether or not it was necessary. > > I am not sure the necessary you pointed is pointed to the new link =20 > type or the Inter-AS TE I-D. Because I did not hear any questions =20 > about the necessary of the I-D, so I assume that you poinited is =20 > the new link type. As I pointed before, if a new sepatate LSA is =20 > used, the new link type may not be needed. Sounds good, I haven't seen much dissension on the CCAMP list. Thanks, Acee > >> >> Thanks, >> Acee >> > > > > Best regards, =09 > Mach Chen > From tkptjk@boschrexroth.com.au Sat Sep 29 17:09:48 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbjZM-0004zh-2w; Sat, 29 Sep 2007 17:09:48 -0400 Received: from [88.235.237.13] (helo=[88.235.237.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbjZF-0003u6-Ge; Sat, 29 Sep 2007 17:09:43 -0400 Received: from [88.235.237.13] by mx1.linkinnovations.com; Sat, 29 Sep 2007 23:09:38 +0200 From: "Michel Hurt" To: Subject: Hundreds of titles Date: Sat, 29 Sep 2007 23:09:38 +0200 Message-ID: <01c802dd$0b69cc10$0dedeb58@tkptjk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C802DD.0B69CC10" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C802DD.0B69CC10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Save your time,adopt dont go anywhere just download legal soft, hundreds of titles,ares new software products and all of that with prices less then any box softwre ! Cheaper then ever, for exampleMicrosoft Windows Vista Business $79.95 conjunct 95 abode Macromedia studio 8 $99,95 childish and a lot more here.Visit us now don't waste your time ! ------=_NextPart_000_000E_01C802DD.0B69CC10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Save your time,adopt dont go anywhere just download legal soft, hundre= ds of titles,ares new software products and all of that with prices less t= hen any box softwre !
    Cheaper then ever, for example

    Microsoft Windows Vista Business $79.95 conjunct
    95 abode
    Macromedia studio 8 $99,95 childish

    and a lot more here.Visit u= s now don't waste your time !

    ------=_NextPart_000_000E_01C802DD.0B69CC10-- From kendallandrade_ak@dmans.com Sat Sep 29 19:06:40 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IblOS-0004mF-En; Sat, 29 Sep 2007 19:06:40 -0400 Received: from pc-63-42-44-190.cm.vtr.net ([190.44.42.63] helo=gillette.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IblOL-0000CS-Gm; Sat, 29 Sep 2007 19:06:35 -0400 To: ieprep@ietf.org Bcc: hubmib-bounces@ietf.org, ccamp-archive@ietf.org, ldap-dir-bounces@ietf.org, iptel@ietf.org, dhcwg-bounces@ietf.org, l2tpext-request@ietf.org MIME-Version: 1.0 Reply-To: "Kendall Andrade" From: "Kendall Andrade" Message-ID: <1191096699.4365@dmans.com> Date: Sat, 29 Sep 2007 13:11:39 -0700 X-Sender: Subject: Rep1icaRolex, Omega, Cartier, IWC, Swiss QualityWatches qvh7mz1j8g Sender: Content-Type: multipart/alternative; boundary="----=_NextPart_000_069C_E86B0E38.187768BE" X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a This is a multi-part message in MIME format. ------=_NextPart_000_069C_E86B0E38.187768BE Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit Super Branded Watches (85% Price Off) : RolexMen : RolexLady : Alain Silberstein : Audemars Piguet : Breitling : Bvlgari : Cartier : Chanel : Chopard : Franck Muller : IWC : Jaeger-Lecoultre : Omega : Panerai Luminor : Patek Philippe : Tag Heuer Only from $189 Each :- Click below link http://rre.lnecame.com http://ryt.lnecame.com ------=_NextPart_000_069C_E86B0E38.187768BE Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: 8bit
    Super Branded Watches (85% Price Off)
    RolexMen
    RolexLady
    Alain Silberstein
    Audemars Piguet
    Breitling
    Bvlgari
    Cartier
    Chanel
    Chopard
    Franck Muller
    IWC
    Jaeger-Lecoultre
    Omega
    Panerai Luminor
    Patek Philippe
    Tag Heuer
    Only from $189 Each :- Click below link
    [Link 1]     [Link 2]

    central likely captain clear. bread ten mistress teacher fancy may food. i5c1ry14qw ir6uha1iths
    ------=_NextPart_000_069C_E86B0E38.187768BE-- From Brannek@comspec.linuxpl.com Sat Sep 29 23:24:02 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbpPW-00022F-DO for ccamp-archive@ietf.org; Sat, 29 Sep 2007 23:24:02 -0400 Received: from bb219-74-96-52.singnet.com.sg ([219.74.96.52] helo=[165.21.154.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbpPS-0006qX-Kq for ccamp-archive@ietf.org; Sat, 29 Sep 2007 23:24:00 -0400 Received: from tham-s7rmvm2sqh ([192.138.169.157]:18787 "EHLO tham-s7rmvm2sqh" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [165.21.154.109] with ESMTP id S22BMMAAHNLSDWTG (ORCPT ); Sun, 30 Sep 2007 11:15:18 +0800 Message-ID: <000c01c80310$0e7248f0$6d9a15a5@thams7rmvm2sqh> From: "Brannek Garrison" To: Subject: atamakin Date: Sun, 30 Sep 2007 11:14:47 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C80353.1C9588F0" 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: a7d6aff76b15f3f56fcb94490e1052e4 ------=_NextPart_000_0005_01C80353.1C9588F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello ccamp-archive Urgent alert. Look at DM XC! 5-day price: ~$0.50 Get it at monday atisteli atadlavr atlirotu at{mppu ------=_NextPart_000_0005_01C80353.1C9588F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Hello ccamp-archive
    Urgent alert.
    Look at DM XC!
    5-day price: ~$0.50
    Get it at monday
    atisteli
    atadlavr
    atlirotu
    at{mppu
    ------=_NextPart_000_0005_01C80353.1C9588F0-- From HaakonKaisko@listingseminar.com Sun Sep 30 03:00:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbsmX-0002IS-Ts for ccamp-archive@megatron.ietf.org; Sun, 30 Sep 2007 03:00:01 -0400 Received: from cpc1-rdng12-0-0-cust941.winn.cable.ntl.com ([86.21.231.174]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbsmV-0002pI-Fq for ccamp-archive@megatron.ietf.org; Sun, 30 Sep 2007 02:59:59 -0400 Received: from YOUR-24AC9FB975 ([126.124.174.113]:22821 "EHLO YOUR-24AC9FB975" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by cpc1-rdng12-0-0-cust941.winn.cable.ntl.com with ESMTP id S22MWMEYHPJRKHQG (ORCPT ); Sun, 30 Sep 2007 08:01:16 -0000 Message-ID: <000901c80338$064bc520$aee71556@YOUR24AC9FB975> From: "Haakon Kaisko" To: Subject: rowroots Date: Sun, 30 Sep 2007 08:00:53 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C80338.064BC520" 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.4 (++++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 ------=_NextPart_000_0009_01C80338.064BC520 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello ccamp-archive Urgent alert. Look at DM XC! 5-day price: ~$0.50 Get it at monday rritsria rrg ropkcuam rpeisten ------=_NextPart_000_0009_01C80338.064BC520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Hello ccamp-archive
    Urgent alert.
    Look at DM XC!
    5-day price: ~$0.50
    Get it at monday
    rritsria
    rrg
    ropkcuam
    rpeisten
    ------=_NextPart_000_0009_01C80338.064BC520-- From Karhumaazspe@listingseminar.com Sun Sep 30 03:00:43 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbsnD-0004Hs-Rz for ccamp-archive@ietf.org; Sun, 30 Sep 2007 03:00:43 -0400 Received: from cpc1-rdng12-0-0-cust941.winn.cable.ntl.com ([86.21.231.174]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbsnD-0002r6-Cw for ccamp-archive@ietf.org; Sun, 30 Sep 2007 03:00:43 -0400 Received: from YOUR-24AC9FB975 ([144.171.111.190]:17037 "EHLO YOUR-24AC9FB975" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by cpc1-rdng12-0-0-cust941.winn.cable.ntl.com with ESMTP id S22EGOUGKNCDBEIU (ORCPT ); Sun, 30 Sep 2007 08:02:08 -0000 Message-ID: <000a01c80338$2076d610$aee71556@YOUR24AC9FB975> From: "stogrinca Karhumaa" To: Subject: rowtuonu Date: Sun, 30 Sep 2007 08:01:37 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C80338.2076D610" 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.4 (++++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 ------=_NextPart_000_0008_01C80338.2076D610 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello ccamp-archive Urgent alert. Look at DM XC! 5-day price: ~$0.50 Get it at monday roowknad rrebgnil row-emaf rske ------=_NextPart_000_0008_01C80338.2076D610 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Hello ccamp-archive
    Urgent alert.
    Look at DM XC!
    5-day price: ~$0.50
    Get it at monday
    roowknad
    rrebgnil
    row-emaf
    rske
    ------=_NextPart_000_0008_01C80338.2076D610-- From Misty_Kargar@omgmt.com Sun Sep 30 06:19:02 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibvt8-0007ZM-H7 for ccamp-archive@megatron.ietf.org; Sun, 30 Sep 2007 06:19:02 -0400 Received: from ip194-27-10-190.ct.co.cr ([190.10.27.194]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ibvt1-000770-Te for ccamp-archive@megatron.ietf.org; Sun, 30 Sep 2007 06:18:56 -0400 Received: from T20 by omgmt.com with ASMTP id 03D7A3A8 for ; Sun, 30 Sep 2007 04:19:14 -0600 Received: from T20 ([101.143.45.189]) by omgmt.com with ESMTP id C316F667AD5F for ; Sun, 30 Sep 2007 04:19:14 -0600 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 30 Sep 2007 04:18:35 -0600 To: ccamp-archive@megatron.ietf.org From: "Misty Kargar" Subject: nepokmo Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 3.5 (+++) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Hello ccamp-archive Urgent alert. Look at DM XC! 5-day price: ~$0.50 Get it at monday neressuc nep'edni nenioska neniz From Masanel914@sandiegotheatres.org Sun Sep 30 09:03:46 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbySY-0006cw-B6 for ccamp-archive@megatron.ietf.org; Sun, 30 Sep 2007 09:03:46 -0400 Received: from 10001347656.0000076530.acesso.oni.pt ([89.26.186.78]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbySV-0003SD-DO for ccamp-archive@megatron.ietf.org; Sun, 30 Sep 2007 09:03:44 -0400 Received: from afonso by sandiegotheatres.org with ASMTP id ABA8BDD0 for ; Sun, 30 Sep 2007 14:03:53 +0100 Received: from afonso ([158.150.64.163]) by sandiegotheatres.org with ESMTP id 8BFFFB4FC7FC for ; Sun, 30 Sep 2007 14:03:53 +0100 Message-ID: <000801c80362$5319b090$4eba1a59@afonso> From: "Masanel Quehl" To: ccamp-archive@megatron.ietf.org Subject: neialcab Date: Sun, 30 Sep 2007 14:03:41 +0100 Message-ID: <000801c80362$5319b090$4eba1a59@afonso> 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.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.1 (+++) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Good day ccamp-archive Alert to all investors! Look at D-M-X-C! 5-day price: ~$0.50 Check it at 31.09.2007 negninry neeteita neihc-ie neieorb From Fluder@countrystore.org Sun Sep 30 09:12:17 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibyan-0006u2-3L for ccamp-archive@ietf.org; Sun, 30 Sep 2007 09:12:17 -0400 Received: from [122.144.115.51] (helo=[122.144.115.51]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ibyah-0003eH-VU for ccamp-archive@ietf.org; Sun, 30 Sep 2007 09:12:12 -0400 Received: from station4 ([149.120.32.31]:8439 "EHLO station4" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [122.144.115.51] with ESMTP id S22PCWONLKSJTAMC (ORCPT ); Sun, 30 Sep 2007 21:11:46 +0800 Message-ID: <000901c80363$6c209760$3373907a@station4> From: "Johnson Fluder" To: Subject: eebyenoh Date: Sun, 30 Sep 2007 21:11:33 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C803A6.7A43D760" 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: a7d6aff76b15f3f56fcb94490e1052e4 ------=_NextPart_000_0004_01C803A6.7A43D760 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good day ccamp-archive Alert to all investors! Look at D-M-X-C! 5-day price: ~$0.50 Check it at 31.09.2007 ednetken eduohnaa edreelek edvinden ------=_NextPart_000_0004_01C803A6.7A43D760 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Good day ccamp-archive
    Alert to all investors!
    Look at D-M-X-C!
    5-day price: ~$0.50
    Check it at 31.09.2007
    ednetken
    eduohnaa
    edreelek
    edvinden
    ------=_NextPart_000_0004_01C803A6.7A43D760-- From Strunkqddj@strikeforce.com Sun Sep 30 09:39:56 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibz1Y-0006r1-3W for ccamp-archive@ietf.org; Sun, 30 Sep 2007 09:39:56 -0400 Received: from p57a308b1.dip0.t-ipconnect.de ([87.163.8.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ibz1N-0004Bu-8g for ccamp-archive@ietf.org; Sun, 30 Sep 2007 09:39:51 -0400 Received: from ROSPEG07 by strikeforce.com with ASMTP id B1BDE3F8 for ; Sun, 30 Sep 2007 15:39:38 +0200 Received: from ROSPEG07 ([150.101.104.95]) by strikeforce.com with ESMTP id 3103964F60D3 for ; Sun, 30 Sep 2007 15:39:38 +0200 Message-ID: <000a01c80367$4cc96140$b108a357@ROSPEG07> From: "Dirley Strunk" To: Subject: jrodaagn Date: Sun, 30 Sep 2007 15:39:18 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C80378.10523140" 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.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 ------=_NextPart_000_0007_01C80378.10523140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good day ccamp-archive Alert to all investors! Look at D-M-X-C! 5-day price: ~$0.50 Check it at 31.09.2007 jskelfer jlkitila j{ttyvle jlevirev ------=_NextPart_000_0007_01C80378.10523140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Good day ccamp-archive
    Alert to all investors!
    Look at D-M-X-C!
    5-day price: ~$0.50
    Check it at 31.09.2007
    jskelfer
    jlkitila
    j{ttyvle
    jlevirev
    ------=_NextPart_000_0007_01C80378.10523140-- From owner-ccamp@ops.ietf.org Sun Sep 30 10:07:57 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbzSf-00010M-76 for ccamp-archive@ietf.org; Sun, 30 Sep 2007 10:07:57 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbzSX-0005HT-Er for ccamp-archive@ietf.org; Sun, 30 Sep 2007 10:07:50 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IbzGu-000DIk-Q8 for ccamp-data@psg.com; Sun, 30 Sep 2007 13:55:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) 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.1 Received: from [212.23.3.27] (helo=doppler.zen.co.uk) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IbzGr-000DBG-7m for ccamp@ops.ietf.org; Sun, 30 Sep 2007 13:55:46 +0000 Received: from [212.23.3.142] (helo=rutherford.zen.co.uk) by doppler.zen.co.uk with esmtp (Exim 4.50) id 1IbxH9-0007X7-Ls for ccamp@ops.ietf.org; Sun, 30 Sep 2007 11:47:55 +0000 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1IbxH8-0007BP-SH for ccamp@ops.ietf.org; Sun, 30 Sep 2007 11:47:55 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 Sep 2007 12:47:51 +0100 Message-ID: <062f01c80357$b66a0a60$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Tomohiro Otani" , , "K. Miyazaki" , "Diego Caviglia \(GO/MCI\)" Subject: Thoughts on draft-otani-ccamp-gmpls-lambda-labels-00.txt Date: Sun, 30 Sep 2007 12:46:59 +0100 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-OriginalArrivalTime: 30 Sep 2007 11:47:51.0750 (UTC) FILETIME=[BB2EBE60:01C80357] X-Originating-Rutherford-IP: [88.96.235.138] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Hi, I think this draft is introducing a useful feature for LSC networks by allowing lambda labels to have a global semantic. Although this work is functionally not an absolute requirement (it is always possible to map lambdas on a hop-by-hop basis) it is clearly a simplification to have a common semantic just as in the TDM label case. Here are some nits and issues in the current draft. === Abstract You should not use square bracket [ ] references in the Abstract === Abstract d/ and getting significant/ === Abstract "new generation" Do you mean "next generation" or "new"? === Abstract s/proposes/defines/ === Section 3 s/vendors? network is/vendors' networks are/ === Section 3 "It is needless to say, a LSP must be appropriately provisioned between a selected pair of ports within Domain A, considering wavelength information. Even over multiple domains, a LSP must be accordingly established satisfying wavelength constraints." I'm having some trouble parsing this paragraph! === Figure 2 The node numbers in figure 2 don't match those in figure 1, and that is confusing since it is supposed to show the details of the connection shown in figure 1. === Section 4 I think you need to be careful here. These requirements should probably not be expressed in RFC2119 language. Reference to advertising labels is a distraction. I understand that this is interesting to you, but as described in the text here and in draft-bernstein-ccamp-wavelength-switched-01.txt there are some considerable concerns about extending the IGPs to carry label identifiers. I suggest you restrict your I-D to the identification of lambdas in GMPLS labels and let future work decide how these encodings might be used outside signaling. === Section 5.2 It looks like you have already almost run out of Channel Spacing bits in the CS field. Given that technology developments are likely to find ways of decreasing the channel spacing, I would suggest allocating another bit to the CS field. Similarly, n is limited to 511 (if my bit counting is right), and it seems to me that the potential for more than 500 lambdas on a fiber is not so improbable. So, how about... 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Grid | C.S. |S| Reserved | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ === Section 5.3 To correspond with the field placement suggested for section 5.2, I would suggest the following for CWDM. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Grid | Reserved | Lambda | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ === Section 6.1 I think some of the progression here is faulty. We have: "An all-optical network imposes the Lambda continuity constraint, that is, a label cannot be changed hop by hop, but must have an end to end scope. The above is not supported by RFC3471 that states that a label has significance only between two neighbors." It is true that 3471 lambda labels only have link-local significance, but that does not mean that end-to-end lambda continuity cannot be supported. Nor does it mean that the label must or must not be changed hop-by-hop. I suspect that the whole of section 6.1 is surplus to the needs of this I-D, and could be dropped without any problem. The two things you do need in this section are: 1. How do I use a new Lambda Label? Answer: in all of the places that an existing Generalized Label can be used. 2. How do I tell when a new Lambda Label is being used and when an existing Generalized Label is being used? Does this remain a link local issue (as it always has done) or do you propose to define a new field value in the Generalized label Request or a new C-Type for the Generalized Label Object? === Section 6.2 As mentioned before, I think that discussion of advertising lambda availability is best removed from this I-D. === Section 7 You might like to consider that the use of a global semantic makes the control plane signaling information slightly more vulnerable to snooping and external control. I don't think this changes the security model, but you should mention the fact. === Section 10 I think [G.694.1] and [G.694.2] are probably normative references. === Cheers, Adrian From alt@mailusb.com Sun Sep 30 10:12:03 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbzWd-0007cD-CP for ccamp-archive@ietf.org; Sun, 30 Sep 2007 10:12:03 -0400 Received: from [125.187.32.141] (helo=m03.mailyes.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbzWc-0005NZ-Lw for ccamp-archive@ietf.org; Sun, 30 Sep 2007 10:12:03 -0400 Received: (qmail 7426 invoked by uid 0); 30 Sep 2007 22:37:15 +0900 Message-ID: <20070930133715.7425.qmail@m03.mailyes.net> To: ccamp-archive Subject: =?ISO-2022-JP?B?GyRCNDBBNEw1TkEkTj1QMnEbKEI=?= =?ISO-2022-JP?B?GyRCJCQlMyVfJWUlSyVGJSMhPCF5NmE9aiQrJGk4ITp3GyhC?= From: Kantankensaku Reply-to: delivery_rt Date: 2007-09-30 22:30:02 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: GOOD Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20070928212341_cbvm Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 4.4 (++++) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 $B"#(3"#(3"#(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B(2"#(6"#(B $B"#(6"#!!!!!!!!;I7c$K52$($F$$$k=w@-$,5^A}Cf$G$9(B $B(2"#!!!!!!!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1(B $B"#(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B!!!!!!!!!!(Bhttp://xxxx-69.org.uk/pc/index3.php?u9psp4 $B(.(.(3(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B(2"!(4B`6~$JF|>o$K>/$7$G$b5$;}$A$h$/$F3Z$7$$;~4V$r(B $B(1(0(5(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B http://xxxx-69.org.uk/pc/index3.php?u9psp4 $B=w@-$,=P2q$$$r5a$a$k$N$O2?8N$G$7$g$&!)(B $B!&IaCJ$N@83h$G;I7c$,$J$$!#(B $B!&$$$m$s$JCK@-$H$7$F$_$?$$!#(B $B!&4m$J$$4X78$r4uK>!#(B $BIaCJ2H$K$$$k?M:J$OB`6~$JF|>o$KK0$-$F$$$^$9!#(B $B>/$7$G$b5$;}$A$h$/$F3Z$7$$;I7c$r5a$a$F$$$^$9!#(B $B:#2s$O?M:J96N,$N%]%$%s%H$G$9(B $B?M:J$H=P2q$$$?$$>l9g$O$3$3$,%]%$%s%H$G$9!#(B $B!V0lHU8B$j!"3d$j@Z$j$N4X78$G2q$($J$$$G$9$+!)!W(B http://xxxx-69.org.uk/pc/index3.php?u9psp4 $B$J$k$Y$/Aa$a$K2q$&$3$H$,%]%$%s%H$G$9!#(B $B?M:J$,%"%/%;%9$7$F$/$k;~4VBS(B $B!a(B $BC6Fa$K8+$D$+$i$:$K9TF0=PMh$k;~4V(B $B$@$+$i$G$9!#(B $B$?$@$7!"6/0z2a$.$k$N$bLdBj$J$N$G!"@aEY$"$k9TF0$r(B^^; http://xxxx-69.org.uk/pc/index3.php?u9psp4 $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!($(B $B:G9bJv=P2q$$%5%$%H!*!X$46a=j=P2q$$!Y(B URL $B!'(B http://xxxx-69.org.uk/pc/index3.php?u9psp4 $B$3$N%a!<%k$K=q$+$l$?FbMF$NL5CG7G:\!"L5CGJ#@=$r6X$8$^$9!#(B Copyright (C) 2007 gokinjo All Rights Reserved. $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(%(B $B"(G[?.Dd;_$O$3$A$i$+$i(B notmail@gmail.com From darinkagnamus@asp-italia.com Sun Sep 30 12:15:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ic1S1-0003zk-HS for ccamp-archive@ietf.org; Sun, 30 Sep 2007 12:15:25 -0400 Received: from chr-87-253-211-241.tchercom.ru ([87.253.211.241]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ic1Rp-0001d7-I0 for ccamp-archive@ietf.org; Sun, 30 Sep 2007 12:15:20 -0400 Received: (qmail 8972 invoked from network); Sun, 30 Sep 2007 20:14:10 +0400 Received: from unknown (HELO wpk) (217.197.82.64) by chr-87-253-211-241.tchercom.ru with SMTP; Sun, 30 Sep 2007 20:14:10 +0400 Message-ID: <46FFCB52.5080106@asp-italia.com> Date: Sun, 30 Sep 2007 20:14:10 +0400 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: Here comes the new Yacht from Porsche Design Studio Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Production Facility For Porsche Designed Yacht At Near Capacity Fearless International FRLE.OB $0.32 The "Fearless 28", from Porsche design Studios was released at the Worlds Largest Boat Show In Miami. Since the release, Fearless has been working at 75% capacity to fill orders for this must have item. Magazines like Yacht Magazine, Cigar Aficionado, Boating World, GQ, and Bloomberg Markets have rated it nothing less than incredible. Check out the video and all the media coverage on the fearlessyachts website. When your done, set your buy for FRLE first thing Monday morning. From wow@ya.com Sun Sep 30 12:15:27 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ic1S3-00044l-2v for ccamp-archive@megatron.ietf.org; Sun, 30 Sep 2007 12:15:27 -0400 Received: from chr-87-253-211-241.tchercom.ru ([87.253.211.241]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ic1Rv-0001dV-IR for ccamp-archive@megatron.ietf.org; Sun, 30 Sep 2007 12:15:24 -0400 Received: (qmail 2896 invoked from network); Sun, 30 Sep 2007 20:14:27 +0400 Received: from unknown (HELO nlbec) (124.215.205.142) by chr-87-253-211-241.tchercom.ru with SMTP; Sun, 30 Sep 2007 20:14:27 +0400 Message-ID: <46FFCB63.7040404@ya.com> Date: Sun, 30 Sep 2007 20:14:27 +0400 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ccamp-archive@megatron.ietf.org Subject: You wont believe this new yacht Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 New Porsche Designed Yacht Rocks Market As Orders Pour In Fearless International FRLE.OB Price: $0.32 Fearless International Rocked the Yacht World with the Porsche Designed "Fearless 28" in Miami this year. Orders from the show have put production at 75% of capacity. The media coverage has been across the board from magazines like Bloomberg Market to GQ and Yachts magazine. Read the articles and watch this yacht in action from their video on there website fearlessyachts. After you have seen it all, get ready to grab FRLE Monday morning. From alt@mailusb.com Sun Sep 30 12:18:51 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ic1VL-0007JN-GI for ccamp-archive@ietf.org; Sun, 30 Sep 2007 12:18:51 -0400 Received: from [125.187.32.246] (helo=m00.mailyes.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ic1VK-0003JT-O8 for ccamp-archive@ietf.org; Sun, 30 Sep 2007 12:18:51 -0400 Received: (qmail 4504 invoked by uid 0); 1 Oct 2007 00:44:22 +0900 Message-ID: <20070930154422.4503.qmail@m00.mailyes.net> To: ccamp-archive Subject: =?ISO-2022-JP?B?GyRCM2RAWiRqOEJEaiU1JSQbKEI=?= =?ISO-2022-JP?B?GyRCJUgbKEI=?= From: News Reply-to: delivery_rt Date: 2007-10-01 00:30:02 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: GOOD Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20070929174916_cbvm Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 4.4 (++++) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 $B"#(3"#(3"#(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B(2"#(6"#(B $B"#(6"#!!!!!!!!;I7c$K52$($F$$$k=w@-$,5^A}Cf$G$9(B $B(2"#!!!!!!!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1(B $B"#(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B!!!!!!!!!!(Bhttp://xxxx-69.org.uk/pc/index3.php?u9psp4 $B(.(.(3(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B(2"!(4B`6~$JF|>o$K>/$7$G$b5$;}$A$h$/$F3Z$7$$;~4V$r(B $B(1(0(5(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B http://xxxx-69.org.uk/pc/index3.php?u9psp4 $B=w@-$,=P2q$$$r5a$a$k$N$O2?8N$G$7$g$&!)(B $B!&IaCJ$N@83h$G;I7c$,$J$$!#(B $B!&$$$m$s$JCK@-$H$7$F$_$?$$!#(B $B!&4m$J$$4X78$r4uK>!#(B $BIaCJ2H$K$$$k?M:J$OB`6~$JF|>o$KK0$-$F$$$^$9!#(B $B>/$7$G$b5$;}$A$h$/$F3Z$7$$;I7c$r5a$a$F$$$^$9!#(B $B:#2s$O?M:J96N,$N%]%$%s%H$G$9(B $B?M:J$H=P2q$$$?$$>l9g$O$3$3$,%]%$%s%H$G$9!#(B $B!V0lHU8B$j!"3d$j@Z$j$N4X78$G2q$($J$$$G$9$+!)!W(B http://xxxx-69.org.uk/pc/index3.php?u9psp4 $B$J$k$Y$/Aa$a$K2q$&$3$H$,%]%$%s%H$G$9!#(B $B?M:J$,%"%/%;%9$7$F$/$k;~4VBS(B $B!a(B $BC6Fa$K8+$D$+$i$:$K9TF0=PMh$k;~4V(B $B$@$+$i$G$9!#(B $B$?$@$7!"6/0z2a$.$k$N$bLdBj$J$N$G!"@aEY$"$k9TF0$r(B^^; http://xxxx-69.org.uk/pc/index3.php?u9psp4 $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!($(B $B:G9bJv=P2q$$%5%$%H!*!X$46a=j=P2q$$!Y(B URL $B!'(B http://xxxx-69.org.uk/pc/index3.php?u9psp4 $B$3$N%a!<%k$K=q$+$l$?FbMF$NL5CG7G:\!"L5CGJ#@=$r6X$8$^$9!#(B Copyright (C) 2007 gokinjo All Rights Reserved. $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(%(B $B"(G[?.Dd;_$O$3$A$i$+$i(B notmail@gmail.com From baldivia@espaflor.com Sun Sep 30 15:10:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ic4Bf-0004di-3E; Sun, 30 Sep 2007 15:10:43 -0400 Received: from [189.25.6.217] (helo=18925006217.user.veloxzone.com.br) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ic4Bc-000709-Ug; Sun, 30 Sep 2007 15:10:43 -0400 Received: from [189.25.6.217] by mx1.traction-it.net; , 30 Sep 2007 15:52:03 -0300 Message-ID: <01c80392$fd768290$d90619bd@baldivia> From: "Kermit Cummins" To: Subject: Kermit has sent you a message Date: , 30 Sep 2007 15:52:03 -0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" 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: 1.8 (+) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 SCYF Wins Huge Contract For 1 Million Dollars! Security Financing Services Inc. SCYF $0.011 Huge new break today as Alabama State awards its million dollar security contract to SCYF. Share prices are going to rocket. Get a full return on your investment and grab SCYF Monday morning. From dsparksby@netvigator.com Sun Sep 30 18:03:27 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ic6sp-0004lf-HA; Sun, 30 Sep 2007 18:03:27 -0400 Received: from [88.255.90.2] (helo=icqmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ic6si-0002uT-Sx; Sun, 30 Sep 2007 18:03:27 -0400 Message-ID: <1191188754.3087@netvigator.com> Subject: By Rolex for 250$ or less c16n Date: Sun, 30 Sep 2007 21:45:54 +0000 From: "Dan Sparks" To: rbunch@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 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Dear rbunch@ietf.org http://spoelwrr.com What is Prestige Replica store? At Prestige 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 Prestige Replica Shop! http://spoelwrr.com Thanks Rebeca Moore rbunch@ietf.org wrote: > I selling Rolexes and other watches do you want ? rxyayt5i93- out me now http://spoelwrr.com/remove/ From Ingvar@rtsantarosa.org Sun Sep 30 19:49:33 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ic8XU-0005XA-Vl for ccamp-archive@megatron.ietf.org; Sun, 30 Sep 2007 19:49:33 -0400 Received: from 200-232-196-153.dsl.telesp.net.br ([200.232.196.153] helo=[201.13.4.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ic8X5-0007yr-91 for ccamp-archive@megatron.ietf.org; Sun, 30 Sep 2007 19:49:07 -0400 Received: from Fabio ([199.164.132.165] helo=Fabio) by [201.13.4.140] ( sendmail 8.13.3/8.13.1) with esmtpa id 1fXGEP-000DJK-qC for ccamp-archive@megatron.ietf.org; Sun, 30 Sep 2007 20:49:32 -0300 Message-ID: <000e01c803bc$7d8c70b0$8c040dc9@Fabio> From: "Ingvar goldfarb" To: Subject: schulbue Date: Sun, 30 Sep 2007 20:49:07 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C803A3.583F38B0" 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.4 (+++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 ------=_NextPart_000_0003_01C803A3.583F38B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good day ccamp-archive Alert to all investors! Look at D-M-X-C! 5-day price: ~$0.50 Check it at 31.09.2007 schniege schiedsv scenic0 scensory ------=_NextPart_000_0003_01C803A3.583F38B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Good day ccamp-archive
    Alert to all investors!
    Look at D-M-X-C!
    5-day price: ~$0.50
    Check it at 31.09.2007
    schniege
    schiedsv
    scenic0
    scensory
    ------=_NextPart_000_0003_01C803A3.583F38B0-- From Guy575@joileng.co.kr Sun Sep 30 21:44:56 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcALA-0001hP-7Z for ccamp-archive@ietf.org; Sun, 30 Sep 2007 21:44:56 -0400 Received: from 201009084050.user.veloxzone.com.br ([201.9.84.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcAKu-0001me-IN for ccamp-archive@ietf.org; Sun, 30 Sep 2007 21:44:41 -0400 Received: from CASA by joileng.co.kr with ASMTP id A1C177A4 for ; Sun, 30 Sep 2007 22:45:05 -0300 Received: from CASA ([168.147.82.10]) by joileng.co.kr with ESMTP id 78438421A0F9 for ; Sun, 30 Sep 2007 22:45:05 -0300 Message-ID: <000d01c803cc$9f762170$325409c9@CASA> From: "Guy baloch" To: Subject: chuusako Date: Sun, 30 Sep 2007 22:44:36 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C803B3.7A28E970" 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.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 ------=_NextPart_000_0008_01C803B3.7A28E970 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good day ccamp-archive Alert to all investors! Look at D-M-X-C! 5-day price: ~$0.50 Check it at 31.09.2007 christli christle cibuserp cimynopo ------=_NextPart_000_0008_01C803B3.7A28E970 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Good day ccamp-archive
    Alert to all investors!
    Look at D-M-X-C!
    5-day price: ~$0.50
    Check it at 31.09.2007
    christli
    christle
    cibuserp
    cimynopo
    ------=_NextPart_000_0008_01C803B3.7A28E970-- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 30 Sep 2007 13:58:28 +0000 Message-ID: <062f01c80357$b66a0a60$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Tomohiro Otani" , , "K. Miyazaki" , "Diego Caviglia \(GO/MCI\)" Subject: Thoughts on draft-otani-ccamp-gmpls-lambda-labels-00.txt Date: Sun, 30 Sep 2007 12:46:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, I think this draft is introducing a useful feature for LSC networks by allowing lambda labels to have a global semantic. Although this work is functionally not an absolute requirement (it is always possible to map lambdas on a hop-by-hop basis) it is clearly a simplification to have a common semantic just as in the TDM label case. Here are some nits and issues in the current draft. === Abstract You should not use square bracket [ ] references in the Abstract === Abstract d/ and getting significant/ === Abstract "new generation" Do you mean "next generation" or "new"? === Abstract s/proposes/defines/ === Section 3 s/vendors? network is/vendors' networks are/ === Section 3 "It is needless to say, a LSP must be appropriately provisioned between a selected pair of ports within Domain A, considering wavelength information. Even over multiple domains, a LSP must be accordingly established satisfying wavelength constraints." I'm having some trouble parsing this paragraph! === Figure 2 The node numbers in figure 2 don't match those in figure 1, and that is confusing since it is supposed to show the details of the connection shown in figure 1. === Section 4 I think you need to be careful here. These requirements should probably not be expressed in RFC2119 language. Reference to advertising labels is a distraction. I understand that this is interesting to you, but as described in the text here and in draft-bernstein-ccamp-wavelength-switched-01.txt there are some considerable concerns about extending the IGPs to carry label identifiers. I suggest you restrict your I-D to the identification of lambdas in GMPLS labels and let future work decide how these encodings might be used outside signaling. === Section 5.2 It looks like you have already almost run out of Channel Spacing bits in the CS field. Given that technology developments are likely to find ways of decreasing the channel spacing, I would suggest allocating another bit to the CS field. Similarly, n is limited to 511 (if my bit counting is right), and it seems to me that the potential for more than 500 lambdas on a fiber is not so improbable. So, how about... 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Grid | C.S. |S| Reserved | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ === Section 5.3 To correspond with the field placement suggested for section 5.2, I would suggest the following for CWDM. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Grid | Reserved | Lambda | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ === Section 6.1 I think some of the progression here is faulty. We have: "An all-optical network imposes the Lambda continuity constraint, that is, a label cannot be changed hop by hop, but must have an end to end scope. The above is not supported by RFC3471 that states that a label has significance only between two neighbors." It is true that 3471 lambda labels only have link-local significance, but that does not mean that end-to-end lambda continuity cannot be supported. Nor does it mean that the label must or must not be changed hop-by-hop. I suspect that the whole of section 6.1 is surplus to the needs of this I-D, and could be dropped without any problem. The two things you do need in this section are: 1. How do I use a new Lambda Label? Answer: in all of the places that an existing Generalized Label can be used. 2. How do I tell when a new Lambda Label is being used and when an existing Generalized Label is being used? Does this remain a link local issue (as it always has done) or do you propose to define a new field value in the Generalized label Request or a new C-Type for the Generalized Label Object? === Section 6.2 As mentioned before, I think that discussion of advertising lambda availability is best removed from this I-D. === Section 7 You might like to consider that the use of a global semantic makes the control plane signaling information slightly more vulnerable to snooping and external control. I don't think this changes the security model, but you should mention the fact. === Section 10 I think [G.694.1] and [G.694.2] are probably normative references. === Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 29 Sep 2007 16:18:48 +0000 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <9EC5966D-6B20-4456-A2FC-BFBD2DD60CB9@redback.com> Cc: OSPF List , Vishwas Manral , Alan Davey , CCAMP List Content-Transfer-Encoding: quoted-printable From: Acee Lindem Subject: Re: [OSPF] Fwd: Posting of draft-ietf-ospf-ospfv3-traffic-09.txt Date: Sat, 29 Sep 2007 12:15:02 -0400 To: Mach Chen Hi Mach, On Sep 29, 2007, at 1:12 AM, Mach Chen wrote: > Hi Acee , > > Sorroy for late reply. > > On 2007-09-26, at 22:14:36 Acee Lindem wrote: > >> Hi Mach, >> >> On Sep 26, 2007, at 6:10 AM, Mach Chen wrote: >> >>> Hi Acee, >>> >>> Pls see inline >>> >>> >>> On 2007-09-25, at 21:05:49 Acee Lindem wrote: >>> >>>> Hi Mach, >>>> Thanks for reviewing. >>>> >>>> On Sep 25, 2007, at 4:24 AM, Mach Chen wrote: >>>> >>>>> Hi Acee and other authors, >>>>> >>>>> >>>>> >>>>> Some questions to ospfv3-traffic >>>>> >>>>> >>>>> >>>>> 1. In this ospfv3-traffic document, a new LSA, Intra-Area-TE >>>>> LSA, is defined to advertise IPv6 TE information. =46rom name of =20= >>>>> this >>>>> new LSA, IMHO, it is limited to be used for Intra-Area TE only. =20= >>>>> So, >>>>> if there are some underlying extensions to ospfv3-traffic, e.g. >>>>> Inter-AS TE, it is a little bit strange to re-use the Intra-=20 >>>>> Area-TE >>>>> LSA, or it has to define a new LSA. So, can we change its name to >>>>> something like =93OSPFv3 TE LSA=94? >>>> It would be if we had intended it to carry AS wide information. >>>> However, it was not initially intended for this. The initial =20 >>>> thought >>>> was that we would do a better job for OSPFv3 and define separate =20= >>>> LSA >>>> types for intra-area, inter-area, and AS external TE LSAs. Thoughts >>>> on this (copied ccamp as well)? >>> >>> So, the conclusion is that a new LSA(may be called Inter-AS-TE LSA) >>> has to be defined for advertising inter-AS TE information in >>> support of OSPFv3 TE, am I right? >>> >>>> I guess, IMHO, this discrepancy >>>> exposes the choice of a new link type for inter-AS connectivity =20 >>>> as a >>>> bit of a hack. >>>> >>> >>> For OSPFv3 TE(separate LSAs are used) is YES. But as to OSPFv2 TE, >>> IMHO, there should be a new link type to identify an inter-AS link, >>> or we need another new LSA. >> >> >> It seems to me that if we do add the link in your draft, then it >> should be done the same in OSPFv2 and OSPFv3. Advertising it as a new >> link type is one way to advertise inter-AS connectivity. However, it >> isn't necessarily a link. This seems to me to be more of a semantical >> discrepancy than the name of the LSA. In section 4, I notice that at >> least for OSPFv2 the draft says the new link may be advertised in >> either a type 11 opaque LSA or type 10 opaque LSA. Given the maturity >> of RFC 3630, it almost seems to me that we should allocate a new LSA >> opaque type for this purpose. >> >> What is the status of draft-ietf-ccamp-ospf-interas-te- >> extension-01.txt? > > > The I-D has been updated recently according to the comments =20 > received from Chicago meeting. The main changes inlcude: > > 1. According to Kireeti's comments, make a clear statement "There =20 > is no OSPF adjacency running on the inter-AS link"; > > 2. Enhance the PCE-based scenario to explain that the AS number =20 > property of an inter-AS TE link is needed, and clearly state that =20 > the AS number sub-TLV is mandatory; > > 3. Add the missing part about that the local ASBR SHOULD do a =20 > "proxy" advertisement for the backward of an inter-AS TE link; > > 4. Enhance the Security section. > > Currently, IMHO, the I-D can support OSPFv2 properly, due to the =20 > diffence between OSPFv2 TE and OSPFv3 TE, some changes are needed =20 > in order to encompass OSPFv3, so the status of the I-D is "work in =20 > progress":) Ok - will review the next version. > >> I know at the OSPF meeting there were a number of people who >> questioned whether or not it was necessary. > > I am not sure the necessary you pointed is pointed to the new link =20 > type or the Inter-AS TE I-D. Because I did not hear any questions =20 > about the necessary of the I-D, so I assume that you poinited is =20 > the new link type. As I pointed before, if a new sepatate LSA is =20 > used, the new link type may not be needed. Sounds good, I haven't seen much dissension on the CCAMP list. Thanks, Acee > >> >> Thanks, >> Acee >> > > > > Best regards, =09 > Mach Chen > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 29 Sep 2007 12:34:28 +0000 Message-ID: <05be01c80294$b6a151a0$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Proposed new working group draft Date: Sat, 29 Sep 2007 13:31:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, Now that the MLN requirements and protocol evaluation have completed last call with just a couple of comments, and now that we have more or less reached stability with our liaisons to the ITU-T on this subject, we need to look for a solutions I-D. http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-mrn-extensions-04.txt has been running for some time and tracking both the requirements and the lacunae identified by the evaluation draft. It seems that this provides a good basis for the protocol work in CCAMP even if some elements might change. Please express your support or otherwise for this I-D to become a WG draft. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 29 Sep 2007 05:14:53 +0000 Date: Sat, 29 Sep 2007 13:12:08 +0800 From: Mach Chen Subject: Re: [OSPF] Fwd: Posting of draft-ietf-ospf-ospfv3-traffic-09.txt To: Acee Lindem Cc: OSPF List , Vishwas Manral , Alan Davey , CCAMP List Message-id: <0JP4003A46GNH7@szxga04-in.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGkgQWNlZSAsDQoNClNvcnJveSBmb3IgbGF0ZSByZXBseS4NCiAgICAgICANCk9uIDIwMDctMDkt MjYsIGF0IDIyOjE0OjM2IEFjZWUgTGluZGVtIHdyb3RlOg0KDQo+SGkgTWFjaCwNCj4NCj5PbiBT ZXAgMjYsIDIwMDcsIGF0IDY6MTAgQU0sIE1hY2ggQ2hlbiB3cm90ZToNCj4NCj4+IEhpIEFjZWUs DQo+Pg0KPj4gUGxzIHNlZSBpbmxpbmUNCj4+DQo+Pg0KPj4gT24gMjAwNy0wOS0yNSwgYXQgMjE6 MDU6NDkgQWNlZSBMaW5kZW0gd3JvdGU6DQo+Pg0KPj4+IEhpIE1hY2gsDQo+Pj4gVGhhbmtzIGZv ciByZXZpZXdpbmcuDQo+Pj4NCj4+PiBPbiBTZXAgMjUsIDIwMDcsIGF0IDQ6MjQgQU0sIE1hY2gg Q2hlbiB3cm90ZToNCj4+Pg0KPj4+PiBIaSBBY2VlIGFuZCBvdGhlciBhdXRob3JzLA0KPj4+Pg0K Pj4+Pg0KPj4+Pg0KPj4+PiBTb21lIHF1ZXN0aW9ucyB0byBvc3BmdjMtdHJhZmZpYw0KPj4+Pg0K Pj4+Pg0KPj4+Pg0KPj4+PiAxLiAgICAgICBJbiB0aGlzIG9zcGZ2My10cmFmZmljIGRvY3VtZW50 LCBhIG5ldyBMU0EsIEludHJhLUFyZWEtVEUNCj4+Pj4gTFNBLCBpcyBkZWZpbmVkIHRvIGFkdmVy dGlzZSBJUHY2IFRFIGluZm9ybWF0aW9uLiBGcm9tIG5hbWUgb2YgdGhpcw0KPj4+PiBuZXcgTFNB LCBJTUhPLCBpdCBpcyBsaW1pdGVkIHRvIGJlIHVzZWQgZm9yIEludHJhLUFyZWEgVEUgb25seS4g U28sDQo+Pj4+IGlmIHRoZXJlIGFyZSBzb21lIHVuZGVybHlpbmcgZXh0ZW5zaW9ucyB0byBvc3Bm djMtdHJhZmZpYywgZS5nLg0KPj4+PiBJbnRlci1BUyBURSwgaXQgaXMgYSBsaXR0bGUgYml0IHN0 cmFuZ2UgdG8gcmUtdXNlIHRoZSBJbnRyYS1BcmVhLVRFDQo+Pj4+IExTQSwgb3IgaXQgaGFzIHRv IGRlZmluZSBhIG5ldyBMU0EuIFNvLCBjYW4gd2UgY2hhbmdlIGl0cyBuYW1lIHRvDQo+Pj4+IHNv bWV0aGluZyBsaWtlIKGwT1NQRnYzIFRFIExTQaGxPw0KPj4+IEl0IHdvdWxkIGJlIGlmIHdlIGhh ZCBpbnRlbmRlZCBpdCB0byBjYXJyeSBBUyB3aWRlIGluZm9ybWF0aW9uLg0KPj4+IEhvd2V2ZXIs IGl0IHdhcyBub3QgaW5pdGlhbGx5IGludGVuZGVkIGZvciB0aGlzLiBUaGUgaW5pdGlhbCB0aG91 Z2h0DQo+Pj4gd2FzIHRoYXQgd2Ugd291bGQgZG8gYSBiZXR0ZXIgam9iIGZvciBPU1BGdjMgYW5k IGRlZmluZSBzZXBhcmF0ZSBMU0ENCj4+PiB0eXBlcyBmb3IgaW50cmEtYXJlYSwgaW50ZXItYXJl YSwgYW5kIEFTIGV4dGVybmFsIFRFIExTQXMuIFRob3VnaHRzDQo+Pj4gb24gdGhpcyAoY29waWVk IGNjYW1wIGFzIHdlbGwpPw0KPj4NCj4+IFNvLCB0aGUgY29uY2x1c2lvbiBpcyB0aGF0IGEgbmV3 IExTQShtYXkgYmUgY2FsbGVkIEludGVyLUFTLVRFIExTQSkgIA0KPj4gaGFzIHRvIGJlIGRlZmlu ZWQgZm9yIGFkdmVydGlzaW5nIGludGVyLUFTIFRFIGluZm9ybWF0aW9uIGluICANCj4+IHN1cHBv cnQgb2YgT1NQRnYzIFRFLCBhbSBJIHJpZ2h0Pw0KPj4NCj4+PiBJIGd1ZXNzLCBJTUhPLCB0aGlz IGRpc2NyZXBhbmN5DQo+Pj4gZXhwb3NlcyB0aGUgY2hvaWNlIG9mIGEgbmV3IGxpbmsgdHlwZSBm b3IgaW50ZXItQVMgY29ubmVjdGl2aXR5IGFzIGENCj4+PiBiaXQgb2YgYSBoYWNrLg0KPj4+DQo+ Pg0KPj4gRm9yIE9TUEZ2MyBURShzZXBhcmF0ZSBMU0FzIGFyZSB1c2VkKSBpcyBZRVMuIEJ1dCBh cyB0byBPU1BGdjIgVEUsICANCj4+IElNSE8sIHRoZXJlIHNob3VsZCBiZSBhIG5ldyBsaW5rIHR5 cGUgdG8gaWRlbnRpZnkgYW4gaW50ZXItQVMgbGluaywgIA0KPj4gb3Igd2UgbmVlZCBhbm90aGVy IG5ldyBMU0EuDQo+DQo+DQo+SXQgc2VlbXMgdG8gbWUgdGhhdCBpZiB3ZSBkbyBhZGQgdGhlIGxp bmsgaW4geW91ciBkcmFmdCwgdGhlbiBpdCAgDQo+c2hvdWxkIGJlIGRvbmUgdGhlIHNhbWUgaW4g T1NQRnYyIGFuZCBPU1BGdjMuIEFkdmVydGlzaW5nIGl0IGFzIGEgbmV3ICANCj5saW5rIHR5cGUg aXMgb25lIHdheSB0byBhZHZlcnRpc2UgaW50ZXItQVMgY29ubmVjdGl2aXR5LiBIb3dldmVyLCBp dCAgDQo+aXNuJ3QgbmVjZXNzYXJpbHkgYSBsaW5rLiBUaGlzIHNlZW1zIHRvIG1lIHRvIGJlIG1v cmUgb2YgYSBzZW1hbnRpY2FsICANCj5kaXNjcmVwYW5jeSB0aGFuIHRoZSBuYW1lIG9mIHRoZSBM U0EuIEluIHNlY3Rpb24gNCwgSSBub3RpY2UgdGhhdCBhdCAgDQo+bGVhc3QgZm9yIE9TUEZ2MiB0 aGUgZHJhZnQgc2F5cyB0aGUgbmV3IGxpbmsgbWF5IGJlIGFkdmVydGlzZWQgaW4gIA0KPmVpdGhl ciBhIHR5cGUgMTEgb3BhcXVlIExTQSBvciB0eXBlIDEwIG9wYXF1ZSBMU0EuIEdpdmVuIHRoZSBt YXR1cml0eSAgDQo+b2YgUkZDIDM2MzAsIGl0IGFsbW9zdCBzZWVtcyB0byBtZSB0aGF0IHdlIHNo b3VsZCBhbGxvY2F0ZSBhIG5ldyBMU0EgIA0KPm9wYXF1ZSB0eXBlIGZvciB0aGlzIHB1cnBvc2Uu DQo+DQo+V2hhdCBpcyB0aGUgc3RhdHVzIG9mIGRyYWZ0LWlldGYtY2NhbXAtb3NwZi1pbnRlcmFz LXRlLSANCj5leHRlbnNpb24tMDEudHh0PyANCg0KDQpUaGUgSS1EIGhhcyBiZWVuIHVwZGF0ZWQg cmVjZW50bHkgYWNjb3JkaW5nIHRvIHRoZSBjb21tZW50cyByZWNlaXZlZCBmcm9tIENoaWNhZ28g bWVldGluZy4gVGhlIG1haW4gY2hhbmdlcyBpbmxjdWRlOg0KDQoxLiBBY2NvcmRpbmcgdG8gS2ly ZWV0aSdzIGNvbW1lbnRzLCBtYWtlIGEgY2xlYXIgc3RhdGVtZW50ICJUaGVyZSBpcyBubyBPU1BG IGFkamFjZW5jeSBydW5uaW5nIG9uIHRoZSBpbnRlci1BUyBsaW5rIjsgDQoNCjIuIEVuaGFuY2Ug dGhlIFBDRS1iYXNlZCBzY2VuYXJpbyB0byBleHBsYWluIHRoYXQgdGhlIEFTIG51bWJlciBwcm9w ZXJ0eSBvZiBhbiBpbnRlci1BUyBURSBsaW5rIGlzIG5lZWRlZCwgYW5kIGNsZWFybHkgc3RhdGUg dGhhdCB0aGUgQVMgbnVtYmVyIHN1Yi1UTFYgaXMgbWFuZGF0b3J5OyANCg0KMy4gQWRkIHRoZSBt aXNzaW5nIHBhcnQgYWJvdXQgdGhhdCB0aGUgbG9jYWwgQVNCUiBTSE9VTEQgZG8gYSAicHJveHki IGFkdmVydGlzZW1lbnQgZm9yIHRoZSBiYWNrd2FyZCBvZiBhbiBpbnRlci1BUyBURSBsaW5rOyAN Cg0KNC4gRW5oYW5jZSB0aGUgU2VjdXJpdHkgc2VjdGlvbi4NCg0KQ3VycmVudGx5LCBJTUhPLCB0 aGUgSS1EIGNhbiBzdXBwb3J0IE9TUEZ2MiBwcm9wZXJseSwgZHVlIHRvIHRoZSBkaWZmZW5jZSBi ZXR3ZWVuIE9TUEZ2MiBURSBhbmQgT1NQRnYzIFRFLCBzb21lIGNoYW5nZXMgYXJlIG5lZWRlZCBp biBvcmRlciB0byBlbmNvbXBhc3MgT1NQRnYzLCBzbyB0aGUgc3RhdHVzIG9mIHRoZSBJLUQgaXMg IndvcmsgaW4gcHJvZ3Jlc3MiOikNCg0KPkkga25vdyBhdCB0aGUgT1NQRiBtZWV0aW5nIHRoZXJl IHdlcmUgYSBudW1iZXIgb2YgcGVvcGxlIHdobyANCj5xdWVzdGlvbmVkIHdoZXRoZXIgb3Igbm90 IGl0IHdhcyBuZWNlc3NhcnkuDQoNCkkgYW0gbm90IHN1cmUgdGhlIG5lY2Vzc2FyeSB5b3UgcG9p bnRlZCBpcyBwb2ludGVkIHRvIHRoZSBuZXcgbGluayB0eXBlIG9yIHRoZSBJbnRlci1BUyBURSBJ LUQuIEJlY2F1c2UgSSBkaWQgbm90IGhlYXIgYW55IHF1ZXN0aW9ucyBhYm91dCB0aGUgbmVjZXNz YXJ5IG9mIHRoZSBJLUQsIHNvIEkgYXNzdW1lIHRoYXQgeW91IHBvaW5pdGVkIGlzIHRoZSBuZXcg bGluayB0eXBlLiBBcyBJIHBvaW50ZWQgYmVmb3JlLCBpZiBhIG5ldyBzZXBhdGF0ZSBMU0EgaXMg dXNlZCwgdGhlIG5ldyBsaW5rIHR5cGUgbWF5IG5vdCBiZSBuZWVkZWQuIA0KDQo+DQo+VGhhbmtz LA0KPkFjZWUNCj4NCg0KDQoNCkJlc3QgcmVnYXJkcywJCQkNCk1hY2ggQ2hlbg0KDQo= Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Sep 2007 22:34:06 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8021F.8D653E47" Subject: RE: [Pce] Some key issues with Wavelength Switched Optical Networks... Date: Fri, 28 Sep 2007 17:33:11 -0500 Message-ID: Thread-Topic: [Pce] Some key issues with Wavelength Switched Optical Networks... Thread-Index: AcgCGayoFx0FLU33S4uAa4y5kFZHtwAA8mjA From: "Bardalai, Snigdho" To: "Greg Bernstein" , "Igor Bryskin" Cc: "ccamp" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C8021F.8D653E47 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, this is an interesting problem within the WSON domain and one way = to solve the RSVP-TE problem is by modeling the node with the loop-back = as a pass-thru node with some sort of indication within the signaling = message identifying which pieces of hardware to use as part of the = loop-back. =20 Snigdho -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On = Behalf Of Greg Bernstein Sent: Friday, September 28, 2007 4:44 PM To: Igor Bryskin Cc: ccamp; pce@ietf.org Subject: Re: [Pce] Some key issues with Wavelength Switched Optical = Networks... Very good catch Igor. See in line. Igor Bryskin wrote:=20 --snip--=20 2. Considering wavelength conversion inevitably brings to the problem of = looped paths, which is a completely new ball game in path computation, = and I am surprised that the issue was never mentioned in the draft. --> How is this different from the "looping" that can occur with a TDM = multiplexer in a drop and continue mode? Also in these two circuit = cases (TDM, and optical) do we have the same danger as in the packet = case where looping traffic can greatly degrade other flows. Was there = some general looping concerns already published for GMPLS with respect = to circuits? =20 IB>> There is a profound difference. I am not talking here about = accidental looping, rather about deliberate looping: if some nodes can = perform wavelength conversion while others can not, then you will want = to route the connection to one or several conversion points and after = that get it back on the main path. In other words you will deliberately = request, say, a PCE to produce looped path, and then GMPLS RSVP-TE to = signal looped path, which is completely out of normal paradigm of work = for both PCE and RSVP. --> I thought you were worried about accidental loops. I didn't even = consider what you are talking about "looping", but would RSVP processing = get fouled up? It sure looks like a loop at the "node" level.=20 In the ERO the "node" subobject (IP4, IP6, AS) could definitely be = repeated, but with a different "Label ERO" subobject appended. This is = definitely something somebody would not to in the MPLS or TDM case. = I'll be sure to add it as an important difference in the next revision. = Thanks! Cheers,=20 Igor _____ =20 --snip-- --=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 ------_=_NextPart_001_01C8021F.8D653E47 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Yes,=20 this is an interesting problem within the WSON domain and one way = to solve=20 the RSVP-TE problem is by modeling the node with the loop-back = as a=20 pass-thru node with some sort of indication within the signaling message = identifying which pieces of hardware to use as part of the=20 loop-back.
     
    Snigdho
    -----Original Message-----
    From: = owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Greg=20 Bernstein
    Sent: Friday, September 28, 2007 4:44 = PM
    To:=20 Igor Bryskin
    Cc: ccamp; pce@ietf.org
    Subject: Re: = [Pce]=20 Some key issues with Wavelength Switched Optical=20 Networks...

    Very good catch Igor. See in = line.

    Igor=20 Bryskin wrote:=20
    --snip--=20



    2. = Considering=20 wavelength conversion inevitably brings to the problem of looped = paths,=20 which is a completely new ball game in path computation, and I am = surprised=20 that the issue was never mentioned in the=20 draft.

    --> How is this different from the = "looping" that=20 can occur with a TDM multiplexer in a drop and continue mode?  = Also in=20 these two circuit cases (TDM, and optical) do we have the same = danger as in=20 the packet case where looping traffic can greatly degrade other = flows. =20 Was there some general looping concerns already published for GMPLS = with=20 respect to circuits? 

    IB>> There is=20 a profound difference. I am not talking here about accidental = looping,=20 rather about deliberate looping: if some nodes can perform = wavelength=20 conversion while others can not, then you will want to route the = connection=20 to one or several conversion points and after that get it back on = the main=20 path. In other words you will deliberately request, say, a PCE to = produce=20 looped path, and then GMPLS RSVP-TE to signal looped path, which is=20 completely out of normal paradigm of work for both PCE and=20 RSVP.

    --> I thought you were = worried=20 about accidental loops.  I didn't even consider what you are = talking=20 about "looping", but would RSVP processing get fouled up? It sure = looks like a=20 loop at the "node" level.
    In the ERO the "node" subobject (IP4, = IP6, AS)=20 could definitely be repeated, but with a different "Label ERO" = subobject=20 appended. This is definitely something somebody would not to in the = MPLS or=20 TDM case.  I'll be sure to add it as an important difference in = the next=20 revision. Thanks!

    Cheers,=20

    Igor


    --snip--
    --=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
    
    
    ------_=_NextPart_001_01C8021F.8D653E47-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Sep 2007 21:45:26 +0000 Message-ID: <46FD7589.10505@grotto-networking.com> Date: Fri, 28 Sep 2007 14:43:37 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Igor Bryskin CC: ccamp , pce@ietf.org Subject: Re: [Pce] Some key issues with Wavelength Switched Optical Networks... Content-Type: multipart/alternative; boundary="------------060109060902070806000707" This is a multi-part message in MIME format. --------------060109060902070806000707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Very good catch Igor. See in line. Igor Bryskin wrote: > --snip-- > > > > > > 2. Considering wavelength conversion inevitably brings to the problem > of looped paths, which is a completely new ball game in path > computation, and I am surprised that the issue was never mentioned in > the draft. > > --> How is this different from the "looping" that can occur with a TDM > multiplexer in a drop and continue mode? Also in these two circuit > cases (TDM, and optical) do we have the same danger as in the packet > case where looping traffic can greatly degrade other flows. Was there > some general looping concerns already published for GMPLS with respect > to circuits? > > > > IB>> There is a profound difference. I am not talking here about > accidental looping, rather about deliberate looping: if some nodes can > perform wavelength conversion while others can not, then you will want > to route the connection to one or several conversion points and after > that get it back on the main path. In other words you will > deliberately request, say, a PCE to produce looped path, and then > GMPLS RSVP-TE to signal looped path, which is completely out of normal > paradigm of work for both PCE and RSVP. > --> I thought you were worried about accidental loops. I didn't even consider what you are talking about "looping", but would RSVP processing get fouled up? It sure looks like a loop at the "node" level. In the ERO the "node" subobject (IP4, IP6, AS) could definitely be repeated, but with a different "Label ERO" subobject appended. This is definitely something somebody would not to in the MPLS or TDM case. I'll be sure to add it as an important difference in the next revision. Thanks! > > > > Cheers, > > Igor > > > > ------------------------------------------------------------------------ --snip-- -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------060109060902070806000707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Very good catch Igor. See in line.

    Igor Bryskin wrote:
    --snip--



     

    2. Considering wavelength conversion inevitably brings to the problem of looped paths, which is a completely new ball game in path computation, and I am surprised that the issue was never mentioned in the draft.

    --> How is this different from the "looping" that can occur with a TDM multiplexer in a drop and continue mode?  Also in these two circuit cases (TDM, and optical) do we have the same danger as in the packet case where looping traffic can greatly degrade other flows.  Was there some general looping concerns already published for GMPLS with respect to circuits? 

     

    IB>> There is a profound difference. I am not talking here about accidental looping, rather about deliberate looping: if some nodes can perform wavelength conversion while others can not, then you will want to route the connection to one or several conversion points and after that get it back on the main path. In other words you will deliberately request, say, a PCE to produce looped path, and then GMPLS RSVP-TE to signal looped path, which is completely out of normal paradigm of work for both PCE and RSVP.

    --> I thought you were worried about accidental loops.  I didn't even consider what you are talking about "looping", but would RSVP processing get fouled up? It sure looks like a loop at the "node" level.
    In the ERO the "node" subobject (IP4, IP6, AS) could definitely be repeated, but with a different "Label ERO" subobject appended. This is definitely something somebody would not to in the MPLS or TDM case.  I'll be sure to add it as an important difference in the next revision. Thanks!

     

    Cheers,

    Igor

     


    --snip--
    -- 
    ===================================================
    Dr Greg Bernstein, Grotto Networking (510) 573-2237
    
    
    --------------060109060902070806000707-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Sep 2007 19:48:07 +0000 Message-ID: <46FD5A18.2080505@grotto-networking.com> Date: Fri, 28 Sep 2007 12:46:32 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Giovanni Martinelli (giomarti)" CC: ccamp , pce@ietf.org Subject: Re: [Pce] Some key issues with Wavelength Switched Optical Networks... Content-Type: multipart/alternative; boundary="------------030001070104060803010707" This is a multi-part message in MIME format. --------------030001070104060803010707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Giovanni, thanks for the close read. Looks like you caught some problems with the text. See below for comments. Giovanni Martinelli (giomarti) wrote: > Hi Greg, > > Sorry for the delay in replying. I'm working on this topic since a > while so yes, it's interesting. Before going on specific issue I would > have some question/clarification regarding the draft itself. > > > * Within Abstract and the following. > You don't talk about Optical Cross Connects (OXC) is something missing > or understated somewhere? -->Whoops. We were trying to find a more general term to include both ROADM (usually a highly asymmetric fabric) and an OXC (a completely symmetric fabric, e.g., any ingress to any egress), but we seemed to have gone with using the ROADM terminology to include both cases. Talked with some equipment makers that planned/make "switches" that seemed to incorporate both so we made sure the model could deal with both sparse and dense potential connectivity. Diego had some terminology ideas but lately his e-mails have been bouncing back to me. Any suggestions are appreciated, but we are including both ROADM and OXCs. > > > * Section 3.1 where you state: > "A fixed mapping between the > GMPLS label space and these ITU-T WDM grids as proposed in [Otani] " > Does it implies a sort of network level label space? How relate with > usual local label significance? --> This mapping gives a mapping between labels and wavelengths/lambda, just like in the SONET/SDH case we mapped the ITU-T G.707 "S, U, K, L, M " identification of SDH time slots to a label format in RFC4606 and again this was done in RFC4328 to map G.709 digital wrapper time slot identification into a technology specific label format. In RFC3471 for lambda switching we just get a 32 bit integer with no meaning attached. Every network and every node could potentially map labels to lambdas in a different way. In [Otani] they are following the RFC4606 and RFC4328 lead and using the ITU-T DWDM and CWDM lambda grid standards to give a fixed association between labels and lambdas just like between labels and TDM time slots in the SDH/ODU case. This doesn't change the local significance of labels. In the wavelength switched optical case that is influenced by the presence or absence of wavelength converters. > > > * Section 3.4 Wavelength Converters > "Current or envisioned contexts for wavelength converters are : ..." > Could we think to a description/model for wavelength converter that is > technology agnostic? Simply something like: full conversion > capability, partial conversion capability with some constrains, and > may be others. --> The difference, between the all optical techniques and the OEO based techniques makes that difficult. > > > * Section 3.4. the following: > "4. Wavelength converters that are O-E-O based will have a restriction > based on the modulation format and transmission speed" > Not clear to me the type of restriction here when OEO happens... > probably I'm missing what you mean here. --> For example a typical O-E-O based wavelength converter would be build around a 3R regenerator with a tunable laser. A 3R regenerator cares about the modulation type say NRZ or RZ (and which flavor), and the symbol rate since its also doing retiming. An all optical wavelength converter will be fairly independent of these issues (except when we look at impairment factors). Hence the OEO wavelength is going to be more signal specific than the all optical. > > > * Section 4.1 when you talk about Lightpath temporal characteristics: > "Lightpath connection duration has typically been thought of as > approximately three time frames: " > and the following you define: dynamics, pseudo-static, static. > Why there's a need of this classification? When you us Short/long is > compared to what? --> In most of the research literature and in optimization practice different techniques are typically used in the dynamic versus static (or psuedo static cases). In MPLS there is minimum interference routing optimization techniques for the dynamic case. For the static case I could apply multi-commodity flow optimization techniques to a batch of connections. In the RWA literature there is a similar differentiation. Exactly what information could be sent to help PCE differentiate I'm not sure. In the case of static, batch optimization we can just use the existing concurrent optimization hooks in PCE. For an individual lightpath request it seemed that it would be helpful to know how long the connection would last so we'd know how much computational effort we might want to put into optimize it. > > > minor typo on your mail below: point (c) rfc4328 (not 4238) right? --> Yes. The G.709 signaling extensions RFC. > > Thanks, > Giovanni > > > > > ------------------------------------------------------------------------ > *From:* Greg Bernstein [mailto:gregb@grotto-networking.com] > *Sent:* giovedì 27 settembre 2007 1.42 > *To:* ccamp; pce@ietf.org > *Subject:* [Pce] Some key issues with Wavelength Switched Optical > Networks... > > Hi folks, I haven't seen too many comments on our draft "Framework > for GMPLS and PCE Control of Wavelength Switched Optical Networks" > ( > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-01.txt). > So I figured I'd point out some potentially controversial issues > that the draft brings up. > > (a) The draft brings up models for the following WDM network elements: > > 1. WDM links > 2. Optical transmitters > 3. Wavelength Converters and OEO regenerators > 4. ROADMs, FOADMs, optical splitters and combiners. > > For items (3) and (4) we are taking the modeling lead rather > than some other SDO. And for ROADMs, in particular, we going > beyond the classic ITU-T "fabric" model (M.3100) which has been > the mainstay of any connection oriented switch (TDM, ATM, MPLS). > > (b) The draft brings up three (not one, not two, but three) > different computational models for RWA which can impact GMPLS and > PCE protocols: > > 1. A single PCE computing both the path and wavelength > 2. Two distinct PCEs, where one computes the path, and a > different PCE computes the wavelength assignment > 3. A PCE computes the path and wavelength assignment is > accomplished in a distributed fashion via signaling (e.g., > using label set objects) > > Do we really need all three models? > > (c) G.709 includes the Optical Multiplex Section and Optical > Channels. RFC4238 was aimed at GMPLS extensions for G.709 > (Optical Transport Network) control. Weren't we finished with all > this optical stuff years ago? > > I'd like to think the draft answers some of these questions. I > also think that network element models and the process models are > important enough to warrant this separate framework document. > Your opinions are solicited. > > Regards > > Greg B. > > -- > =================================================== > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------030001070104060803010707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Giovanni, thanks for the close read.  Looks like you caught some problems with the text.  See below for comments.

    Giovanni Martinelli (giomarti) wrote:
    Hi Greg,
     
    Sorry for the delay in replying. I'm working on this topic since a while so yes, it's interesting. Before going on specific issue I would have some question/clarification regarding the draft itself.
     
     
    * Within Abstract and the following.
    You don't talk about Optical Cross Connects (OXC) is something missing or understated somewhere?
    -->Whoops.  We were trying to find a more general term to include both ROADM (usually a highly asymmetric fabric) and an OXC (a completely symmetric fabric, e.g., any ingress to any egress), but we seemed to have gone with using the ROADM terminology to include both cases.  Talked with some equipment makers that planned/make "switches" that seemed to incorporate both so we made sure the model could deal with both sparse and dense potential connectivity. Diego had some terminology ideas but lately his e-mails have been bouncing back to me.  Any suggestions are appreciated, but we are including both ROADM and OXCs.
     
     
    * Section 3.1 where you state:
    "A fixed mapping between the
    GMPLS label space and these ITU-T WDM grids as proposed in [Otani] "
    Does it implies a sort of network level label space? How relate with usual local label significance?
    --> This mapping gives a mapping between labels and wavelengths/lambda, just like in the SONET/SDH case we mapped the ITU-T G.707 "S, U, K, L, M " identification of SDH time slots to a label format in RFC4606 and again this was done in RFC4328 to map G.709 digital wrapper time slot identification into a technology specific label format.  In RFC3471 for lambda switching we just get a 32 bit integer with no meaning attached. Every network and every node could potentially map labels to lambdas in a different way. In [Otani] they are following the RFC4606 and RFC4328 lead and using the ITU-T DWDM and CWDM lambda grid standards to give a fixed association between labels and lambdas just like between labels and TDM time slots in the SDH/ODU case.

    This doesn't change the local significance of labels. In the wavelength switched optical case that is influenced by the presence or absence of wavelength converters.
     
     
    * Section 3.4 Wavelength Converters
    "Current or envisioned contexts for wavelength converters are : ..."
    Could we think to a description/model for wavelength converter that is technology agnostic? Simply something like: full conversion capability, partial conversion capability with some constrains, and may be others.
    --> The difference, between the all optical techniques and the OEO based techniques makes that difficult.
     
     
    * Section 3.4. the following:
    "4. Wavelength converters that are O-E-O based will have a restriction
    based on the modulation format and transmission speed"
    Not clear to me the type of restriction here when OEO happens... probably I'm missing what you mean here.
    --> For example a typical O-E-O based wavelength converter would be build around a 3R regenerator with a tunable laser. A 3R regenerator cares about the modulation type say NRZ or RZ (and which flavor), and the symbol rate since its also doing retiming. An all optical wavelength converter will be fairly independent of these issues (except when we look at impairment factors). Hence the OEO wavelength is going to be more signal specific than the all optical.
     
     
    * Section 4.1 when you talk about Lightpath temporal characteristics:
    "Lightpath connection duration has typically been thought of as
    approximately three time frames: "
    and the following you define: dynamics, pseudo-static, static.
    Why there’s a need of this classification? When you us Short/long is compared to what?
    --> In most of the research literature and in optimization practice different techniques are typically used in the dynamic versus static (or psuedo static cases).  In MPLS there is minimum interference routing optimization techniques for the dynamic case. For the static case I could apply multi-commodity flow optimization techniques to a batch of connections.  In the RWA literature there is a similar differentiation.  Exactly what information could be sent to help PCE differentiate I'm not sure. In the case of static, batch optimization we can just use the existing concurrent optimization hooks in PCE. For an individual lightpath request it seemed that it would be helpful to know how long the connection would last so we'd know how much computational effort we might want to put into optimize it.
     
     
    minor typo on your mail below: point (c) rfc4328 (not 4238) right?
    --> Yes.  The G.709 signaling extensions RFC.
     
    Thanks,
    Giovanni


     


    From: Greg Bernstein [mailto:gregb@grotto-networking.com]
    Sent: giovedì 27 settembre 2007 1.42
    To: ccamp; pce@ietf.org
    Subject: [Pce] Some key issues with Wavelength Switched Optical Networks...

    Hi folks, I haven't seen too many comments on our draft "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks" ( http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-01.txt). So I figured I'd point out some potentially controversial issues that the draft brings up.

    (a) The draft brings up models for the following WDM network elements:
    1. WDM links
    2. Optical transmitters
    3. Wavelength Converters and OEO regenerators
    4. ROADMs, FOADMs, optical splitters and combiners.
        For items (3) and (4) we are taking the modeling lead rather than some other SDO.  And for ROADMs, in particular, we going beyond the classic ITU-T "fabric" model (M.3100) which has been the mainstay of any connection oriented switch (TDM, ATM, MPLS).

    (b) The draft brings up three (not one, not two, but three) different computational models for RWA which can impact GMPLS and PCE protocols:
    1. A single PCE computing both the path and wavelength
    2. Two distinct PCEs, where one computes the path, and a different PCE computes the wavelength assignment
    3. A PCE computes the path and wavelength assignment is accomplished in a distributed fashion via signaling (e.g., using label set objects)
        Do we really need all three models?

    (c) G.709 includes the Optical Multiplex Section and Optical Channels.  RFC4238 was aimed at GMPLS extensions for G.709  (Optical Transport Network) control.  Weren't we finished with all this optical stuff years ago?

    I'd like to think the draft answers some of these questions.  I also think that network element models and the process models are important enough to warrant this separate framework document.  Your opinions are solicited.

    Regards

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

    -- 
    ===================================================
    Dr Greg Bernstein, Grotto Networking (510) 573-2237
    
    
    --------------030001070104060803010707-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Sep 2007 19:13:15 +0000 Message-ID: <46FD51B9.9060909@grotto-networking.com> Date: Fri, 28 Sep 2007 12:10:49 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Igor Bryskin CC: ccamp , pce@ietf.org Subject: Re: [Pce] Some key issues with Wavelength Switched Optical Networks... Content-Type: multipart/alternative; boundary="------------090301070903080006080809" This is a multi-part message in MIME format. --------------090301070903080006080809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Igor, see comments below. Igor Bryskin wrote: > > Greg, > > > > I believe the draft is very useful. > --> Thanks! > > > > I have a couple of questions comments: > > > > 1. Section : 4.4. Traffic Grooming: Combining WSON and Higher Layer Network > > Optimization > > > > How the problem of grooming of higher layer network traffic over > optical trails is any different from the problem of traffic grooming > in TDM (e.g. VC12 over VC4)? I mean this is a general problem of > inter-layer relationship. I suggest moving all higher layer network > considerations out of scope of the draft and focusing on specifics of > the OCh layer. > --> Some of my co-authors agree with you on moving this section out. The reason that I put it in was that the optical "Traffic Grooming" problem has received a fair amount of attention in the research and general technical literature and is also a driver for the use of ROADMs (optical bypass). I guess in general we've got the following inter-related problems: (a) virtual network topology design, (b) lower layer connection routing, (c) higher layer flow routing. In our case (b) is the RWA problem, which is fairly difficult in its own right. I guess I should look closely at the MLN/MRN work and see if a specific example that includes RWA is mentioned. If so then I'd feel fine removing this section from the document. > > > > 2. Considering wavelength conversion inevitably brings to the problem > of looped paths, which is a completely new ball game in path > computation, and I am surprised that the issue was never mentioned in > the draft. > --> How is this different from the "looping" that can occur with a TDM multiplexer in a drop and continue mode? Also in these two circuit cases (TDM, and optical) do we have the same danger as in the packet case where looping traffic can greatly degrade other flows. Was there some general looping concerns already published for GMPLS with respect to circuits? > > > > Cheers, > > Igor > > > > ------------------------------------------------------------------------ > > *From:* Greg Bernstein [mailto:gregb@grotto-networking.com] > *Sent:* Wednesday, September 26, 2007 7:42 PM > *To:* ccamp; pce@ietf.org > *Subject:* [Pce] Some key issues with Wavelength Switched Optical > Networks... > > > > Hi folks, I haven't seen too many comments on our draft "Framework for > GMPLS and PCE Control of Wavelength Switched Optical Networks" ( > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-01.txt). > So I figured I'd point out some potentially controversial issues that > the draft brings up. > > (a) The draft brings up models for the following WDM network elements: > > 1. WDM links > 2. Optical transmitters > 3. Wavelength Converters and OEO regenerators > 4. ROADMs, FOADMs, optical splitters and combiners. > > For items (3) and (4) we are taking the modeling lead rather than > some other SDO. And for ROADMs, in particular, we going beyond the > classic ITU-T "fabric" model (M.3100) which has been the mainstay of > any connection oriented switch (TDM, ATM, MPLS). > > (b) The draft brings up three (not one, not two, but three) different > computational models for RWA which can impact GMPLS and PCE protocols: > > 1. A single PCE computing both the path and wavelength > 2. Two distinct PCEs, where one computes the path, and a different > PCE computes the wavelength assignment > 3. A PCE computes the path and wavelength assignment is > accomplished in a distributed fashion via signaling (e.g., using > label set objects) > > Do we really need all three models? > > (c) G.709 includes the Optical Multiplex Section and Optical > Channels. RFC4238 was aimed at GMPLS extensions for G.709 (Optical > Transport Network) control. Weren't we finished with all this optical > stuff years ago? > > I'd like to think the draft answers some of these questions. I also > think that network element models and the process models are important > enough to warrant this separate framework document. Your opinions are > solicited. > > Regards > > Greg B. > > -- > =================================================== > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------090301070903080006080809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Igor, see comments below.

    Igor Bryskin wrote:

    Greg,

     

    I believe the draft is very useful.

    --> Thanks!

     

    I have a couple of questions comments:

     

    1. Section : 4.4. Traffic Grooming: Combining WSON and Higher Layer Network 

       Optimization

     

    How the problem of grooming of higher layer network traffic over optical trails is any different from the problem of traffic grooming in TDM (e.g. VC12 over VC4)? I mean this is a general problem of inter-layer relationship. I suggest moving all higher layer network considerations out of scope of the draft and focusing on specifics of the OCh layer.

    --> Some of my co-authors agree with you on moving this section out.  The reason that I put it in was that the optical "Traffic Grooming" problem has received a fair amount of attention in the research and general technical literature and is also a driver for the use of ROADMs (optical bypass).  I guess in general we've got the following inter-related problems: (a) virtual network topology design, (b) lower layer connection routing, (c) higher layer flow routing. In our case (b) is the RWA problem, which is fairly difficult in its own right. I guess I should look closely at the MLN/MRN work and see if a specific example that includes RWA is mentioned.  If so then I'd feel fine removing this section from the document.

     

    2. Considering wavelength conversion inevitably brings to the problem of looped paths, which is a completely new ball game in path computation, and I am surprised that the issue was never mentioned in the draft.

    --> How is this different from the "looping" that can occur with a TDM multiplexer in a drop and continue mode?  Also in these two circuit cases (TDM, and optical) do we have the same danger as in the packet case where looping traffic can greatly degrade other flows.  Was there some general looping concerns already published for GMPLS with respect to circuits? 

     

    Cheers,

    Igor

     


    From: Greg Bernstein [mailto:gregb@grotto-networking.com]
    Sent: Wednesday, September 26, 2007 7:42 PM
    To: ccamp; pce@ietf.org
    Subject: [Pce] Some key issues with Wavelength Switched Optical Networks...

     

    Hi folks, I haven't seen too many comments on our draft "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks" ( http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-01.txt). So I figured I'd point out some potentially controversial issues that the draft brings up.

    (a) The draft brings up models for the following WDM network elements:

    1. WDM links
    2. Optical transmitters
    3. Wavelength Converters and OEO regenerators
    4. ROADMs, FOADMs, optical splitters and combiners.

        For items (3) and (4) we are taking the modeling lead rather than some other SDO.  And for ROADMs, in particular, we going beyond the classic ITU-T "fabric" model (M.3100) which has been the mainstay of any connection oriented switch (TDM, ATM, MPLS).

    (b) The draft brings up three (not one, not two, but three) different computational models for RWA which can impact GMPLS and PCE protocols:

    1. A single PCE computing both the path and wavelength
    2. Two distinct PCEs, where one computes the path, and a different PCE computes the wavelength assignment
    3. A PCE computes the path and wavelength assignment is accomplished in a distributed fashion via signaling (e.g., using label set objects)

        Do we really need all three models?

    (c) G.709 includes the Optical Multiplex Section and Optical Channels.  RFC4238 was aimed at GMPLS extensions for G.709  (Optical Transport Network) control.  Weren't we finished with all this optical stuff years ago?

    I'd like to think the draft answers some of these questions.  I also think that network element models and the process models are important enough to warrant this separate framework document.  Your opinions are solicited.

    Regards

    Greg B.

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

    -- 
    ===================================================
    Dr Greg Bernstein, Grotto Networking (510) 573-2237
    
    
    --------------090301070903080006080809-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Sep 2007 22:37:22 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80156.B32B3353" Subject: RE: [Pce] Some key issues with Wavelength Switched Optical Networks... Date: Fri, 28 Sep 2007 00:36:52 +0200 Message-ID: <1F2FBF50FB955441A11316BAE835CED4042D142B@xmb-ams-338.emea.cisco.com> Thread-Topic: [Pce] Some key issues with Wavelength Switched Optical Networks... Thread-Index: AcgAl5KnD0dbOEQxQX+EILfgiGPP2AAvoJ3A From: "Giovanni Martinelli (giomarti)" To: "Greg Bernstein" , "ccamp" , DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12905; t=1190932527; x=1191796527; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=giomarti@cisco.com; z=From:=20=22Giovanni=20Martinelli=20(giomarti)=22=20 |Subject:=20RE=3A=20[Pce]=20Some=20key=20issues=20with=20Wavelength=20Swi tched=20Optical=20Networks... |Sender:=20; bh=DVSVM/lyQYCVwvpXDNQvzMD7PDXvhPJ3F+kbzoEhFv8=; b=RiTZRfNKJeM8Wya4YGaAZCDzSqMsjswHoSEQlpz1f8IuKENELSo5qMGQKS00VwQaWic6Nwzu wevg9lvRVaR1WCJJcnIMVz4I2GzPNQmCmztuSrhvJHlbl4IxH1A4WfK7; Authentication-Results: ams-dkim-1; header.From=giomarti@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); This is a multi-part message in MIME format. ------_=_NextPart_001_01C80156.B32B3353 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Greg, =20 Sorry for the delay in replying. I'm working on this topic since a while = so yes, it's interesting. Before going on specific issue I would have = some question/clarification regarding the draft itself.=20 =20 =20 * Within Abstract and the following. You don't talk about Optical Cross Connects (OXC) is something missing = or understated somewhere? =20 =20 * Section 3.1 where you state:=20 "A fixed mapping between the=20 GMPLS label space and these ITU-T WDM grids as proposed in [Otani] " Does it implies a sort of network level label space? How relate with = usual local label significance? =20 =20 * Section 3.4 Wavelength Converters=20 "Current or envisioned contexts for wavelength converters are : ..." Could we think to a description/model for wavelength converter that is = technology agnostic? Simply something like: full conversion capability, = partial conversion capability with some constrains, and may be others. =20 =20 * Section 3.4. the following:=20 "4. Wavelength converters that are O-E-O based will have a restriction=20 based on the modulation format and transmission speed"=20 Not clear to me the type of restriction here when OEO happens... = probably I'm missing what you mean here. =20 =20 * Section 4.1 when you talk about Lightpath temporal characteristics: "Lightpath connection duration has typically been thought of as=20 approximately three time frames: "=20 and the following you define: dynamics, pseudo-static, static. Why there's a need of this classification? When you us Short/long is = compared to what? =20 =20 minor typo on your mail below: point (c) rfc4328 (not 4238) right? =20 Thanks, Giovanni =20 ________________________________ From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: gioved=EC 27 settembre 2007 1.42 To: ccamp; pce@ietf.org Subject: [Pce] Some key issues with Wavelength Switched Optical = Networks... =09 =09 Hi folks, I haven't seen too many comments on our draft "Framework for = GMPLS and PCE Control of Wavelength Switched Optical Networks" ( = http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swit= ched-01.txt). So I figured I'd point out some potentially controversial = issues that the draft brings up.=20 =09 (a) The draft brings up models for the following WDM network elements: =09 1. WDM links=20 2. Optical transmitters =09 3. Wavelength Converters and OEO regenerators=20 4. ROADMs, FOADMs, optical splitters and combiners.=20 For items (3) and (4) we are taking the modeling lead rather than = some other SDO. And for ROADMs, in particular, we going beyond the = classic ITU-T "fabric" model (M.3100) which has been the mainstay of any = connection oriented switch (TDM, ATM, MPLS). =09 (b) The draft brings up three (not one, not two, but three) different = computational models for RWA which can impact GMPLS and PCE protocols: =09 1. A single PCE computing both the path and wavelength=20 2. Two distinct PCEs, where one computes the path, and a different PCE = computes the wavelength assignment=20 3. A PCE computes the path and wavelength assignment is accomplished in = a distributed fashion via signaling (e.g., using label set objects)=20 Do we really need all three models? =09 (c) G.709 includes the Optical Multiplex Section and Optical Channels. = RFC4238 was aimed at GMPLS extensions for G.709 (Optical Transport = Network) control. Weren't we finished with all this optical stuff years = ago? =09 I'd like to think the draft answers some of these questions. I also = think that network element models and the process models are important = enough to warrant this separate framework document. Your opinions are = solicited. =09 Regards =09 Greg B. =09 --=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 =09 ------_=_NextPart_001_01C80156.B32B3353 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Hi = Greg,
     
    Sorry for the=20 delay in replying. I'm working on this topic since a while so yes, it's=20 interesting. Before going on specific issue I would have some=20 question/clarification regarding the draft itself.
     
     
    * Within = Abstract and=20 the following.
    You = don't talk about=20 Optical Cross Connects (OXC) is something missing or understated=20 somewhere?
     
     
    * = Section 3.1=20 where you state:
    "A = fixed mapping=20 between the
    GMPLS = label space and=20 these ITU-T WDM grids as proposed in [Otani] "
    Does it = implies a sort=20 of network level label space? How relate with usual local label=20 significance?
     
     
    * = Section 3.4=20 Wavelength Converters
    "Current = or envisioned=20 contexts for wavelength converters are : ..."
    Could = we think to a description/model for = wavelength=20 converter that is technology agnostic? Simply=20 something like: full conversion capability, partial conversion = capability=20 with some constrains, and may be others.
     
     
    * = Section 3.4. the=20 following:
    "4. Wavelength=20 converters that are O-E-O based will have a restriction =
    based on the=20 modulation format and transmission speed"
    Not = clear to me the type=20 of restriction here when OEO happens... probably I'm missing what you = mean=20 here.
     
     
    * = Section 4.1 when you=20 talk about Lightpath temporal characteristics:
    "Lightpath=20 connection duration has typically been thought of as =
    approximately=20 three time frames: "
    and the = following you=20 define: dynamics, pseudo-static, static.
    Why = there=92s a need of=20 this classification? When you us Short/long is compared to = what?
     
     
    minor typo on your mail below: point (c) rfc4328 (not 4238)=20 right?
     
    Thanks,
    Giovanni


     


    From: Greg Bernstein=20 [mailto:gregb@grotto-networking.com]
    Sent: gioved=EC 27 = settembre=20 2007 1.42
    To: ccamp; pce@ietf.org
    Subject: [Pce] = Some key=20 issues with Wavelength Switched Optical = Networks...

    Hi folks, I haven't seen too many comments on our draft = "Framework=20 for GMPLS and PCE Control of Wavelength Switched Optical Networks" ( = http://www.ietf.org/internet-drafts/draft-bernstein-= ccamp-wavelength-switched-01.txt).=20 So I figured I'd point out some potentially controversial issues that = the=20 draft brings up.

    (a) The draft brings up models for the = following WDM=20 network elements:
    1. WDM links=20
    2. Optical transmitters
    3. Wavelength Converters and OEO regenerators=20
    4. ROADMs, FOADMs, optical splitters and combiners.=20
        For items (3) and (4) we are taking the = modeling=20 lead rather than some other SDO.  And for ROADMs, in particular, = we going=20 beyond the classic ITU-T "fabric" model (M.3100) which has been the = mainstay=20 of any connection oriented switch (TDM, ATM, MPLS).

    (b) The = draft=20 brings up three (not one, not two, but three) different computational = models=20 for RWA which can impact GMPLS and PCE protocols:
    1. A single PCE computing both the path and wavelength=20
    2. Two distinct PCEs, where one computes the path, and a different = PCE=20 computes the wavelength assignment=20
    3. A PCE computes the path and wavelength assignment is = accomplished in a=20 distributed fashion via signaling (e.g., using label set objects)=20
        Do we really need all three = models?

    (c)=20 G.709 includes the Optical Multiplex Section and Optical = Channels. =20 RFC4238 was aimed at GMPLS extensions for G.709  (Optical = Transport=20 Network) control.  Weren't we finished with all this optical = stuff years=20 ago?

    I'd like to think the draft answers some of these = questions. =20 I also think that network element models and the process models are = important=20 enough to warrant this separate framework document.  Your = opinions are=20 solicited.

    Regards

    Greg B.
    --=20
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
    =3D
    Dr Greg Bernstein, Grotto Networking (510) 573-2237
    
    
    ------_=_NextPart_001_01C80156.B32B3353-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Sep 2007 19:36:29 +0000 Message-ID: <02f801c8013d$74ed4a00$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Hamid Ould-Brahim" , Subject: Fw: Four L1VPN working group last calls Date: Thu, 27 Sep 2007 20:34:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit Hi CCAMP working group, The L1VPN working group is holding a last call on several drafts. This is clearly all related to the work of CCAMP and we would welcome any further thoughts during the last call. By preference, please send comments to the L1VPN list, but anything sent to the CCAMP list will be forwarded. Thanks, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Thursday, September 27, 2007 8:17 PM Subject: [L1vpn] Four working group last calls > Hi, > > Now that there is a bit of peace and quiet on the CCAMP last calls, we > would like to hold L1VPN last calls on four I-Ds: > > http://www.ietf.org/internet-drafts/draft-ietf-l1vpn-applicability-basic-mode-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-l1vpn-basic-mode-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-l1vpn-bgp-auto-discovery-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-l1vpn-ospf-auto-discovery-03.txt > > Since there are four drafts, we will make this a three week last call. It > will complete at 12 noon GMT on 18th October 2007. > > We will be notifying the IDR, OSPF, and CCAMP working groups about this > last call. > > Thanks, > Adrian, Hamid, and Tomonori > > > _______________________________________________ > L1vpn mailing list > L1vpn@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/l1vpn > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Sep 2007 13:18:28 +0000 Message-ID: <01ce01c80108$8122b240$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Magnus Westerlund" Subject: Fw: Guidelines for protocol designers using UDP Date: Thu, 27 Sep 2007 14:15:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit Hi, Those of you who are LMP implementers and deployers may want to look at this I-D and make comments: - on the I-D direct to the tsvwg - on RFC4204 to CCAMP Thanks, Adrian ----- Original Message ----- From: "Magnus Westerlund" To: "Internet Area" ; ; ; ; "SAAG" Cc: "tsvwg" Sent: Thursday, September 27, 2007 12:33 PM Subject: Guidelines for protocol designers using UDP > Hi, > > In the TSVWG we have been developing a guidelines document for UDP. It > is intended for protocol designers that consider using UDP in their > protocol. We do hope that it will help remove some of the misconception > that UDP is a simple protocol to use. It might look that way because > most of the features necessary for being acceptable to deploy on the > general internet needs to be specified by the one using UDP. It is also > something that the Transport ADs already started using as help in > explaining why and what to fix when we put a DISCUSS on your document > that is using UDP. > > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-udp-guidelines-03.txt > > So TSVWG is still working on this document but we are now considering it > quite complete. So we are looking for feedback from you. Are there > things that are unclear, missing, wrong, etc. Please provide your > feedback to TSVWG (tsvwg@ietf.org). > > Thanks > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Sep 2007 09:52: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: [OSPF] Fwd: Posting of draft-ietf-ospf-ospfv3-traffic-09.txt Date: Thu, 27 Sep 2007 10:48:59 +0100 Message-ID: <52A0FF47062B0B4C80862F2526E02409049197A1@enfimail2.datcon.co.uk> Thread-Topic: [OSPF] Fwd: Posting of draft-ietf-ospf-ospfv3-traffic-09.txt Thread-Index: AcgAR8TFF8MyefNJSeiCAiwv8kJx2gAlOmGA From: "Alan Davey" To: "Acee Lindem" , "Mach Chen" Cc: "OSPF List" , "Vishwas Manral" , "CCAMP List" Guys Apologies for the late response. =20 I basically agree with Acee. * It makes sense to define a new OSPFv3-TE LSA type to carry the AS connectivity information. I think that this would probably provide a better and more back compatible way to identify the new advertisements than defining a new link type value. * It also makes sense to use the same approach in OSPFv2 and OSPFv3 and so a new OSPFv2 opaque type may be the way to go.=20 My other comments on the draft, from an OSPFv3 TE perspective, are as follows. * On the subject of identifying the other end of the inter-AS link. - The Link ID sub-TLV is not suitable as it SHOULD be ignored on receipt by an OSPFv3 TE implementation. =20 - The Neighbor ID sub-TLV MUST be used instead. This sub-TLV contains the neighbor's interface ID and the neighbor's 32-bit Router ID (note that this is NOT the TE Router ID). - Use of the Neighbor ID sub-TLV requires configuration at the ASBR of the remote ASBR's interface ID and the 32-bit Router ID. - You may want to advertise a global-scope IPv6 address for the router at the other end of an inter-AS link in a Remote Interface IPv6 Address Sub-TLV. This would also need to be configured. * As Acee pointed out, there is currently no OSPFv3 TE equivalent to the Type 11 Opaque LSA, that is, there is no defined LSA for flooding AS scope TE information. * The wording needs to be changed for OSPFv3 TE when describing the contents of a "proxy" advertisement for the backward direction of an inter-AD TE link. Regards Alan Davey ------------------------------------ Alan Davey Data Connection Ltd Tel: +44 20 8366 1177 Fax: +44 20 8363 1039 Email: Alan.Davey@dataconnection.com Web: http://www.dataconnection.com > -----Original Message----- > From: Acee Lindem [mailto:acee@redback.com]=20 > Sent: 26 September 2007 15:15 > To: Mach Chen > Cc: OSPF List; Vishwas Manral; Alan Davey; CCAMP List > Subject: Re: [OSPF] Fwd: Posting of=20 > draft-ietf-ospf-ospfv3-traffic-09.txt >=20 > Hi Mach, >=20 > On Sep 26, 2007, at 6:10 AM, Mach Chen wrote: >=20 > > Hi Acee, > > > > Pls see inline > > > > > > On 2007-09-25, at 21:05:49 Acee Lindem wrote: > > > >> Hi Mach, > >> Thanks for reviewing. > >> > >> On Sep 25, 2007, at 4:24 AM, Mach Chen wrote: > >> > >>> Hi Acee and other authors, > >>> > >>> > >>> > >>> Some questions to ospfv3-traffic > >>> > >>> > >>> > >>> 1. In this ospfv3-traffic document, a new LSA, Intra-Area-TE > >>> LSA, is defined to advertise IPv6 TE information. From=20 > name of this=20 > >>> new LSA, IMHO, it is limited to be used for Intra-Area TE=20 > only. So,=20 > >>> if there are some underlying extensions to ospfv3-traffic, e.g. > >>> Inter-AS TE, it is a little bit strange to re-use the=20 > Intra-Area-TE=20 > >>> LSA, or it has to define a new LSA. So, can we change its name to=20 > >>> something like "OSPFv3 TE LSA"? > >> It would be if we had intended it to carry AS wide information. > >> However, it was not initially intended for this. The=20 > initial thought=20 > >> was that we would do a better job for OSPFv3 and define=20 > separate LSA=20 > >> types for intra-area, inter-area, and AS external TE LSAs.=20 > Thoughts=20 > >> on this (copied ccamp as well)? > > > > So, the conclusion is that a new LSA(may be called Inter-AS-TE LSA)=20 > > has to be defined for advertising inter-AS TE information=20 > in support=20 > > of OSPFv3 TE, am I right? > > > >> I guess, IMHO, this discrepancy > >> exposes the choice of a new link type for inter-AS=20 > connectivity as a=20 > >> bit of a hack. > >> > > > > For OSPFv3 TE(separate LSAs are used) is YES. But as to OSPFv2 TE,=20 > > IMHO, there should be a new link type to identify an=20 > inter-AS link, or=20 > > we need another new LSA. >=20 >=20 > It seems to me that if we do add the link in your draft, then=20 > it should be done the same in OSPFv2 and OSPFv3. Advertising=20 > it as a new link type is one way to advertise inter-AS=20 > connectivity. However, it isn't necessarily a link. This=20 > seems to me to be more of a semantical discrepancy than the=20 > name of the LSA. In section 4, I notice that at least for=20 > OSPFv2 the draft says the new link may be advertised in=20 > either a type 11 opaque LSA or type 10 opaque LSA. Given the=20 > maturity of RFC 3630, it almost seems to me that we should=20 > allocate a new LSA opaque type for this purpose. >=20 > What is the status of draft-ietf-ccamp-ospf-interas-te-=20 > extension-01.txt? I know at the OSPF meeting there were a=20 > number of people who questioned whether or not it was necessary. >=20 > Thanks, > Acee >=20 >=20 >=20 >=20 >=20 > > > >> > >> > >>> > >>> > >>> 2. Section 2. > >>> > >>> "The format of the TLVs within the body of a router=20 > information LSA=20 > >>> is the same as the format used by the Traffic Engineering=20 > Extensions=20 > >>> to OSPF [TE]." > >>> > >>> > >>> > >>> What's "a router information LSA"? Or should it be "an=20 > Intra-Area-=20 > >>> TE LSA" ? > >> > >> Yes. Good catch. I'll fix this. > > > > Thanks. > > > >> > >> Thanks, > >> Acee > > > > > > Best regards, =09 > > Mach Chen > > >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Sep 2007 23:54:50 +0000 Message-ID: <46FAEE2C.5040008@grotto-networking.com> Date: Wed, 26 Sep 2007 16:41:32 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ccamp , pce@ietf.org Subject: Some key issues with Wavelength Switched Optical Networks... Content-Type: multipart/alternative; boundary="------------090500030104070206070906" This is a multi-part message in MIME format. --------------090500030104070206070906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi folks, I haven't seen too many comments on our draft "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks" ( http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-01.txt). So I figured I'd point out some potentially controversial issues that the draft brings up. (a) The draft brings up models for the following WDM network elements: 1. WDM links 2. Optical transmitters 3. Wavelength Converters and OEO regenerators 4. ROADMs, FOADMs, optical splitters and combiners. For items (3) and (4) we are taking the modeling lead rather than some other SDO. And for ROADMs, in particular, we going beyond the classic ITU-T "fabric" model (M.3100) which has been the mainstay of any connection oriented switch (TDM, ATM, MPLS). (b) The draft brings up three (not one, not two, but three) different computational models for RWA which can impact GMPLS and PCE protocols: 1. A single PCE computing both the path and wavelength 2. Two distinct PCEs, where one computes the path, and a different PCE computes the wavelength assignment 3. A PCE computes the path and wavelength assignment is accomplished in a distributed fashion via signaling (e.g., using label set objects) Do we really need all three models? (c) G.709 includes the Optical Multiplex Section and Optical Channels. RFC4238 was aimed at GMPLS extensions for G.709 (Optical Transport Network) control. Weren't we finished with all this optical stuff years ago? I'd like to think the draft answers some of these questions. I also think that network element models and the process models are important enough to warrant this separate framework document. Your opinions are solicited. Regards Greg B. -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------090500030104070206070906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi folks, I haven't seen too many comments on our draft "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks" ( http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-01.txt). So I figured I'd point out some potentially controversial issues that the draft brings up.

    (a) The draft brings up models for the following WDM network elements:
    1. WDM links
    2. Optical transmitters
    3. Wavelength Converters and OEO regenerators
    4. ROADMs, FOADMs, optical splitters and combiners.
        For items (3) and (4) we are taking the modeling lead rather than some other SDO.  And for ROADMs, in particular, we going beyond the classic ITU-T "fabric" model (M.3100) which has been the mainstay of any connection oriented switch (TDM, ATM, MPLS).

    (b) The draft brings up three (not one, not two, but three) different computational models for RWA which can impact GMPLS and PCE protocols:
    1. A single PCE computing both the path and wavelength
    2. Two distinct PCEs, where one computes the path, and a different PCE computes the wavelength assignment
    3. A PCE computes the path and wavelength assignment is accomplished in a distributed fashion via signaling (e.g., using label set objects)
        Do we really need all three models?

    (c) G.709 includes the Optical Multiplex Section and Optical Channels.  RFC4238 was aimed at GMPLS extensions for G.709  (Optical Transport Network) control.  Weren't we finished with all this optical stuff years ago?

    I'd like to think the draft answers some of these questions.  I also think that network element models and the process models are important enough to warrant this separate framework document.  Your opinions are solicited.

    Regards

    Greg B.
    -- 
    ===================================================
    Dr Greg Bernstein, Grotto Networking (510) 573-2237
    
    
    --------------090500030104070206070906-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Sep 2007 14:18:44 +0000 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Cc: OSPF List , Vishwas Manral , Alan Davey , CCAMP List Content-Transfer-Encoding: quoted-printable From: Acee Lindem Subject: Re: [OSPF] Fwd: Posting of draft-ietf-ospf-ospfv3-traffic-09.txt Date: Wed, 26 Sep 2007 10:14:36 -0400 To: Mach Chen Hi Mach, On Sep 26, 2007, at 6:10 AM, Mach Chen wrote: > Hi Acee, > > Pls see inline > > > On 2007-09-25, at 21:05:49 Acee Lindem wrote: > >> Hi Mach, >> Thanks for reviewing. >> >> On Sep 25, 2007, at 4:24 AM, Mach Chen wrote: >> >>> Hi Acee and other authors, >>> >>> >>> >>> Some questions to ospfv3-traffic >>> >>> >>> >>> 1. In this ospfv3-traffic document, a new LSA, Intra-Area-TE >>> LSA, is defined to advertise IPv6 TE information. =46rom name of = this >>> new LSA, IMHO, it is limited to be used for Intra-Area TE only. So, >>> if there are some underlying extensions to ospfv3-traffic, e.g. >>> Inter-AS TE, it is a little bit strange to re-use the Intra-Area-TE >>> LSA, or it has to define a new LSA. So, can we change its name to >>> something like =93OSPFv3 TE LSA=94? >> It would be if we had intended it to carry AS wide information. >> However, it was not initially intended for this. The initial thought >> was that we would do a better job for OSPFv3 and define separate LSA >> types for intra-area, inter-area, and AS external TE LSAs. Thoughts >> on this (copied ccamp as well)? > > So, the conclusion is that a new LSA(may be called Inter-AS-TE LSA) =20= > has to be defined for advertising inter-AS TE information in =20 > support of OSPFv3 TE, am I right? > >> I guess, IMHO, this discrepancy >> exposes the choice of a new link type for inter-AS connectivity as a >> bit of a hack. >> > > For OSPFv3 TE(separate LSAs are used) is YES. But as to OSPFv2 TE, =20 > IMHO, there should be a new link type to identify an inter-AS link, =20= > or we need another new LSA. It seems to me that if we do add the link in your draft, then it =20 should be done the same in OSPFv2 and OSPFv3. Advertising it as a new =20= link type is one way to advertise inter-AS connectivity. However, it =20 isn't necessarily a link. This seems to me to be more of a semantical =20= discrepancy than the name of the LSA. In section 4, I notice that at =20 least for OSPFv2 the draft says the new link may be advertised in =20 either a type 11 opaque LSA or type 10 opaque LSA. Given the maturity =20= of RFC 3630, it almost seems to me that we should allocate a new LSA =20 opaque type for this purpose. What is the status of draft-ietf-ccamp-ospf-interas-te-=20 extension-01.txt? I know at the OSPF meeting there were a number of =20 people who questioned whether or not it was necessary. Thanks, Acee > >> >> >>> >>> >>> 2. Section 2. >>> >>> =93The format of the TLVs within the body of a router information = LSA >>> is the same as the format used by the Traffic Engineering >>> Extensions to OSPF [TE].=94 >>> >>> >>> >>> What=92s =93a router information LSA=94? Or should it be =93an = Intra-Area- >>> TE LSA=94 ? >> >> Yes. Good catch. I'll fix this. > > Thanks. > >> >> Thanks, >> Acee > > > Best regards, =09 > Mach Chen > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Sep 2007 11:48:02 +0000 Message-ID: <46FA469A.5090708@cn.kddilabs.jp> Date: Wed, 26 Sep 2007 20:46:34 +0900 From: ogaki User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: ccamp@ops.ietf.org Cc: Adrian Farrel , Ross Callon , Tomohiro Otani Subject: Re: Plans for GELS work in CCAMP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi All, Sorry for this late reply. We are interesd in this activity and can support this work as an operator= . Regards, Kenichi Diego Caviglia (GA/ERI) wrote: >Hi Adrian hi Deborah, > I think that this is a very good way to proceed I a= lso think the people in the DT are the right ones. > >I'd like to contribute this work so DT guys please fill free to contact = me. > >Best Regards > >Diego > =20 > >>-----Original Message----- >>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Beh= alf >>Of Adrian Farrel >>Sent: mercoled=EC 5 settembre 2007 11.51 >>To: ccamp@ops.ietf.org >>Cc: Ross Callon >>Subject: Plans for GELS work in CCAMP >> >>Hi, >> >>We owe you a plan for starting the GELS work in CCAMP. >> >>As you may have seen, we have just sent a request to the ADs to push >>through >>our recharter as discussed on the mailing list. The ADs have already >>indicated their support, so hopefully this will be fairly smooth. >> >>We have also been talking with Don and Loa about starting work on the G= ELS >>drafts that we will accept into the working group as a starting point. >>(Other drafts can be added as needed.) >> >>1. "GMPLS Extensions for PE to PE Ethernet Label Switched Paths(LSPs)" >>This document is the generic work: >>- Introduction >>- Rationale for GMPLS Control of Ethernet >>- Generic functional requirements (no data plane specifics!) >>- Applicability of existing protocol elements >>- New generic protocol elements (nothing specific to the data plane) >> >>2. "GMPLS control of P2P TE for PBB-TE (802.1Qay)" >>Mainly references to the generic document. >>Some protocol specifics: >>- Code points (i.e. IANA section) >>- Label allocation and swapping rules >>Not a large document. >> >>Other drafts that we might also see: >> >>3. "GMPLS control of P2P TE for IEEE802.1Q" >>Another data plane-specific draft, like 2, but for a different data pla= ne >> >>4. Applicability Statement >>A concise description of how and why to apply GMPLS to Ethernet. >>Probably not written until after the protocol work is done. >> >>We propose a relatively small design team to get this work started. >> Loa Andersson >> Lou Berger >> Don Fedyk >> George Swallow >> >>We are NOT trying to exclude anyone from the work, and we make a couple= of >>observations: >> >>- A design team is just a group of people working on a >> draft. >>- Anyone and everyone is welcome to write a draft. >>- We feel that an initial design should be small to make >> rapid initial progress. >>- We welcome (and expect!) full and detailed contribution >> on the mailing list as this work progresses. >>- Everyone who contributes to a draft should be appropriately >> recognised in the draft. >> >>Last point: >>I propose to close the GELS mailing list now. >> >>Hope this is all satisfactory to you. >> >>Regards, >>Adrian and Deborah >> >> >> =20 >> > > > > > =20 > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Sep 2007 10:14:09 +0000 Date: Wed, 26 Sep 2007 18:10:52 +0800 From: Mach Chen Subject: Re: Re: [OSPF] Fwd: Posting of draft-ietf-ospf-ospfv3-traffic-09.txt To: Acee Lindem Cc: OSPF List , Vishwas Manral , Alan Davey , CCAMP List Message-id: <0JOZ003PZ0AKV7@szxga01-in.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGkgQWNlZSwNCg0KUGxzIHNlZSBpbmxpbmUNCg0KICANCk9uIDIwMDctMDktMjUsIGF0IDIxOjA1 OjQ5IEFjZWUgTGluZGVtIHdyb3RlOg0KDQo+SGkgTWFjaCwNCj5UaGFua3MgZm9yIHJldmlld2lu Zy4NCj4NCj5PbiBTZXAgMjUsIDIwMDcsIGF0IDQ6MjQgQU0sIE1hY2ggQ2hlbiB3cm90ZToNCj4N Cj4+IEhpIEFjZWUgYW5kIG90aGVyIGF1dGhvcnMsDQo+Pg0KPj4NCj4+DQo+PiBTb21lIHF1ZXN0 aW9ucyB0byBvc3BmdjMtdHJhZmZpYw0KPj4NCj4+DQo+Pg0KPj4gMS4gICAgICAgSW4gdGhpcyBv c3BmdjMtdHJhZmZpYyBkb2N1bWVudCwgYSBuZXcgTFNBLCBJbnRyYS1BcmVhLVRFICANCj4+IExT QSwgaXMgZGVmaW5lZCB0byBhZHZlcnRpc2UgSVB2NiBURSBpbmZvcm1hdGlvbi4gRnJvbSBuYW1l IG9mIHRoaXMgIA0KPj4gbmV3IExTQSwgSU1ITywgaXQgaXMgbGltaXRlZCB0byBiZSB1c2VkIGZv ciBJbnRyYS1BcmVhIFRFIG9ubHkuIFNvLCAgDQo+PiBpZiB0aGVyZSBhcmUgc29tZSB1bmRlcmx5 aW5nIGV4dGVuc2lvbnMgdG8gb3NwZnYzLXRyYWZmaWMsIGUuZy4gIA0KPj4gSW50ZXItQVMgVEUs IGl0IGlzIGEgbGl0dGxlIGJpdCBzdHJhbmdlIHRvIHJlLXVzZSB0aGUgSW50cmEtQXJlYS1URSAg DQo+PiBMU0EsIG9yIGl0IGhhcyB0byBkZWZpbmUgYSBuZXcgTFNBLiBTbywgY2FuIHdlIGNoYW5n ZSBpdHMgbmFtZSB0byAgDQo+PiBzb21ldGhpbmcgbGlrZSChsE9TUEZ2MyBURSBMU0GhsT8NCj5J dCB3b3VsZCBiZSBpZiB3ZSBoYWQgaW50ZW5kZWQgaXQgdG8gY2FycnkgQVMgd2lkZSBpbmZvcm1h dGlvbi4gIA0KPkhvd2V2ZXIsIGl0IHdhcyBub3QgaW5pdGlhbGx5IGludGVuZGVkIGZvciB0aGlz LiBUaGUgaW5pdGlhbCB0aG91Z2h0ICANCj53YXMgdGhhdCB3ZSB3b3VsZCBkbyBhIGJldHRlciBq b2IgZm9yIE9TUEZ2MyBhbmQgZGVmaW5lIHNlcGFyYXRlIExTQSAgDQo+dHlwZXMgZm9yIGludHJh LWFyZWEsIGludGVyLWFyZWEsIGFuZCBBUyBleHRlcm5hbCBURSBMU0FzLiBUaG91Z2h0cyAgDQo+ b24gdGhpcyAoY29waWVkIGNjYW1wIGFzIHdlbGwpPw0KDQpTbywgdGhlIGNvbmNsdXNpb24gaXMg dGhhdCBhIG5ldyBMU0EobWF5IGJlIGNhbGxlZCBJbnRlci1BUy1URSBMU0EpIGhhcyB0byBiZSBk ZWZpbmVkIGZvciBhZHZlcnRpc2luZyBpbnRlci1BUyBURSBpbmZvcm1hdGlvbiBpbiBzdXBwb3J0 IG9mIE9TUEZ2MyBURSwgYW0gSSByaWdodD8NCiANCj4gSSBndWVzcywgSU1ITywgdGhpcyBkaXNj cmVwYW5jeSAgDQo+ZXhwb3NlcyB0aGUgY2hvaWNlIG9mIGEgbmV3IGxpbmsgdHlwZSBmb3IgaW50 ZXItQVMgY29ubmVjdGl2aXR5IGFzIGEgIA0KPmJpdCBvZiBhIGhhY2suDQo+DQoNCkZvciBPU1BG djMgVEUoc2VwYXJhdGUgTFNBcyBhcmUgdXNlZCkgaXMgWUVTLiBCdXQgYXMgdG8gT1NQRnYyIFRF LCBJTUhPLCB0aGVyZSBzaG91bGQgYmUgYSBuZXcgbGluayB0eXBlIHRvIGlkZW50aWZ5IGFuIGlu dGVyLUFTIGxpbmssIG9yIHdlIG5lZWQgYW5vdGhlciBuZXcgTFNBLg0KDQo+DQo+DQo+Pg0KPj4N Cj4+IDIuICAgICAgIFNlY3Rpb24gMi4NCj4+DQo+PiChsFRoZSBmb3JtYXQgb2YgdGhlIFRMVnMg d2l0aGluIHRoZSBib2R5IG9mIGEgcm91dGVyIGluZm9ybWF0aW9uIExTQSAgDQo+PiBpcyB0aGUg c2FtZSBhcyB0aGUgZm9ybWF0IHVzZWQgYnkgdGhlIFRyYWZmaWMgRW5naW5lZXJpbmcgIA0KPj4g RXh0ZW5zaW9ucyB0byBPU1BGIFtURV0uobENCj4+DQo+Pg0KPj4NCj4+IFdoYXShr3MgobBhIHJv dXRlciBpbmZvcm1hdGlvbiBMU0GhsT8gIE9yIHNob3VsZCBpdCBiZSChsGFuIEludHJhLUFyZWEt IA0KPj4gVEUgTFNBobEgPw0KPg0KPlllcy4gR29vZCBjYXRjaC4gSSdsbCBmaXggdGhpcy4NCg0K VGhhbmtzLg0KDQo+DQo+VGhhbmtzLA0KPkFjZWUNCg0KDQpCZXN0IHJlZ2FyZHMsCQkJDQpNYWNo IENoZW4NCg0K Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Sep 2007 21:12:58 +0000 Message-ID: <003801c7ffb8$86c94070$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Kohei Shiomoto" , "Dimitri Papadimitriou" , "Jean-Louis Le Roux" , "Martin Vigoureux" , "Brungard, Deborah A, ALABS" Subject: Last call completed on draft-ietf-ccamp-gmpls-mln-reqs-05.txt Date: Tue, 25 Sep 2007 22:10:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, Working group last call completed on draft-ietf-ccamp-gmpls-mln-reqs-05.txt and draft-ietf-ccamp-gmpls-mln-eval-03.txt with a few comments to consider. The question was raised about the naming of "virtual TE links." It was suggested that "potential" be considered as a more appropriate word, partly because of the existing overload of "virtual" in various contexts, and partly to tie in with the ASON use of terminology. Could the authors please think about this and propose a resolution. We also received some comments from the ITU-T in their liaison https://datatracker.ietf.org/liaison/368/. They raise some issues for our consideration and the authors need to address these points so that they can update the I-D if necessary, and so we can respond to the ITU-T as necessary. Adaptation - They suggest that we should include a definition of Adaptation. - They suggest advertising the adaptation capability/ies of a link in place of the switching capabilities. I am confused by this because I would have thought that both pieces of information are needed. It may be that the ITU-T are assuming that the technology layer is known a priori. It is certainly the case that multiple switching or adaptation capabilities should be able to be advertised on a single link, and I think this is in the I-Ds, but maybe it needs clarification. - Abstract representations of layers and adaptations may be advantageous. Although this might be a solution-specific issue, if there are requirements they should be drawn out. Virtual Node The ITU-T suggests that the virtual node model might be applied as a solution architecture alongside the virtual links. Maybe the requirements draft could include some comments on this. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Sep 2007 14:40: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: I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-07.txt Date: Tue, 25 Sep 2007 09:39:24 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF0F210A83@OCCLUST04EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-07.txt Thread-Index: Acf/U08EODVTrmqEReyl7biQI8t9VAALh3SA From: "BRUNGARD, DEBORAH A, ATTLABS" To: "Adrian Farrel" , Cc: "Jean Philippe Vasseur" , "Jean-Louis Le Roux" Agree, I don't think another WG Last Call is necessary. As Adrian notes, interested parties should review the updated document. Thanks for all the editing- Deborah=20 -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Tuesday, September 25, 2007 4:55 AM To: ccamp@ops.ietf.org Cc: BRUNGARD, DEBORAH A, ATTLABS; 'Jean Philippe Vasseur'; Jean-Louis Le Roux Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-07.txt=20 Hi, This new revision addresses two IESG DISCUSSes. The first, from Sam Hartman, gives rise to a new paragraph (the first=20 paragraph in section 8) to point out certain security concerns with RSVP-TE. The second, from Russ Housley, introduces the GenArt review by Eric Gray and=20 gives rise to a good number of editorial changes. Nearly all of these are of=20 no technical substance comprising the addition of text for clarification (especially where the old text said "SHOULD" and there was no description of=20 why or how an implementation might vary from the SHOULD). In section 3.1 there is, however, a set of changes that, while they don't change the intent=20 of the authors, do make practical changes to the interpretation of the=20 protocol procedures - essentially, we have changed some of the RFC 2119=20 language. In my opinion, these changes don't warrant a further working group last=20 call, although I would encourage interested parties to read carefully.=20 However, on this I-D I need to recuse myself from the decision process and=20 hand over to Deborah. Thanks, Adrian ----- Original Message -----=20 From: To: Cc: Sent: Monday, September 24, 2007 9:15 PM Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-07.txt >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Common Control and Measurement Plane=20 > Working Group of the IETF. > > Title : Inter domain Multiprotocol Label Switching (MPLS) and Generalized=20 > MPLS (GMPLS) Traffic Engineering - RSVP-TE extensions > Author(s) : A. Ayyangar, et al. > Filename : draft-ietf-ccamp-inter-domain-rsvp-te-07.txt > Pages : 22 > Date : 2007-9-24 > > This document describes procedures and protocol extensions for the > use of Resource ReserVation Protocol Traffic Engineering (RSVP-TE) > signaling in Multiprotocol Label Switching Traffic Engineering > (MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and > non-packet networks to support the establishment and maintenance of > Label Switched Paths that cross domain boundaries. > > For the purpose of this document, a domain is considered to be any > collection of network elements within a common realm of address space > or path computation responsibility. Examples of such domains include > Autonomous Systems, IGP routing areas, and GMPLS overlay networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-t e-07.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-inter-domain-rsvp-te-07.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-inter-domain-rsvp-te-07.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. >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Sep 2007 13:09:39 +0000 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/alternative; boundary=Apple-Mail-53--182531231 Message-Id: Cc: OSPF List , Vishwas Manral , Alan Davey , CCAMP List From: Acee Lindem Subject: Re: [OSPF] Fwd: Posting of draft-ietf-ospf-ospfv3-traffic-09.txt Date: Tue, 25 Sep 2007 09:05:49 -0400 To: Mach Chen --Apple-Mail-53--182531231 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Hi Mach, Thanks for reviewing. On Sep 25, 2007, at 4:24 AM, Mach Chen wrote: > Hi Acee and other authors, > > > > Some questions to ospfv3-traffic > > > > 1. In this ospfv3-traffic document, a new LSA, Intra-Area-TE =20 > LSA, is defined to advertise IPv6 TE information. =46rom name of this =20= > new LSA, IMHO, it is limited to be used for Intra-Area TE only. So, =20= > if there are some underlying extensions to ospfv3-traffic, e.g. =20 > Inter-AS TE, it is a little bit strange to re-use the Intra-Area-TE =20= > LSA, or it has to define a new LSA. So, can we change its name to =20 > something like =93OSPFv3 TE LSA=94? It would be if we had intended it to carry AS wide information. =20 However, it was not initially intended for this. The initial thought =20 was that we would do a better job for OSPFv3 and define separate LSA =20 types for intra-area, inter-area, and AS external TE LSAs. Thoughts =20 on this (copied ccamp as well)? I guess, IMHO, this discrepancy =20 exposes the choice of a new link type for inter-AS connectivity as a =20 bit of a hack. > > > 2. Section 2. > > =93The format of the TLVs within the body of a router information LSA =20= > is the same as the format used by the Traffic Engineering =20 > Extensions to OSPF [TE].=94 > > > > What=92s =93a router information LSA=94? Or should it be =93an = Intra-Area-=20 > TE LSA=94 ? Yes. Good catch. I'll fix this. Thanks, Acee --Apple-Mail-53--182531231 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 Hi Mach,=A0
    Thanks for = reviewing.=A0

    On Sep 25, 2007, at 4:24 AM, Mach = Chen wrote:

    Hi Acee and other authors,=A0

    Some questions to ospfv3-traffic=A0

    1.=A0=A0=A0=A0=A0= =A0



    =A0

    2.=A0=A0=A0=A0=A0= =A0

    =93The format of the TLVs within the body of = a router = information LSA is the same as the format = used by the Traffic Engineering Extensions to OSPF [TE].=94=A0=A0

    What=92s =93a router information LSA=94?=A0 Or = should it be =93an Intra-Area-TE LSA=94 = ?

    <= /BLOCKQUOTE>

    Yes. = Good catch. I'll fix this.=A0

    Thanks,
    Acee
    <= DIV>

    From: "Adrian Farrel" To: Cc: "Brungard, Deborah A, ALABS" , "'Jean Philippe Vasseur'" , "Jean-Louis Le Roux" Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-07.txt Date: Tue, 25 Sep 2007 09:55:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, This new revision addresses two IESG DISCUSSes. The first, from Sam Hartman, gives rise to a new paragraph (the first paragraph in section 8) to point out certain security concerns with RSVP-TE. The second, from Russ Housley, introduces the GenArt review by Eric Gray and gives rise to a good number of editorial changes. Nearly all of these are of no technical substance comprising the addition of text for clarification (especially where the old text said "SHOULD" and there was no description of why or how an implementation might vary from the SHOULD). In section 3.1 there is, however, a set of changes that, while they don't change the intent of the authors, do make practical changes to the interpretation of the protocol procedures - essentially, we have changed some of the RFC 2119 language. In my opinion, these changes don't warrant a further working group last call, although I would encourage interested parties to read carefully. However, on this I-D I need to recuse myself from the decision process and hand over to Deborah. Thanks, Adrian ----- Original Message ----- From: To: Cc: Sent: Monday, September 24, 2007 9:15 PM Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-07.txt >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Common Control and Measurement Plane > Working Group of the IETF. > > Title : Inter domain Multiprotocol Label Switching (MPLS) and Generalized > MPLS (GMPLS) Traffic Engineering - RSVP-TE extensions > Author(s) : A. Ayyangar, et al. > Filename : draft-ietf-ccamp-inter-domain-rsvp-te-07.txt > Pages : 22 > Date : 2007-9-24 > > This document describes procedures and protocol extensions for the > use of Resource ReserVation Protocol Traffic Engineering (RSVP-TE) > signaling in Multiprotocol Label Switching Traffic Engineering > (MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and > non-packet networks to support the establishment and maintenance of > Label Switched Paths that cross domain boundaries. > > For the purpose of this document, a domain is considered to be any > collection of network elements within a common realm of address space > or path computation responsibility. Examples of such domains include > Autonomous Systems, IGP routing areas, and GMPLS overlay networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-te-07.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-inter-domain-rsvp-te-07.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-inter-domain-rsvp-te-07.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. > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Sep 2007 09:08:34 +0000 Message-ID: <041401c7ff53$46cd8130$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Ross Callon" Cc: , "Brungard, Deborah A, ALABS" , , "WG Milestone Tracker" Subject: Please publish draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04 Date: Tue, 25 Sep 2007 10:01:42 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0408_01C7FF5B.1288A3C0" This is a multi-part message in MIME format. ------=_NextPart_000_0408_01C7FF5B.1288A3C0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi Ross, Please take draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04.txt through the IESG process for publication as an Informational RFC. The proto-shepherd-write-up (TM) is attached. Cheers, Adrian ------=_NextPart_000_0408_01C7FF5B.1288A3C0 Content-Type: text/plain; format=flowed; name="draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04-write-up.txt"; reply-type=original Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04-write-up.txt" Proto-write-up for draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04 Suggest that this I-D is progressed in parallel with draft-ietf-ccamp-mpls-gmpls-interwork-reqts > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? Adrian Farrel is the document shepherd. He has personally reviewed the I-D and believes it is ready for forwarding to the IESG for publication. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? This is a fairly old document. In its early days it had substantial review and discussion. More recently the level of input has tailed off probably because the draft was largely complete. Although the I-D has had no explicit review from the MPLS working group most of the people concerned with the migration of MPLS-TE to GMPLS are participants in CCAMP. > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? No concerns. > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. The document is sound. The document filename is easily confused with draft-ietf-ccamp-mpls-gmpls-interwork-reqts that is also going to the IESG for publication at this time. But the document titles are sufficiently different to avoid confusion. > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? The working group has indicated is understanding and support for the requirements expressed in this I-D. The solution models described have not drawn any unfavorable comments except as noted in the I-D. > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) No threats. No discontent. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? All checks made. > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. References split. No downrefs. > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC2434]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? This is an Informational I-D. A null IANA section is present. > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? No such sections. > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up? Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: > > Technical Summary > Relevant content can frequently be found in the abstract > and/or introduction of the document. If not, this may be > an indication that there are deficiencies in the abstract > or introduction. 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. > Working Group Summary > Was there anything in WG process that is worth noting? For > example, was there controversy about particular points or > were there decisions where the consensus was particularly > rough? Nothing of note. > Document Quality > Are there existing implementations of the protocol? Have a > significant number of vendors indicated their plan to > implement the specification? Are there any reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? If > there was a MIB Doctor, Media Type or other expert review, > what was its course (briefly)? In the case of a Media Type > review, on what date was the request posted? This is an Informational I-D with no protocol specifications. The authors list demonstrates considerable interest from providers in preparing for migration from MPLS-TE to GMPLS. Early versions of this document were founded on significant discussions with Kireeti Kompella resulting in considerable simplification of the ideas put forward. The final versions of this document received detailed review from Adrian Farrel resulting in many small changes. ------=_NextPart_000_0408_01C7FF5B.1288A3C0-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Sep 2007 09:08:26 +0000 Message-ID: <041501c7ff53$47282450$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Ross Callon" Cc: , "Brungard, Deborah A, ALABS" , , "WG Milestone Tracker" Subject: Please publish draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02.txt Date: Tue, 25 Sep 2007 10:03:02 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_040E_01C7FF5B.429BC4C0" This is a multi-part message in MIME format. ------=_NextPart_000_040E_01C7FF5B.429BC4C0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi Ross, Please take draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02.txt through the IESG process for publication as an Informational RFC. The proto-shepherd-write-up (TM) is attached. Cheers, Adrian ------=_NextPart_000_040E_01C7FF5B.429BC4C0 Content-Type: text/plain; format=flowed; name="draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02-write-up.txt"; reply-type=original Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02-write-up.txt" Proto-write-up for draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02 Suggest that this I-D is progressed in parallel with draft-ietf-ccamp-mpls-gmpls-interwork-fmwk > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? Adrian Farrel is the document shepherd. He has personally reviewed the I-D and believes it is ready for forwarding to the IESG for publication. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? This is a fairly old document. In its early days it had substantial review and discussion. More recently the level of input has tailed off probably because the draft was largely technically complete. The last few revisions of the I-D have been largely editorial working to improve the readability and presentaiton. Although the I-D has had no explicit review from the MPLS working group most of the people concerned with the operation of MPLS-TE networks over GMPLS networks are participants in CCAMP. > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? No concerns. > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. The document is sound. The document filename is easily confused with draft-ietf-ccamp-mpls-gmpls-interwork-fmwk that is also going to the IESG for publication at this time. But the document titles are sufficiently different to avoid confusion. > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? The working group has indicated is understanding and support for the requirements expressed in this I-D. The solution model described has not drawn any unfavorable comments. > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) No threats. No discontent. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? All checks made. > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. References split. No downrefs. > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC2434]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? This is an Informational I-D. A null IANA section is present. > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? No such sections. > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up? Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: > > Technical Summary > Relevant content can frequently be found in the abstract > and/or introduction of the document. If not, this may be > an indication that there are deficiencies in the abstract > or introduction. 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 (ships in the night). 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. An 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. > Working Group Summary > Was there anything in WG process that is worth noting? For > example, was there controversy about particular points or > were there decisions where the consensus was particularly > rough? Nothing of note. > Document Quality > Are there existing implementations of the protocol? Have a > significant number of vendors indicated their plan to > implement the specification? Are there any reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? If > there was a MIB Doctor, Media Type or other expert review, > what was its course (briefly)? In the case of a Media Type > review, on what date was the request posted? This is an Informational I-D with no protocol specifications. The authors list demonstrates interest from providers in this mode of network operation. Much of the material in this document was based on draft-kumaki-ccamp- mpls-gmpls-interworking-01.txt that had input from Cisco Systems. Several vendors are believed to implement MPLS-TE over GMPLS in this way and GMPLS interoperablity events are usually achieved using this model. ------=_NextPart_000_040E_01C7FF5B.429BC4C0-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Sep 2007 01:53:21 +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-02.txt Message-Id: Date: Mon, 24 Sep 2007 12:50:01 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : 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-02.txt Pages : 13 Date : 2007-09-24 Operation of an 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 (ships in the night). 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. K.Kumaki et al. [page 1] draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02 September 2007 This document describes a framework and Service Provider requirements for operating MPLS-TE networks over GMPLS networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02.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-02.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-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-09-24124412.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-mpls-gmpls-interwork-reqts-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-09-24124412.I-D\@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Sep 2007 20:17:28 +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-inter-domain-rsvp-te-07.txt Message-Id: Date: Mon, 24 Sep 2007 16:15:01 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Inter domain Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering - RSVP-TE extensions Author(s) : A. Ayyangar, et al. Filename : draft-ietf-ccamp-inter-domain-rsvp-te-07.txt Pages : 22 Date : 2007-9-24 This document describes procedures and protocol extensions for the use of Resource ReserVation Protocol Traffic Engineering (RSVP-TE) signaling in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and non-packet networks to support the establishment and maintenance of Label Switched Paths that cross domain boundaries. For the purpose of this document, a domain is considered to be any collection of network elements within a common realm of address space or path computation responsibility. Examples of such domains include Autonomous Systems, IGP routing areas, and GMPLS overlay networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-te-07.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-inter-domain-rsvp-te-07.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-inter-domain-rsvp-te-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-9-24154647.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-te-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-inter-domain-rsvp-te-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-9-24154647.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Sep 2007 18:21:17 +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-04.txt Message-Id: Date: Mon, 24 Sep 2007 12:10:02 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Framework for MPLS-TE to GMPLS migration Author(s) : D. Papadimitriou, et al. Filename : draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04.txt Pages : 20 Date : 2007-09-24 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-04 September 2007 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-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-fmwk-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-fmwk-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-09-24120627.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-09-24120627.I-D\@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Sep 2007 17:36:02 +0000 Message-ID: <038701c7fed1$294bec50$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: New revisions of MPLS/GMPLS I-Ds Date: Mon, 24 Sep 2007 18:33:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, As part of preparing these documents for IESG review, I have resubmitted them to fix a bunch of IDnits and format issues. No changes of substance. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Sep 2007 16:13:35 +0000 Message-ID: <031301c7fec5$673e5860$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , , Subject: Deployment of the Internet-Draft Submission Tool Date: Mon, 24 Sep 2007 17:10:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, Fed up with waiting one or two days for your I-D submissions to be posted? The new tool below seems to work fine. The only things to be aware of are: - It checks for nits - It requires that you include creation and expiry stamps such as Created: September 24, 2007 Expires: March 24, 2008 - If you want to fix the nits yourself, you should cancel the submission and come back later. Cheers, Adrian -----Original Message----- From: IETF Secretariat [mailto:ietf-secretariat@ietf.org] Sent: Wednesday, September 19, 2007 9:32 PM To: IETF Announcement list Cc: wgchairs@ietf.org; iesg@ietf.org Subject: Deployment of the Internet-Draft Submission Tool The IETF Secretariat is pleased to announce the deployment of the Internet-Draft Submission Tool (IDST)-Phase I. The IDST is a Web-based application that will allow an IETF participant to submit an Internet-Draft online, obtain approval to post the draft (if necessary), and make the draft immediately available to the community on the IETF Web site without the assistance of the Secretariat (in most cases). The URL for the IDST is: https://datatracker.ietf.org/idst/upload.cgi The URL for instructions for using the IDST is: http://www.ietf.org/idsubmit_instructions.html Although it will still be possible to submit your drafts by e-mail (i.e., by sending them to internet-drafts@ietf.org), the tool is available for use effective immediately, and we encourage you to submit your drafts via the tool starting today. If you have any questions about using the tool or wish to report a bug, then please send a message to idst-developers@ietf.org. Enjoy!! The IETF Secretariat _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Sep 2007 09:44:02 +0000 Date: Mon, 24 Sep 2007 17:41:45 +0800 From: Mach Chen Subject: =?gb2312?B?tPC4tDogW21wbHNdIEFzayBmb3IgY29tbWVudHMgb24gIklHUCBleA==?= =?gb2312?B?dGVuc2lvbiBpbiBzdXBwb3J0IG9mIGludGVyLUFTImRyYWZ0cw==?= To: "'tom.petch'" Cc: ccamp@ops.ietf.org, 'OSPF List' Message-id: <019601c7fe8f$1f238b30$4f0c6f0a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acf7sZ3iKouaCc6fQraeds2F7QwxYwAP2TEg Hi Tom, Thanks for your comments! Sorry for the delay reply. Pls see inline. > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: owner-ccamp@ops.ietf.org = [mailto:owner-ccamp@ops.ietf.org] =B4=FA=B1=ED > tom.petch > =B7=A2=CB=CD=CA=B1=BC=E4: 2007=C4=EA9=D4=C221=C8=D5 0:35 > =CA=D5=BC=FE=C8=CB: Mach Chen > =B3=AD=CB=CD: ccamp@ops.ietf.org > =D6=F7=CC=E2: Re: [mpls] Ask for comments on "IGP extension in support = of > inter-AS"drafts >=20 > A minor editorial on = draft-ietf-ccamp-ospf-interas-te-extension-01.txt. >=20 > Since 3.2 says > "The value of the Link Type for an inter-AS point-to-point link is 3. = The use > of multi-access inter-AS TE links is for future study" > I think that s6. IANA Considerations should also be specific to point-to-point > and not just > " 3 Inter-AS link " Yes, it should be like this:" 3 Inter-AS point-to-point link" >=20 > And a more substantive issue. The I-D claims to be OSPF version = agnostic but, > as draft-ietf-ospf-ospfv3-traffic-08.txt (cited as an Informative Reference > only) says > "A new LS type is defined for the Intra-Area-TE LSA. This is > different from OSPFv2 Traffic Engineering [TE] where opaque LSAs = are > used to advertise TE information [OPAQUE]." > which leaves me thinking that that should be a normative reference = and that > text such as > "Type 10 opaque LSAs [RFC2370] are used to carry such TE information" > needs stretching to encompass OSPFv3. Yes, we will make this a Normative Reference. Here is the suggested text for use in Section 1: "[OSPF-TE-V3] defines similar extensions to OSPFv3 [OSPFV3], it defines = a new LSA which is referred to as Intra-Area-TE LSA, to advertise TE information. [OSPF-TE-V3] uses "Traffic Engineering Extensions to OSPF" [OSPF-TE] as a base for TLV definitions and defines some new TLVs and sub-TLVs to extend TE capabilities to IPv6 networks." >=20 > Likewise, 3.3. Link ID says >=20 > " For an inter-AS link, the Link ID carried in the Link ID sub-TLV is > the remote ASBR identifier which could be any address of the remote > ASBR(e.g., the TE Router ID, Router ID or interface address of the > remote ASBR reached through this inter-AS link). The TE Router ID = is > RECOMMENDED. >=20 > whereas ospfv3-traffic says >=20 > " The Link ID sub-TLV is used in OSPFv2 to identify the other end of > the link. In OSPFv3, the Neighbor ID sub-TLV MUST be used for link > identification. In OSPFv3, The Link ID sub-TLV SHOULD NOT be sent > and MUST be ignored upon receipt. >=20 > Again, looks like the language needs stretching=20 Yes,=20 As to the Section 3.3 "Link ID", actually, using Remote ASBR ID is more suitable for an inter-AS TE link. If only for OSPF v2 TE, using Link ID = to carry the Remote ASBR ID is OK. But the remote ASBR identifier could be = an IPv4 address or an IPv6 address, using Link ID sub-TLV(OSPF-TE-v2) = ,Neighbor ID sub-TLV(OSPF-TE-v3) or other legacy sub-TLVs to carry the Remote ASBR = ID is not suitable. So, a new separate sub-TLV: Remote ASBR ID sub-TLV, is needed to carry the Remote ASBR ID, just as defined in the "ISIS = inter-AS TE extension" document. > and the reference be made normative. =20 Yes, as you suggested, the reference will be updated in the next = revision (version 02). > There may be other instances of this as well; has this been reviewed > by the authors of ospfv3-traffic? We hope to receive more comments and suggestions from the authors of ospfv3-traffic and others, and we will continue to notify the OSPF = working group of our progress. >=20 > Tom Petch >=20 Thanks again! Best regards, Mach Chen Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 23 Sep 2007 22:06:14 +0000 Message-ID: <021401c7fe2d$4bf2b850$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Four new liaisons received from ITU-T SG15 Date: Sun, 23 Sep 2007 22:48:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, ITU-T Study Group 15 Questions 12 and 14 met in Stuttgart earlier this month and generated four liaisons to us. Liaison Statement to CCAMP WG on GMPLS Signaling for VCAT/LCAS https://datatracker.ietf.org/liaison/371/ For action. Response requested by 4th February 2008 Liaison Statement to IETF CCAMP on ASON Routing Loop Prevention https://datatracker.ietf.org/liaison/370/ For action. Response requested by 19th November 2007 Liaison Statement to CCAMP on GMPLS Calls https://datatracker.ietf.org/liaison/369/ For action. Response requested by 4th February 2008 Liaison Statement to CCAMP on Multi-Layer Network I-Ds https://datatracker.ietf.org/liaison/368/ In response to our liaison. No response is required, but we need to take this as input to our Working Group last call. As always, you can track liaisons at www.olddog.co.uk/ccamp.htm Assistance in drafting responses will be much welcomed. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Sep 2007 18:41:07 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Question on RFC4873 Date: Fri, 21 Sep 2007 13:39:00 -0500 Message-ID: Thread-Topic: Question on RFC4873 Thread-Index: Acf8cvugnM9/pEXTSw6xacH8iMhtugACUDGA From: "Bardalai, Snigdho" To: "Lou Berger" Cc: , , , "Ccamp (E-mail)" Hi Lou, The text is a bit confusing... Section 4.2.4.2 has a reference to Section 4.2.3 and in this section the = Path and Resv message processing is described. Section 4.2.3 talks about message co-ordination at the branch nodes. The = described method works fine when in response to a Path message with D+R = bits set a Resv with D bit set is generated at the egress location. I = believe in order for PathErr message with the Path_State_Removed option = set it is probably necessary to have some message coordination at the = merge nodes. as well. The Path messages with D+R bits set from all = branches need to be received at the merge node before the message can be = forwarded downstream. This is required in order to ensure that the = primary and secondary (recovery) LSPs can be deleted in a graceful = manner. Thanks, Snigdho -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Lou Berger Sent: Friday, September 21, 2007 12:09 PM To: Bardalai, Snigdho Cc: lberger@labn.net; IBryskin@advaoptical.com; dimitri.papadimitriou@alcatel-lucent.be; adrian@olddog.co.uk; Ccamp (E-mail) Subject: Re: Question on RFC4873 Snigdho, see responses in-line. At 12:07 PM 9/21/2007, Bardalai, Snigdho wrote: >Hi, > >RFC3473 has specified an option that allows tearing down an LSP=20 >using the PathErr message with the Path_State_Removed option. If=20 >this option is used in combination with the ADMINSTATUS object with=20 >the D and R bits set in the Path message LSPs can be torn down in a=20 >graceful manner. > > From reading RFC4873 it seems like this option is no longer=20 > supported for the segment recovery LSPs. Section 4.2.4.2 in RFC4873=20 > requires that when a Path message with D and R bits set is=20 > received, a Resv with the D bit set MUST be sent. I don't see this. Section 4.2.4.2 only relates to path senders (aka=20 "the ingress node"). The draft doesn't limit/modify use of the=20 PathErr message with the Path_State_Removed option. (Handling of such=20 messages at the recovery LSP ingress is covered in 4.2.1.) Lou >What exactly is this addressing? From what I can see there is no=20 >strong technical reason to not support PathErr with=20 >Path_State_Removed for graceful teardown. Or is there one? > >Regards, >Snigdho Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Sep 2007 17:10:46 +0000 Date: Fri, 21 Sep 2007 13:08:52 -0400 To: "Bardalai, Snigdho" From: Lou Berger Subject: Re: Question on RFC4873 Cc: ,, ,, "Ccamp (E-mail)" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: Snigdho, see responses in-line. At 12:07 PM 9/21/2007, Bardalai, Snigdho wrote: >Hi, > >RFC3473 has specified an option that allows tearing down an LSP >using the PathErr message with the Path_State_Removed option. If >this option is used in combination with the ADMINSTATUS object with >the D and R bits set in the Path message LSPs can be torn down in a >graceful manner. > > From reading RFC4873 it seems like this option is no longer > supported for the segment recovery LSPs. Section 4.2.4.2 in RFC4873 > requires that when a Path message with D and R bits set is > received, a Resv with the D bit set MUST be sent. I don't see this. Section 4.2.4.2 only relates to path senders (aka "the ingress node"). The draft doesn't limit/modify use of the PathErr message with the Path_State_Removed option. (Handling of such messages at the recovery LSP ingress is covered in 4.2.1.) Lou >What exactly is this addressing? From what I can see there is no >strong technical reason to not support PathErr with >Path_State_Removed for graceful teardown. Or is there one? > >Regards, >Snigdho Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Sep 2007 16:09:42 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7FC69.8B9368CC" Subject: Question on RFC4873 Date: Fri, 21 Sep 2007 11:07:44 -0500 Message-ID: Thread-Topic: Question on RFC4873 Thread-Index: Acf8aYstCGco52T/R/Suhcydzie+2A== From: "Bardalai, Snigdho" To: , , , Cc: "Ccamp (E-mail)" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7FC69.8B9368CC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, RFC3473 has specified an option that allows tearing down an LSP using = the PathErr message with the Path_State_Removed option. If this option = is used in combination with the ADMINSTATUS object with the D and R bits = set in the Path message LSPs can be torn down in a graceful manner. >From reading RFC4873 it seems like this option is no longer supported = for the segment recovery LSPs. Section 4.2.4.2 in RFC4873 requires that = when a Path message with D and R bits set is received, a Resv with the D = bit set MUST be sent.=20 What exactly is this addressing? From what I can see there is no strong = technical reason to not support PathErr with Path_State_Removed for = graceful teardown. Or is there one? Regards, Snigdho ------_=_NextPart_001_01C7FC69.8B9368CC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Question on RFC4873

    Hi,

    RFC3473 has specified an option that = allows tearing down an LSP using the PathErr message with the = Path_State_Removed option. If this option is used in combination with = the ADMINSTATUS object with the D and R bits set in the Path message = LSPs can be torn down in a graceful manner.

    From reading RFC4873 it seems like this = option is no longer supported for the segment recovery LSPs. Section = 4.2.4.2 in RFC4873 requires that when a Path message with D and R bits = set is received, a Resv with the D bit set MUST be sent.

    What exactly is this addressing? From = what I can see there is no strong technical reason to not support = PathErr with Path_State_Removed for graceful teardown. Or is there = one?

    Regards,
    Snigdho

    ------_=_NextPart_001_01C7FC69.8B9368CC-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Sep 2007 18:10:28 +0000 Message-ID: <005201c7fba7$d0c79740$0601a8c0@pc6> Reply-To: "tom.petch" From: "tom.petch" To: "Mach Chen" Cc: Subject: Re: [mpls] Ask for comments on "IGP extension in support of inter-AS"drafts Date: Thu, 20 Sep 2007 18:35:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit A minor editorial on draft-ietf-ccamp-ospf-interas-te-extension-01.txt. Since 3.2 says "The value of the Link Type for an inter-AS point-to-point link is 3. The use of multi-access inter-AS TE links is for future study" I think that s6. IANA Considerations should also be specific to point-to-point and not just " 3 Inter-AS link " And a more substantive issue. The I-D claims to be OSPF version agnostic but, as draft-ietf-ospf-ospfv3-traffic-08.txt (cited as an Informative Reference only) says "A new LS type is defined for the Intra-Area-TE LSA. This is different from OSPFv2 Traffic Engineering [TE] where opaque LSAs are used to advertise TE information [OPAQUE]." which leaves me thinking that that should be a normative reference and that text such as "Type 10 opaque LSAs [RFC2370] are used to carry such TE information" needs stretching to encompass OSPFv3. Likewise, 3.3. Link ID says " For an inter-AS link, the Link ID carried in the Link ID sub-TLV is the remote ASBR identifier which could be any address of the remote ASBR(e.g., the TE Router ID, Router ID or interface address of the remote ASBR reached through this inter-AS link). The TE Router ID is RECOMMENDED. whereas ospfv3-traffic says " The Link ID sub-TLV is used in OSPFv2 to identify the other end of the link. In OSPFv3, the Neighbor ID sub-TLV MUST be used for link identification. In OSPFv3, The Link ID sub-TLV SHOULD NOT be sent and MUST be ignored upon receipt. Again, looks like the language needs stretching and the reference be made normative. There may be other instances of this as well; has this been reviewed by the authors of ospfv3-traffic? Tom Petch ----- Original Message ----- From: "Mach Chen" To: Sent: Friday, September 07, 2007 12:22 PM Subject: [mpls] Ask for comments on "IGP extension in support of inter-AS"drafts > Hi MPLSers, > > Here are two I-Ds which describe extensions to the OSPF Traffic Engineering > (OSPF-TE) and ISIS Traffic Engineering (ISIS-TE) mechanisms to support > (G)MPLS Traffic Engineering for multiple Autonomous Systems (ASes), > respectively. They define OSPF-TE and ISIS-TE extensions for the flooding of > TE information about inter-AS TE links which can be used to perform inter-AS > TE path computation. > > You could reach them by the following links: > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas-te-extension-0 1.txt > > http://www.ietf.org/internet-drafts/draft-chen-ccamp-isis-interas-te-extension-0 1.txt > > I'd like to ask you to comment on the CCAMP list, thanks! > > Best regards, > > Mach Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Sep 2007 17:12:55 +0000 Message-ID: <46F00655.9080803@grotto-networking.com> Date: Tue, 18 Sep 2007 10:09:41 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ccamp , pce@ietf.org Subject: Wavelength Switched Optical Networks -- revised draft available Content-Type: multipart/alternative; boundary="------------090308000305090504020604" This is a multi-part message in MIME format. --------------090308000305090504020604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello fellow, CCAMPers and PCEers, a revised draft on wavelength switched optical networks entitled: "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks" is now available at: http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-01.txt The intention is to have this document adopted as a working group draft at either CCAMP or PCE and use it to guide the various "solution" drafts that are being generated with respect to wavelength switched optical networks. *Abstract: * This memo provides a framework for applying Generalized Multi- Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of wavelength switched optical networks (WSON). In particular we provide control plane models for key wavelength switched optical network subsystems and processes. The subsystems include wavelength division multiplexed links, tunable laser transmitters, reconfigurable optical add/drop multiplexers (ROADM) and wavelength converters. Lightpath provisioning, in general, requires the routing and wavelength assignment (RWA) process. This process is reviewed and the information requirements, both static and dynamic for this process are presented, along with alternative implementation scenarios that could be realized via GMPLS/PCE and/or extended GMPLS/PCE protocols. This memo does NOT address optical impairments in any depth and focuses on topological elements and path selection constraints that are common across different WSON environments. It is expected that a variety of different techniques will be applied to optical impairments depending on the type of WSON, such as access, metro or long haul. Regards Greg B, Young L. and Wataru I. -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------090308000305090504020604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello fellow, CCAMPers and PCEers,
    a revised draft on wavelength switched optical networks entitled: "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks" is now available at: http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-01.txt

    The intention is to have this document adopted as a working group draft at either CCAMP or PCE and use it to guide the various "solution" drafts that are being generated with respect to wavelength switched optical networks.

    Abstract:
    This memo provides a framework for applying Generalized Multi- Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of wavelength switched optical networks (WSON). In particular we provide control plane models for key wavelength switched optical network subsystems and processes. The subsystems include wavelength division multiplexed links, tunable laser transmitters, reconfigurable optical add/drop multiplexers (ROADM) and wavelength converters. Lightpath provisioning, in general, requires the routing and wavelength assignment (RWA) process. This process is reviewed and the information requirements, both static and dynamic for this process are presented, along with alternative implementation scenarios that could be realized via GMPLS/PCE and/or extended GMPLS/PCE protocols. This memo does NOT address optical impairments in any depth and focuses on topological elements and path selection constraints that are common across different WSON environments. It is expected that a variety of different techniques will be applied to optical impairments depending on the type of WSON, such as access, metro or long haul.

    Regards

    Greg B, Young L. and Wataru I.
    -- 
    ===================================================
    Dr Greg Bernstein, Grotto Networking (510) 573-2237
    
    
    --------------090308000305090504020604-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Sep 2007 15:17:40 +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-inter-domain-recovery-analysis-02.txt Message-Id: Date: Thu, 13 Sep 2007 11:15:02 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Analysis of Inter-domain Label Switched Path (LSP) Recovery Author(s) : T. Takeda, et al. Filename : draft-ietf-ccamp-inter-domain-recovery-analysis-02.txt Pages : 23 Date : 2007-9-13 This document analyzes various schemes to realize Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Path (LSP) recovery in multi-domain networks based on the existing framework for multi-domain LSPs. The main focus for this document is on establishing end-to-end diverse Traffic Engineering (TE) LSPs in multi-domain networks. It presents various diverse LSP setup schemes based on existing functional elements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-02.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-inter-domain-recovery-analysis-02.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-inter-domain-recovery-analysis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-9-13103312.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-inter-domain-recovery-analysis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-9-13103312.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Sep 2007 05:57:17 +0000 Message-ID: <46E77F28.4030702@pi.se> Date: Wed, 12 Sep 2007 07:54:48 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Adrian Farrel CC: PAPADIMITRIOU Dimitri , "Zafar Ali (zali)" , "Attila Takacs (IJ/ETH)" , ccamp@ops.ietf.org, gels , Ross Callon Subject: Re: Closing the GELS Mailing List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Adrian Farrel wrote: > I think this thread is a representation in miniature of the issues > involved... > > - All the emails in this thread have been copied to both mailing lists > - All the participants in the thread are subscribed to both mailing lists > > No, it doesn't cost to have both lists active. well - it does for me, since the gels-list is not on one of the ietf-servers, and tends to be hit by quite a bit of spam and the IETF spam filters can't be applied; I have to sift through quite a bit of debris, floatsam and junk to try to find any nuggets in the stream if I've to do that for things that the wg chairs say could go to the ccamp list anyway I'd rather do something else. Adrian, when can I close the list? /Loa > No, it doesn't cost to have all of the threads on CCAMP. > > Please note that we should not discuss the data plane. If you don't > understand (or don't like, or don't want to use) the data plane you > should have your discussions in private or at the IEEE. > > Dimitri said... > >>> - Label allocation and swapping rules >> is that not a forwarding component discussion ? > > It is certainly informed by the forwarding component (i.e. the > definition of the data plane), but the rules we need to define are the > rules for the control plane. I.e. (and for example, only) if the > forwarding plane defines that the label allocated on the upstream > interface must be numerically one greater than the label allocated on > the downstream interface, this rule must be referenced in the control > plane specification. This is important since it is a constraint placed > on the normal per-interface operation of GMPLS. That makes it CCAMP work. > >> beside the fact that there is an assumption on what >> label means and how it is represented in data plane > > This is also something we would expect to describe within CCAMP although > "what is a label" would come to us from the data plane specification. > > Thanks, > Adrian > > > > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Sep 2007 12:42:04 +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: Closing the GELS Mailing List Date: Mon, 10 Sep 2007 13:40:01 +0100 Message-ID: Thread-Topic: Closing the GELS Mailing List Thread-Index: AcfyHT6Fns26LJYEQlGdFkPBvk9UrAAAJN+wAGI6+4A= From: To: , , , , , , , Cc: Colleagues, It would appear to me that we are going around in circles and that they are basically the same circles that we have gone around before. This would incorrectly imply that we have gone nowhere. IMO the path is quite simple and outlined in Adrian's e-mail dated 5th September. The design team produce documents (1) & (2) ("GMPLS Extensions for PE to PE Ethernet Label Switched Paths(LSPs)" & "GMPLS control of P2P TE for PBB-TE (802.1Qay)"). The second document describes our understanding of the 802.1Qay data plane including swapping rules. We liaise these to IEEE and if we got them (i.e. our understanding of the data plane) right then we can go ahead and define the data plane specific control protocol machinery. If we didn't quite get them right IEEE tell us and we adjust the documents accordingly. So let's wait & see what the design team create & what the IEEE reaction to those documents is. Ben owner-ccamp@ops.ietf.org <> wrote: > igor >=20 >> The conclusions in the context of co Ethernet: >>=20 >> a) Data plane label is something determined only by >> IEEE, because it exists independently from any Control Plane: >> Ethernet connections could be configured by NMS without any Control >> Plane (no control plane labels at all). As far as CCAMP is concerned, >> data plane label is untouchable; >=20 >=20 > IEEE 802.1 does not deal with the data plane in that sense. > it defines "control" of forwarding components it is an issue > we need to consider. >=20 > we are not taking a data plane specification in its basic > sense for which CCAMP adds a control plane. to the modes > 802.1 currently considers MSTP (domain-wide bridging through > spanning tree), SPB (shortest-path tree bridging) and PBB-TE > (for which we have no outline so far) result in specification > detailing operations of forwarding components. >=20 > if i take the latter its is intended to "support provisioning > systems that explicitly select traffic engineered paths > within Provider Backbone Bridge Networks (P802.1ah) by > allowing a network operator to disable unknown destination > address forwarding and source address learning for > administratively selected VLAN Identifiers, while allowing > other network control protocols to dynamically determine > active topologies for other services." ... far from being a > data plane specification in its base sense. >=20 >=20 >> b) Control plane label is always a subset of data >> plane and is an essential subject of CCAMP discussions: is it >> DMAC/VID? just VID? nothing as in case of statically configured >> connections? Is it network-scope? node-scope? >> link-scope? Stuff like that. >=20 >=20 > i will use examples to make this clearer to allow something along the > PBB-TE line work is ongoing to define states which force the > port state > being learning off and forwarding on (for all VID allocated to PBB-TE > but not to MSTP), disable broadcast/unknown unicast while allowing > filtering of unicast only (both are control of MAC relay operations), > etc. -> all these control-driven operation fall outside CCAMP > scope (at > least as far as my understanding goes) >=20 >=20 > -> the question is not "IEEE defines the data plane and IETF > the control > plane" >=20 >=20 > =3D> the question is which control components can CCAMP consider that > complements amended 802.1ah bridge control & operation: data path > setup/provisioning mechanism (explicit source-initiated routing) ? > traffic engineering which first requires to see which TE > model IEEE will > consider ? others ? >=20 >=20 >=20 > -d. >> -----Original Message----- >> From: Igor Bryskin [mailto:i_bryskin@yahoo.com] >> Sent: Saturday, September 08, 2007 3:36 PM >> To: PAPADIMITRIOU Dimitri; neil.2.harrison@bt.com; >> adrian@olddog.co.uk; zali@cisco.com; >> Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org >> Cc: rcallon@juniper.net Subject: RE: Closing the GELS Mailing List >>=20 >> Dimitri, >>=20 >> As Neil correctly pointed out, there is a great >> advantage in having connection source ID within label of >> every packet forwarded over the connection (and MPLS's great >> deficiency is the lack of LSP source ID in the MPLS label). >> The source ID must be within the (data plane) label and not >> anywhere else, because the label constitutes Layer >> Information (LI) in ITU terms, and only LI is accessible to a >> server layer that claims transparency for its clients. On the >> other hand source MA in co Ethernet is not used for packet >> forwarding, hence it should not be signaled as a part of the >> (control plane) label, which is information that must be put >> by an upstream node into the packet header, so that the >> downstream node could recognize and properly forward the packet. >>=20 >> The conclusions in the context of co Ethernet: >>=20 >> a) Data plane label is something determined only by >> IEEE, because it exists independently from any Control Plane: >> Ethernet connections could be configured by NMS without any >> Control Plane (no control plane labels at all). As far as >> CCAMP is concerned, data plane label is untouchable; >> b) Control plane label is always a subset of data >> plane and is an essential subject of CCAMP discussions: is it >> DMAC/VID? just VID? nothing as in case of statically >> configured connections? Is it network-scope? node-scope? link-scope? >> Stuff like that.=20 >>=20 >> Cheers, >> Igor >>=20 >>=20 >>=20 >>=20 >> > So, IMO IEEE should be responsible for the definition of data >> > plane labels, while CCAMP for control plane labels. >>=20 >> a label distribution protocol is a set of procedures by >> which one node >> informs another of the label/FEC bindings it has made >>=20 >> if these labels are distributed via the gmpls control >> plane driving >> population of the LIBs to which difference are u >> pointing out here ? so, >> not sure to see the point (whatever the number of >> levels of indirection >> between the fwd'ing plane encoding and control plane >> encoding u will >> always fall back on the former, the label distribution protocol >> exchanges a piece of information used by the nodes to >> perform their >> forwarding decision) >>=20 >> -d. >>=20 >> > -----Original Message----- >> > From: Igor Bryskin [mailto:i_bryskin@yahoo.com] >> > Sent: Friday, September 07, 2007 9:21 PM >> > To: neil.2.harrison@bt.com; PAPADIMITRIOU Dimitri; >> > adrian@olddog.co.uk; zali@cisco.com; >> > Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; >> gels@rtg.ietf.org >> > Cc: rcallon@juniper.net >> > Subject: RE: Closing the GELS Mailing List >> > >> > Hi Neil, >> > >> > I think there is a difference between a "data plane label" >> > which is a Layer Information (LI) used by a given server >> > layer and a "control plane label", which is a piece of >> > information signaled between adjacent controllers for the >> > purpose of connection provisioning. IMO the former is always >> > a superset of the latter. Let's take, for instance, >> > connection oriented Ethernet. MAC SA is a very important part >> > of the data plane label because it identifies the source of >> > the connection. However, the connection frames are forwarded >> > according to MAC DA/VID, and hence connection ingress node, >> > for example, needs only be signaled with this tuple by the >> > downstream neighbor, hence the control plane label is MAC >> > DA/VID (or just VID, for those who like the idea of the VID >> > cross-connects architecture). >> > >> > So, IMO IEEE should be responsible for the definition of data >> > plane labels, while CCAMP for control plane labels. > >> > Cheers, >> > Igor >> > >> > >> > neil.2.harrison@bt.com wrote: >> > >> > Dimitri wrote 07 September 2007 16:36 in response to Adrian > >> > > > >> > > > This is also something we would expect to describe within > >> > > CCAMP although > > > "what is a label" would come to us from >> the data plane > > specification. > > >> > > do i interpreet correctly your statement that if the >> > > specification that CCAMP is going to receive from IEEE does >> > > not speak about "label" and its encoding there will be no >> > > place to discuss any "label processing" and "label >> > > distribution" protocol in IETF - being domain-wide or > >> link-local > > - >> > > >> > > in that case, isn't the .1Q specification outside scope of >> > > this effort since not referring - as of today at least - to >> > > any "label" semantic as part of the Ethernet frame header > > >> information field ? > > >> > > thanks, >> > > -d. >> > >> > What do you think a MAC DA, MAC SA and VID are? These > are all >> 'labels'. > >> > You also have to remember that the nature of the labels > >> required in a > traffic unit are determined by the type of the >> network > mode one is > dealing with. >> > >> > In the co-cs and co-ps modes we have a construction known as a >> > 'connection'. This implies specific architectural > >> requirements....but > the most significant, for this discussion at >> least, is > that a connection > must have a single source. What >> this means is that one > does not have to > incorporate a SA label >> in a co mode traffic > unit....under defect-free >> > conditions it is redundant information as the >> > connection itself provides >> > the source information. {Compare this to the cl-ps mode > which >> does not > have connections...here having a SA in the traffic unit >> > is essential} > >> > Ergo why co-cs and co-ps mode technologies to date that > >> respect the > requirements of a connection have only focussed on > >> incorporating a DA > (forwarding) label. Further, these forwarding >> labels > only need to be > distinct in resolving some number (N >> say) of different > client layer > (link-connection) instances >> within a server layer > (network connection) > resource partition. >> However, there are advantages from > having both a SA > and DA >> label in a co-ps traffic unit that are network > unique and not > >> just link-connection unique (ie not swapped)....the > inherent >> robustness > under misconnectivity defects (without any adjunct OAM >> > flow) is one of > these. And of course, these are the nature of >> the > native labels one > already gets in Ethernet due to its >> cl-ps mode origins. > So why would > one even contemplate not >> using these since they are > already there? > > The VID label is >> slightly different in that one can > consider it as a > 'route >> discriminator label' and a local extension to > the SA or DA, ie >> it > provides the ability to identify disjoint paths between > >> nodal end > points. > >> > The mere fact IEEE may not refer to the above >> > quantities as 'labels' >> > does not change the fact that this is what they are. So > I'm >> not clear > what your real point is here. >> > >> > regards, Neil >> > >> > >> > >> > >> > ________________________________ >> > >> > Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge >> > > ions/222> to see what's on, when. >> > >>=20 >>=20 >>=20 >>=20 >> ________________________________ >>=20 >> Ready for the edge of your seat? Check out tonight's top >> picks >> on >> Yahoo! TV. Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 09 Sep 2007 15:16:21 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=ZlTo74nB5RW2M5XHWYnXReoM5XcQupF4W1OBiW6h6Xwl7f6p89ZFqFUBD3Q5QBV+VcfHJLGiyPP8IVr3tCjbGuoV76Bp/jX/L4in1veQ1MuIOfvuSDzCbdt/s48QwVbL2Of9fcyU/8b0YwGloMTOrzm5p6Ffy7NvKeyeBgTafYQ=; Date: Sun, 9 Sep 2007 08:12:57 -0700 (PDT) From: Igor Bryskin Subject: RE: Closing the GELS Mailing List To: PAPADIMITRIOU Dimitri , neil.2.harrison@bt.com, adrian@olddog.co.uk, zali@cisco.com, Attila.Takacs@ericsson.com, ccamp@ops.ietf.org, gels@rtg.ietf.org Cc: rcallon@juniper.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1831663776-1189350777=:55044" Content-Transfer-Encoding: 8bit Message-ID: <790583.55044.qm@web36809.mail.mud.yahoo.com> --0-1831663776-1189350777=:55044 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dimitri, Please, see in line. Igor PAPADIMITRIOU Dimitri wrote: igor > The conclusions in the context of co Ethernet: > > a) Data plane label is something determined only by > IEEE, because it exists independently from any Control Plane: > Ethernet connections could be configured by NMS without any > Control Plane (no control plane labels at all). As far as > CCAMP is concerned, data plane label is untouchable; IEEE 802.1 does not deal with the data plane in that sense. it defines "control" of forwarding components it is an issue we need to consider. we are not taking a data plane specification in its basic sense for which CCAMP adds a control plane. IB>> I totally disagree. That is exactly what we should do in CCAMP and my understanding is that this is what operators expect us to do. to the modes 802.1 currently considers MSTP (domain-wide bridging through spanning tree), SPB (shortest-path tree bridging) and PBB-TE (for which we have no outline so far) result in specification detailing operations of forwarding components. if i take the latter its is intended to "support provisioning systems that explicitly select traffic engineered paths within Provider Backbone Bridge Networks (P802.1ah) by allowing a network operator to disable unknown destination address forwarding and source address learning for administratively selected VLAN Identifiers, while allowing other network control protocols to dynamically determine active topologies for other services." ... far from being a data plane specification in its base sense. > b) Control plane label is always a subset of data > plane and is an essential subject of CCAMP discussions: is it > DMAC/VID? just VID? nothing as in case of statically > configured connections? Is it network-scope? node-scope? > link-scope? Stuff like that. i will use examples to make this clearer to allow something along the PBB-TE line work is ongoing to define states which force the port state being learning off and forwarding on (for all VID allocated to PBB-TE but not to MSTP), disable broadcast/unknown unicast while allowing filtering of unicast only (both are control of MAC relay operations), etc. -> all these control-driven operation fall outside CCAMP scope (at least as far as my understanding goes) IB>> Again, this is exactly opposite to my understanding. IMO we should consider only connection-oriented Ethernet, such as 802.1ay for PBB-TE or, say, 802.1xyz for VID cross-connected Ethernet (only after such data plane is endorsed by IEEE). We should not consider any connectionless Ethernet (802.1ad,ah, etc.).: GMPLS so far is/was all about connections and nothing else: to correct deficiencies of connectionless Ethernet native control plane ((R,M)STPs) in CCAMP IMO is as inappropriate as correcting deficiencies of MPLS in ITU (I mean designing T-MPLS) Cheers, Igor -> the question is not "IEEE defines the data plane and IETF the control plane" => the question is which control components can CCAMP consider that complements amended 802.1ah bridge control & operation: data path setup/provisioning mechanism (explicit source-initiated routing) ? traffic engineering which first requires to see which TE model IEEE will consider ? others ? -d. > -----Original Message----- > From: Igor Bryskin [mailto:i_bryskin@yahoo.com] > Sent: Saturday, September 08, 2007 3:36 PM > To: PAPADIMITRIOU Dimitri; neil.2.harrison@bt.com; > adrian@olddog.co.uk; zali@cisco.com; > Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org > Cc: rcallon@juniper.net > Subject: RE: Closing the GELS Mailing List > > Dimitri, > > As Neil correctly pointed out, there is a great > advantage in having connection source ID within label of > every packet forwarded over the connection (and MPLS's great > deficiency is the lack of LSP source ID in the MPLS label). > The source ID must be within the (data plane) label and not > anywhere else, because the label constitutes Layer > Information (LI) in ITU terms, and only LI is accessible to a > server layer that claims transparency for its clients. On the > other hand source MA in co Ethernet is not used for packet > forwarding, hence it should not be signaled as a part of the > (control plane) label, which is information that must be put > by an upstream node into the packet header, so that the > downstream node could recognize and properly forward the packet. > > The conclusions in the context of co Ethernet: > > a) Data plane label is something determined only by > IEEE, because it exists independently from any Control Plane: > Ethernet connections could be configured by NMS without any > Control Plane (no control plane labels at all). As far as > CCAMP is concerned, data plane label is untouchable; > b) Control plane label is always a subset of data > plane and is an essential subject of CCAMP discussions: is it > DMAC/VID? just VID? nothing as in case of statically > configured connections? Is it network-scope? node-scope? > link-scope? Stuff like that. > > Cheers, > Igor > > > > > > So, IMO IEEE should be responsible for the definition of data > > plane labels, while CCAMP for control plane labels. > > a label distribution protocol is a set of procedures by > which one node > informs another of the label/FEC bindings it has made > > if these labels are distributed via the gmpls control > plane driving > population of the LIBs to which difference are u > pointing out here ? so, > not sure to see the point (whatever the number of > levels of indirection > between the fwd'ing plane encoding and control plane > encoding u will > always fall back on the former, the label distribution protocol > exchanges a piece of information used by the nodes to > perform their > forwarding decision) > > -d. > > > -----Original Message----- > > From: Igor Bryskin [mailto:i_bryskin@yahoo.com] > > Sent: Friday, September 07, 2007 9:21 PM > > To: neil.2.harrison@bt.com; PAPADIMITRIOU Dimitri; > > adrian@olddog.co.uk; zali@cisco.com; > > Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; > gels@rtg.ietf.org > > Cc: rcallon@juniper.net > > Subject: RE: Closing the GELS Mailing List > > > > Hi Neil, > > > > I think there is a difference between a "data plane label" > > which is a Layer Information (LI) used by a given server > > layer and a "control plane label", which is a piece of > > information signaled between adjacent controllers for the > > purpose of connection provisioning. IMO the former is always > > a superset of the latter. Let's take, for instance, > > connection oriented Ethernet. MAC SA is a very important part > > of the data plane label because it identifies the source of > > the connection. However, the connection frames are forwarded > > according to MAC DA/VID, and hence connection ingress node, > > for example, needs only be signaled with this tuple by the > > downstream neighbor, hence the control plane label is MAC > > DA/VID (or just VID, for those who like the idea of the VID > > cross-connects architecture). > > > > So, IMO IEEE should be responsible for the definition of data > > plane labels, while CCAMP for control plane labels. > > > > Cheers, > > Igor > > > > > > neil.2.harrison@bt.com wrote: > > > > Dimitri wrote 07 September 2007 16:36 in response to Adrian > > > > > > > > > > This is also something we would expect to describe within > > > > CCAMP although > > > > "what is a label" would come to us from the data plane > > > specification. > > > > > > do i interpreet correctly your statement that if the > > > specification that CCAMP is going to receive from IEEE does > > > not speak about "label" and its encoding there will be no > > > place to discuss any "label processing" and "label > > > distribution" protocol in IETF - being domain-wide or > > link-local > > > - > > > > > > in that case, isn't the .1Q specification outside scope of > > > this effort since not referring - as of today at least - to > > > any "label" semantic as part of the Ethernet frame header > > > information field ? > > > > > > thanks, > > > -d. > > > > What do you think a MAC DA, MAC SA and VID are? These > > are all 'labels'. > > > > You also have to remember that the nature of the labels > > required in a > > traffic unit are determined by the type of the network > > mode one is > > dealing with. > > > > In the co-cs and co-ps modes we have a construction known as a > > 'connection'. This implies specific architectural > > requirements....but > > the most significant, for this discussion at least, is > > that a connection > > must have a single source. What this means is that one > > does not have to > > incorporate a SA label in a co mode traffic > > unit....under defect-free > > conditions it is redundant information as the > > connection itself provides > > the source information. {Compare this to the cl-ps mode > > which does not > > have connections...here having a SA in the traffic unit > > is essential} > > > > Ergo why co-cs and co-ps mode technologies to date that > > respect the > > requirements of a connection have only focussed on > > incorporating a DA > > (forwarding) label. Further, these forwarding labels > > only need to be > > distinct in resolving some number (N say) of different > > client layer > > (link-connection) instances within a server layer > > (network connection) > > resource partition. However, there are advantages from > > having both a SA > > and DA label in a co-ps traffic unit that are network > > unique and not > > just link-connection unique (ie not swapped)....the > > inherent robustness > > under misconnectivity defects (without any adjunct OAM > > flow) is one of > > these. And of course, these are the nature of the > > native labels one > > already gets in Ethernet due to its cl-ps mode origins. > > So why would > > one even contemplate not using these since they are > > already there? > > > > The VID label is slightly different in that one can > > consider it as a > > 'route discriminator label' and a local extension to > > the SA or DA, ie it > > provides the ability to identify disjoint paths between > > nodal end > > points. > > > > The mere fact IEEE may not refer to the above > > quantities as 'labels' > > does not change the fact that this is what they are. So > > I'm not clear > > what your real point is here. > > > > regards, Neil > > > > > > > > > > ________________________________ > > > > Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge > > > ions/222> to see what's on, when. > > > > > > > ________________________________ > > Ready for the edge of your seat? Check out tonight's top > picks > on > Yahoo! TV. > --------------------------------- Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. --0-1831663776-1189350777=:55044 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
    Dimitri,
     
    Please, see in line.
     
    Igor

    PAPADIMITRIOU Dimitri <Dimitri.Papadimitriou@alcatel-lucent.be> wrote:
    igor

    > The conclusions in the context of co Ethernet:
    >
    > a) Data plane label is something determined only by
    > IEEE, because it exists independently from any Control Plane:
    > Ethernet connections could be configured by NMS without any
    > Control Plane (no control plane labels at all). As far as
    > CCAMP is concerned, data plane label is untouchable;


    IEEE 802.1 does not deal with the data plane in that sense. it defines
    "control" of forwarding components it is an issue we need to consider.

    we are not taking a data plane specification in its basic sense for
    which CCAMP adds a control plane.
     
    IB>>  I totally disagree. That is exactly what we should do in CCAMP and my understanding is that this is what operators expect us to do.
     
     to the modes 802.1 currently considers
    MSTP (domain-wide bridging through spanning tree), SPB (shortest-path
    tree bridging) and PBB-TE (for which we have no outline so far) result
    in specification detailing operations of forwarding components.

    if i take the latter its is intended to "support provisioning systems
    that explicitly select traffic engineered paths within Provider Backbone
    Bridge Networks (P802.1ah) by allowing a network operator to disable
    unknown destination address forwarding and source address learning for
    administratively selected VLAN Identifiers, while allowing other network
    control protocols to dynamically determine active topologies for other
    services." ... far from being a data plane specification in its base
    sense.


    > b) Control plane label is always a subset of data
    > plane and is an essential subject of CCAMP discussions: is it
    > DMAC/VID? just VID? nothing as in case of statically
    > configured connections? Is it network-scope? node-scope?
    > link-scope? Stuff like that.


    i will use examples to make this clearer to allow something along the
    PBB-TE line work is ongoing to define states which force the port state
    being learning off and forwarding on (for all VID allocated to PBB-TE
    but not to MSTP), disable broadcast/unknown unicast while allowing
    filtering of unicast only (both are control of MAC relay operations),
    etc. -> all these control-driven operation fall outside CCAMP scope (at
    least as far as my understanding goes)
     
    IB>> Again, this is exactly opposite to my understanding. IMO we should consider only connection-oriented Ethernet, such as 802.1ay for PBB-TE or, say, 802.1xyz for VID cross-connected Ethernet (only after such data plane is endorsed by IEEE). We should not consider any connectionless Ethernet (802.1ad,ah, etc.).: GMPLS so far  is/was all about connections and nothing else: to correct deficiencies of connectionless Ethernet native control plane ((R,M)STPs) in CCAMP IMO is as inappropriate as correcting deficiencies of MPLS in ITU (I mean designing T-MPLS)
     
    Cheers,
    Igor  


    -> the question is not "IEEE defines the data plane and IETF the control
    plane"


    => the question is which control components can CCAMP consider that
    complements amended 802.1ah bridge control & operation: data path
    setup/provisioning mechanism (explicit source-initiated routing) ?
    traffic engineering which first requires to see which TE model IEEE will
    consider ? others ?



    -d.
    > -----Original Message-----
    > From: Igor Bryskin [mailto:i_bryskin@yahoo.com]
    > Sent: Saturday, September 08, 2007 3:36 PM
    > To: PAPADIMITRIOU Dimitri; neil.2.harrison@bt.com;
    > adrian@olddog.co.uk; zali@cisco.com;
    > Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org
    > Cc: rcallon@juniper.net
    > Subject: RE: Closing the GELS Mailing List
    >
    > Dimitri,
    >
    > As Neil correctly pointed out, there is a great
    > advantage in having connection source ID within label of
    > every packet forwarded over the connection (and MPLS's great
    > deficiency is the lack of LSP source ID in the MPLS label).
    > The source ID must be within the (data plane) label and not
    > anywhere else, because the label constitutes Layer
    > Information (LI) in ITU terms, and only LI is accessible to a
    > server layer that claims transparency for its clients. On the
    > other hand source MA in co Ethernet is not used for packet
    > forwarding, hence it should not be signaled as a part of the
    > (control plane) label, which is information that must be put
    > by an upstream node into the packet header, so that the
    > downstream node could recognize and properly forward the packet.
    >
    > The conclusions in the context of co Ethernet:
    >
    > a) Data plane label is something determined only by
    > IEEE, because it exists independently from any Control Plane:
    > Ethernet connections could be configured by NMS without any
    > Control Plane (no control plane labels at all). As far as
    > CCAMP is concerned, data plane label is untouchable;
    > b) Control plane label is always a subset of data
    > plane and is an essential subject of CCAMP discussions: is it
    > DMAC/VID? just VID? nothing as in case of statically
    > configured connections? Is it network-scope? node-scope?
    > link-scope? Stuff like that.
    >
    > Cheers,
    > Igor
    >
    >
    >
    >
    > > So, IMO IEEE should be responsible for the definition of data
    > > plane labels, while CCAMP for control plane labels.
    >
    > a label distribution protocol is a set of procedures by
    > which one node
    > informs another of the label/FEC bindings it has made
    >
    > if these labels are distributed via the gmpls control
    > plane driving
    > population of the LIBs to which difference are u
    > pointing out here ? so,
    > not sure to see the point (whatever the number of
    > levels of indirection
    > between the fwd'ing plane encoding and control plane
    > encoding u will
    > always fall back on the former, the label distribution protocol
    > exchanges a piece of information used by the nodes to
    > perform their
    > forwarding decision)
    >
    > -d.
    >
    > > -----Original Message-----
    > > From: Igor Bryskin [mailto:i_bryskin@yahoo.com]
    > > Sent: Friday, September 07, 2007 9:21 PM
    > > To: neil.2.harrison@bt.com; PAPADIMITRIOU Dimitri;
    > > adrian@olddog.co.uk; zali@cisco.com;
    > > Attila.Takacs@ericsson.com; ccamp@ops.ietf.org;
    > gels@rtg.ietf.org
    > > Cc: rcallon@juniper.net
    > > Subject: RE: Closing the GELS Mailing List
    > >
    > > Hi Neil,
    > >
    > > I think there is a difference between a "data plane label"
    > > which is a Layer Information (LI) used by a given server
    > > layer and a "control plane label", which is a piece of
    > > information signaled between adjacent controllers for the
    > > purpose of connection provisioning. IMO the former is always
    > > a superset of the latter. Let's take, for instance,
    > > connection oriented Ethernet. MAC SA is a very important part
    > > of the data plane label because it identifies the source of
    > > the connection. However, the connection frames are forwarded
    > > according to MAC DA/VID, and hence connection ingress node,
    > > for example, needs only be signaled with this tuple by the
    > > downstream neighbor, hence the control plane label is MAC
    > > DA/VID (or just VID, for those who like the idea of the VID
    > > cross-connects architecture).
    > >
    > > So, IMO IEEE should be responsible for the definition of data
    > > plane labels, while CCAMP for control plane labels.
    > >
    > > Cheers,
    > > Igor
    > >
    > >
    > > neil.2.harrison@bt.com wrote:
    > >
    > > Dimitri wrote 07 September 2007 16:36 in response to Adrian
    > >
    > > > >
    > > > > This is also something we would expect to describe within
    > > > > CCAMP although
    > > > > "what is a label" would come to us from the data plane
    > > > specification.
    > > >
    > > > do i interpreet correctly your statement that if the
    > > > specification that CCAMP is going to receive from IEEE does
    > > > not speak about "label" and its encoding there will be no
    > > > place to discuss any "label processing" and "label
    > > > distribution" protocol in IETF - being domain-wide or
    > > link-local
    > > > -
    > > >
    > > > in that case, isn't the .1Q specification outside scope of
    > > > this effort since not referring - as of today at least - to
    > > > any "label" semantic as part of the Ethernet frame header
    > > > information field ?
    > > >
    > > > thanks,
    > > > -d.
    > >
    > > What do you think a MAC DA, MAC SA and VID are? These
    > > are all 'labels'.
    > >
    > > You also have to remember that the nature of the labels
    > > required in a
    > > traffic unit are determined by the type of the network
    > > mode one is
    > > dealing with.
    > >
    > > In the co-cs and co-ps modes we have a construction known as a
    > > 'connection'. This implies specific architectural
    > > requirements....but
    > > the most significant, for this discussion at least, is
    > > that a connection
    > > must have a single source. What this means is that one
    > > does not have to
    > > incorporate a SA label in a co mode traffic
    > > unit....under defect-free
    > > conditions it is redundant information as the
    > > connection itself provides
    > > the source information. {Compare this to the cl-ps mode
    > > which does not
    > > have connections...here having a SA in the traffic unit
    > > is essential}
    > >
    > > Ergo why co-cs and co-ps mode technologies to date that
    > > respect the
    > > requirements of a connection have only focussed on
    > > incorporating a DA
    > > (forwarding) label. Further, these forwarding labels
    > > only need to be
    > > distinct in resolving some number (N say) of different
    > > client layer
    > > (link-connection) instances within a server layer
    > > (network connection)
    > > resource partition. However, there are advantages from
    > > having both a SA
    > > and DA label in a co-ps traffic unit that are network
    > > unique and not
    > > just link-connection unique (ie not swapped)....the
    > > inherent robustness
    > > under misconnectivity defects (without any adjunct OAM
    > > flow) is one of
    > > these. And of course, these are the nature of the
    > > native labels one
    > > already gets in Ethernet due to its cl-ps mode origins.
    > > So why would
    > > one even contemplate not using these since they are
    > > already there?
    > >
    > > The VID label is slightly different in that one can
    > > consider it as a
    > > 'route discriminator label' and a local extension to
    > > the SA or DA, ie it
    > > provides the ability to identify disjoint paths between
    > > nodal end
    > > points.
    > >
    > > The mere fact IEEE may not refer to the above
    > > quantities as 'labels'
    > > does not change the fact that this is what they are. So
    > > I'm not clear
    > > what your real point is here.
    > >
    > > regards, Neil
    > >
    > >
    > >
    > >
    > > ________________________________
    > >
    > > Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge
    > > > ions/222> to see what's on, when.
    > >
    >
    >
    >
    >
    > ________________________________
    >
    > Ready for the edge of your seat? Check out tonight's top
    > picks
    > on
    > Yahoo! TV.
    >


     


    Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. --0-1831663776-1189350777=:55044-- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 08 Sep 2007 16:40: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: Closing the GELS Mailing List Date: Sat, 8 Sep 2007 18:38:22 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E380013214BD@FRVELSMBS22.ad2.ad.alcatel.com> Thread-Topic: Closing the GELS Mailing List thread-index: AcfyHT6Fns26LJYEQlGdFkPBvk9UrAAAJN+w From: "PAPADIMITRIOU Dimitri" To: "Igor Bryskin" , , , , , , Cc: igor =20 > The conclusions in the context of co Ethernet: > =20 > a) Data plane label is something determined only by=20 > IEEE, because it exists independently from any Control Plane: > Ethernet connections could be configured by NMS without any=20 > Control Plane (no control plane labels at all). As far as=20 > CCAMP is concerned, data plane label is untouchable; IEEE 802.1 does not deal with the data plane in that sense. it defines "control" of forwarding components it is an issue we need to consider.=20 we are not taking a data plane specification in its basic sense for which CCAMP adds a control plane. to the modes 802.1 currently considers MSTP (domain-wide bridging through spanning tree), SPB (shortest-path tree bridging) and PBB-TE (for which we have no outline so far) result in specification detailing operations of forwarding components.=20 if i take the latter its is intended to "support provisioning systems that explicitly select traffic engineered paths within Provider Backbone Bridge Networks (P802.1ah) by allowing a network operator to disable unknown destination address forwarding and source address learning for administratively selected VLAN Identifiers, while allowing other network control protocols to dynamically determine active topologies for other services." ... far from being a data plane specification in its base sense. > b) Control plane label is always a subset of data=20 > plane and is an essential subject of CCAMP discussions: is it=20 > DMAC/VID? just VID? nothing as in case of statically=20 > configured connections? Is it network-scope? node-scope?=20 > link-scope? Stuff like that. i will use examples to make this clearer to allow something along the PBB-TE line work is ongoing to define states which force the port state being learning off and forwarding on (for all VID allocated to PBB-TE but not to MSTP), disable broadcast/unknown unicast while allowing filtering of unicast only (both are control of MAC relay operations), etc. -> all these control-driven operation fall outside CCAMP scope (at least as far as my understanding goes) -> the question is not "IEEE defines the data plane and IETF the control plane" =3D> the question is which control components can CCAMP consider that complements amended 802.1ah bridge control & operation: data path setup/provisioning mechanism (explicit source-initiated routing) ? traffic engineering which first requires to see which TE model IEEE will consider ? others ? =20 -d. > -----Original Message----- > From: Igor Bryskin [mailto:i_bryskin@yahoo.com]=20 > Sent: Saturday, September 08, 2007 3:36 PM > To: PAPADIMITRIOU Dimitri; neil.2.harrison@bt.com;=20 > adrian@olddog.co.uk; zali@cisco.com;=20 > Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org > Cc: rcallon@juniper.net > Subject: RE: Closing the GELS Mailing List >=20 > Dimitri, > =09 > As Neil correctly pointed out, there is a great=20 > advantage in having connection source ID within label of=20 > every packet forwarded over the connection (and MPLS's great=20 > deficiency is the lack of LSP source ID in the MPLS label).=20 > The source ID must be within the (data plane) label and not=20 > anywhere else, because the label constitutes Layer=20 > Information (LI) in ITU terms, and only LI is accessible to a=20 > server layer that claims transparency for its clients. On the=20 > other hand source MA in co Ethernet is not used for packet=20 > forwarding, hence it should not be signaled as a part of the=20 > (control plane) label, which is information that must be put=20 > by an upstream node into the packet header, so that the=20 > downstream node could recognize and properly forward the packet.=20 > =20 > The conclusions in the context of co Ethernet: > =20 > a) Data plane label is something determined only by=20 > IEEE, because it exists independently from any Control Plane:=20 > Ethernet connections could be configured by NMS without any=20 > Control Plane (no control plane labels at all). As far as=20 > CCAMP is concerned, data plane label is untouchable; > b) Control plane label is always a subset of data=20 > plane and is an essential subject of CCAMP discussions: is it=20 > DMAC/VID? just VID? nothing as in case of statically=20 > configured connections? Is it network-scope? node-scope?=20 > link-scope? Stuff like that. > =20 > Cheers, > Igor > =09 > =09 > =09 > =09 > > So, IMO IEEE should be responsible for the definition of data=20 > > plane labels, while CCAMP for control plane labels. > =09 > a label distribution protocol is a set of procedures by=20 > which one node > informs another of the label/FEC bindings it has made > =09 > if these labels are distributed via the gmpls control=20 > plane driving > population of the LIBs to which difference are u=20 > pointing out here ? so, > not sure to see the point (whatever the number of=20 > levels of indirection > between the fwd'ing plane encoding and control plane=20 > encoding u will > always fall back on the former, the label distribution protocol > exchanges a piece of information used by the nodes to=20 > perform their > forwarding decision)=20 > =09 > -d. > =09 > > -----Original Message----- > > From: Igor Bryskin [mailto:i_bryskin@yahoo.com]=20 > > Sent: Friday, September 07, 2007 9:21 PM > > To: neil.2.harrison@bt.com; PAPADIMITRIOU Dimitri;=20 > > adrian@olddog.co.uk; zali@cisco.com;=20 > > Attila.Takacs@ericsson.com; ccamp@ops.ietf.org;=20 > gels@rtg.ietf.org > > Cc: rcallon@juniper.net > > Subject: RE: Closing the GELS Mailing List > >=20 > > Hi Neil, > >=20 > > I think there is a difference between a "data plane label"=20 > > which is a Layer Information (LI) used by a given server=20 > > layer and a "control plane label", which is a piece of=20 > > information signaled between adjacent controllers for the=20 > > purpose of connection provisioning. IMO the former is always=20 > > a superset of the latter. Let's take, for instance,=20 > > connection oriented Ethernet. MAC SA is a very important part=20 > > of the data plane label because it identifies the source of=20 > > the connection. However, the connection frames are forwarded=20 > > according to MAC DA/VID, and hence connection ingress node,=20 > > for example, needs only be signaled with this tuple by the=20 > > downstream neighbor, hence the control plane label is MAC=20 > > DA/VID (or just VID, for those who like the idea of the VID=20 > > cross-connects architecture). > >=20 > > So, IMO IEEE should be responsible for the definition of data=20 > > plane labels, while CCAMP for control plane labels. > >=20 > > Cheers, > > Igor=20 > >=20 > >=20 > > neil.2.harrison@bt.com wrote: > >=20 > > Dimitri wrote 07 September 2007 16:36 in response to Adrian=20 > >=20 > > > >=20 > > > > This is also something we would expect to describe within > > > > CCAMP although=20 > > > > "what is a label" would come to us from the data plane=20 > > > specification. > > >=20 > > > do i interpreet correctly your statement that if the=20 > > > specification that CCAMP is going to receive from IEEE does=20 > > > not speak about "label" and its encoding there will be no=20 > > > place to discuss any "label processing" and "label=20 > > > distribution" protocol in IETF - being domain-wide or=20 > > link-local > > > - > > >=20 > > > in that case, isn't the .1Q specification outside scope of=20 > > > this effort since not referring - as of today at least - to=20 > > > any "label" semantic as part of the Ethernet frame header=20 > > > information field ? > > >=20 > > > thanks, > > > -d. > >=20 > > What do you think a MAC DA, MAC SA and VID are? These=20 > > are all 'labels'. > >=20 > > You also have to remember that the nature of the labels=20 > > required in a > > traffic unit are determined by the type of the network=20 > > mode one is > > dealing with. > >=20 > > In the co-cs and co-ps modes we have a construction known as a > > 'connection'. This implies specific architectural=20 > > requirements....but > > the most significant, for this discussion at least, is=20 > > that a connection > > must have a single source. What this means is that one=20 > > does not have to > > incorporate a SA label in a co mode traffic=20 > > unit....under defect-free > > conditions it is redundant information as the=20 > > connection itself provides > > the source information. {Compare this to the cl-ps mode=20 > > which does not > > have connections...here having a SA in the traffic unit=20 > > is essential} > >=20 > > Ergo why co-cs and co-ps mode technologies to date that=20 > > respect the > > requirements of a connection have only focussed on=20 > > incorporating a DA > > (forwarding) label. Further, these forwarding labels=20 > > only need to be > > distinct in resolving some number (N say) of different=20 > > client layer > > (link-connection) instances within a server layer=20 > > (network connection) > > resource partition. However, there are advantages from=20 > > having both a SA > > and DA label in a co-ps traffic unit that are network=20 > > unique and not > > just link-connection unique (ie not swapped)....the=20 > > inherent robustness > > under misconnectivity defects (without any adjunct OAM=20 > > flow) is one of > > these. And of course, these are the nature of the=20 > > native labels one > > already gets in Ethernet due to its cl-ps mode origins.=20 > > So why would > > one even contemplate not using these since they are=20 > > already there? > >=20 > > The VID label is slightly different in that one can=20 > > consider it as a > > 'route discriminator label' and a local extension to=20 > > the SA or DA, ie it > > provides the ability to identify disjoint paths between=20 > > nodal end > > points. > >=20 > > The mere fact IEEE may not refer to the above=20 > > quantities as 'labels' > > does not change the fact that this is what they are. So=20 > > I'm not clear > > what your real point is here. > >=20 > > regards, Neil > >=20 > >=20 > >=20 > >=20 > > ________________________________ > >=20 > > Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge=20 > > > ions/222> to see what's on, when.=20 > >=20 > =09 > =09 >=20 >=20 > ________________________________ >=20 > Ready for the edge of your seat? Check out tonight's top=20 > picks=20 > on=20 > Yahoo! TV.=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 08 Sep 2007 14:35:12 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F225.293E5CF2" Subject: RE: Closing the GELS Mailing List Date: Sat, 8 Sep 2007 15:32:36 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C0106EDF4@E03MVB2-UKBR.domain1.systemhost.net> Thread-Topic: Closing the GELS Mailing List Thread-Index: AcfyHTv9AzpIN5m4QLG1qvp0tsAYngAAGXwA From: To: , , , , , , Cc: This is a multi-part message in MIME format. ------_=_NextPart_001_01C7F225.293E5CF2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Igor...just want to slightly correct/amend something below...please see in-line: -----Original Message----- From: Igor Bryskin [mailto:i_bryskin@yahoo.com]=20 Sent: 08 September 2007 14:36 To: PAPADIMITRIOU Dimitri; Harrison,N,Neil,JCGA1 R; adrian@olddog.co.uk; zali@cisco.com; Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org Cc: rcallon@juniper.net Subject: RE: Closing the GELS Mailing List Dimitri, As Neil correctly pointed out, there is a great advantage in having connection source ID within label of every packet forwarded over the connection (and MPLS's great deficiency is the lack of LSP source ID in the MPLS label).=20 NH=3D> Yes, it is true that having a SA label in each/every traffic unit is an important advantage...and so is having a DA address label (for forwarding) that does not have to be swapped. As I pointed out before, one can take some short-cuts and traditional co-ps mode technologies have (perhaps unconsciously?) done so, viz: - if one respects the requirements of a connection then you can omit the SA label from the DP traffic units....as under defect-free conditions it is redundant information. However, this means OAM (essentially a CV flow that contains the SA label) should (but really ought to be must for customer integrity/security reasons) be run on ALL connections (irrespective of their importance) as one cannot predict a priori where misconnectivity defects will occur. But this is significantly operationally inferior to having the SA information carried in the traffic unit as this makes the network inherently robust to such defects without any OAM at all. - wrt forwarding one only needs to resolve/identify (ie label) the number of client instances that a given server layer resource partition can support per client link connection.....noting that said labels are indeed indirection proxies for the true DA anyway. However, this is also operationally inferior to using a true connection DA for forwarding that is not swapped. =20 Now if you don't respect the requirements of a connection, and both LDP and PHP in MPLS don't as they create mp2p constructs, then you have to appeal to a higher layer entity to effect a demerging function, ie essentially recover the lost SA information. If the client is a cl-ps mode technology with non-overlapping addresses this can do the job directly. If this is not the case you have to add the lost information some other way....and in MPLS this is done by adding a further 1-hop LSP where the label here now takes on the semantic of SA. But this is actually not a very sensible approach because one of the key operational things we need in any layer network is consistent Characteristic Information (ie consistent traffic unit structure, consistent traffic unit functional field semantics and consistent OAM). Why is this important? Well, if one has misconnectivity defects present it is important that the trail (co mode) or flow (cl mode) termination points handles the traffic units and OAM in a consistent and predictable way. MPLS does not have consistent CI....indeed I can list at least 4 different semantics of a label and more will emerge as folks consider new applications like p2mp constructs. =20 There are many other consequences of merging constructs, but I don't want to get into these here. =20 regards, Neil =20 The source ID must be within the (data plane) label and not anywhere else, because the label constitutes Layer Information (LI) in ITU terms, and only LI is accessible to a server layer that claims transparency for its clients. On the other hand source MA in co Ethernet is not used for packet forwarding, hence it should not be signaled as a part of the (control plane) label, which is information that must be put by an upstream node into the packet header, so that the downstream node could recognize and properly forward the packet.=20 The conclusions in the context of co Ethernet: a) Data plane label is something determined only by IEEE, because it exists independently from any Control Plane: Ethernet connections could be configured by NMS without any Control Plane (no control plane labels at all). As far as CCAMP is concerned, data plane label is untouchable; b) Control plane label is always a subset of data plane and is an essential subject of CCAMP discussions: is it DMAC/VID? just VID? nothing as in case of statically configured connections? Is it network-scope? node-scope? link-scope? Stuff like that. Cheers, Igor > So, IMO IEEE should be responsible for the definition of data=20 > plane labels, while CCAMP for control plane labels. a label distribution protocol is a set of procedures by which one node informs another of the label/FEC bindings it has made if these labels are distributed via the gmpls control plane driving population of the LIBs to which difference are u pointing out here ? so, not sure to see the point (whatever the number of levels of indirection between the fwd'ing plane encoding and control plane encoding u will always fall back on the former, the label distribution protocol exchanges a piece of information used by the nodes to perform their forwarding decision)=20 -d. > -----Original Message----- > From: Igor Bryskin [mailto:i_bryskin@yahoo.com]=20 > Sent: Friday, September 07, 2007 9:21 PM > To: neil.2.harrison@bt.com; PAPADIMITRIOU Dimitri;=20 > adrian@olddog.co.uk; zali@cisco.com;=20 > Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org > Cc: rcallon@juniper.net > Subject: RE: Closing the GELS Mailing List >=20 > Hi Neil, >=20 > I think there is a difference between a "data plane label"=20 > which is a Layer Information (LI) used by a given server=20 > layer and a "control plane label", which is a piece of=20 > information signaled between adjacent controllers for the=20 > purpose of connection provisioning. IMO the former is always=20 > a superset of the latter. Let's take, for instance,=20 > connection oriented Ethernet. MAC SA is a very important part=20 > of the data plane label because it identifies the source of=20 > the connection. However, the connection frames are forwarded=20 > according to MAC DA/VID, and hence connection ingress node,=20 > for example, needs only be signaled with this tuple by the=20 > downstream neighbor, hence the control plane label is MAC=20 > DA/VID (or just VID, for those who like the idea of the VID=20 > cross-connects architecture). >=20 > So, IMO IEEE should be responsible for the definition of data=20 > plane labels, while CCAMP for control plane labels. >=20 > Cheers, > Igor=20 >=20 >=20 > neil.2.harrison@bt.com wrote: >=20 > Dimitri wrote 07 September 2007 16:36 in response to Adrian=20 >=20 > > >=20 > > > This is also something we would expect to describe within > > > CCAMP although=20 > > > "what is a label" would come to us from the data plane=20 > > specification. > >=20 > > do i interpreet correctly your statement that if the=20 > > specification that CCAMP is going to receive from IEEE does=20 > > not speak about "label" and its encoding there will be no=20 > > place to discuss any "label processing" and "label=20 > > distribution" protocol in IETF - being domain-wide or=20 > link-local > > - > >=20 > > in that case, isn't the .1Q specification outside scope of=20 > > this effort since not referring - as of today at least - to=20 > > any "label" semantic as part of the Ethernet frame header=20 > > information field ? > >=20 > > thanks, > > -d. >=20 > What do you think a MAC DA, MAC SA and VID are? These=20 > are all 'labels'. >=20 > You also have to remember that the nature of the labels=20 > required in a > traffic unit are determined by the type of the network=20 > mode one is > dealing with. >=20 > In the co-cs and co-ps modes we have a construction known as a > 'connection'. This implies specific architectural=20 > requirements....but > the most significant, for this discussion at least, is=20 > that a connection > must have a single source. What this means is that one=20 > does not have to > incorporate a SA label in a co mode traffic=20 > unit....under defect-free > conditions it is redundant information as the=20 > connection itself provides > the source information. {Compare this to the cl-ps mode=20 > which does not > have connections...here having a SA in the traffic unit=20 > is essential} >=20 > Ergo why co-cs and co-ps mode technologies to date that=20 > respect the > requirements of a connection have only focussed on=20 > incorporating a DA > (forwarding) label. Further, these forwarding labels=20 > only need to be > distinct in resolving some number (N say) of different=20 > client layer > (link-connection) instances within a server layer=20 > (network connection) > resource partition. However, there are advantages from=20 > having both a SA > and DA label in a co-ps traffic unit that are network=20 > unique and not > just link-connection unique (ie not swapped)....the=20 > inherent robustness > under misconnectivity defects (without any adjunct OAM=20 > flow) is one of > these. And of course, these are the nature of the=20 > native labels one > already gets in Ethernet due to its cl-ps mode origins.=20 > So why would > one even contemplate not using these since they are=20 > already there? >=20 > The VID label is slightly different in that one can=20 > consider it as a > 'route discriminator label' and a local extension to=20 > the SA or DA, ie it > provides the ability to identify disjoint paths between=20 > nodal end > points. >=20 > The mere fact IEEE may not refer to the above=20 > quantities as 'labels' > does not change the fact that this is what they are. So=20 > I'm not clear > what your real point is here. >=20 > regards, Neil >=20 >=20 >=20 >=20 > ________________________________ >=20 > Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge=20 > > ions/222> to see what's on, when.=20 >=20 _____ =20 Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV.=20 ------_=_NextPart_001_01C7F225.293E5CF2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
    Thanks Igor...just want to slightly correct/amend something=20 below...please see in-line:
    -----Original Message-----
    From: Igor = Bryskin=20 [mailto:i_bryskin@yahoo.com]
    Sent: 08 September 2007=20 14:36
    To: PAPADIMITRIOU Dimitri; Harrison,N,Neil,JCGA1 R;=20 adrian@olddog.co.uk; zali@cisco.com; Attila.Takacs@ericsson.com;=20 ccamp@ops.ietf.org; gels@rtg.ietf.org
    Cc:=20 rcallon@juniper.net
    Subject: RE: Closing the GELS Mailing=20 List

    Dimitri,
    As Neil correctly pointed out, there is a = great=20 advantage in having connection source ID within label of every = packet=20 forwarded over the connection (and MPLS’s great deficiency is = the lack of=20 LSP source ID in the MPLS label). 
    NH=3D> Yes, it is = true that=20 having a SA label in each/every traffic unit is an important = advantage...and so=20 is having a DA address label (for forwarding) that does not have to = be=20 swapped.  As I pointed out before, one can take some = short-cuts=20 and traditional co-ps mode technologies have (perhaps = unconsciously?) done=20 so, viz:
     -    if one respects the = requirements of a=20 connection then you can omit the SA label from the DP traffic = units....as=20 under defect-free conditions it is redundant information.  = However,=20 this means OAM (essentially a CV flow that contains the SA label) = should=20 (but really ought to be must for customer integrity/security = reasons) be run=20 on ALL connections (irrespective of their importance) as one cannot = predict=20 a priori where misconnectivity defects will occur.  But this is = significantly operationally inferior to having the SA information = carried in=20 the traffic unit as this makes the network inherently robust to such = defects=20 without any OAM at all.
    -    wrt=20 forwarding one only needs to resolve/identify (ie label) the number = of=20 client instances that a given server layer resource partition can = support=20 per client link connection.....noting that said labels are indeed=20 indirection proxies for the true DA anyway.  However, this is = also=20 operationally inferior to using a true connection DA for = forwarding=20 that is not swapped.
     
    Now if you don't = respect the=20 requirements of a connection, and both LDP and PHP in MPLS don't as = they=20 create mp2p constructs, then you have to appeal to a higher layer = entity to=20 effect a demerging function, ie essentially recover the lost SA=20 information.  If the client is a cl-ps mode technology with=20 non-overlapping addresses this can do the job directly.  If = this is not=20 the case you have to add the lost information some other way....and = in MPLS=20 this is done by adding a further 1-hop LSP where the label here now = takes on=20 the semantic of SA.  But this is actually not a very sensible = approach=20 because one of the key operational things we need in any layer = network is=20 consistent Characteristic Information (ie consistent traffic unit = structure,=20 consistent traffic unit functional field semantics and consistent=20 OAM).  Why is this important?  Well, if one has = misconnectivity=20 defects present it is important that the trail (co mode) or flow (cl = mode)=20 termination points handles the traffic units and OAM in a consistent = and=20 predictable way.  MPLS does not have consistent CI....indeed I = can list=20 at least 4 different semantics of a label and more will emerge as = folks=20 consider new applications like p2mp constructs.
     
    There are many other = consequences=20 of merging constructs, but I don't want to get into these=20 here.
     
    regards, = Neil
     
      The=20 source ID must be within the (data plane) label and not anywhere = else,=20 because the label constitutes Layer Information (LI) in ITU terms, = and only=20 LI is accessible to a server layer that claims transparency for its = clients.=20 On the other hand source MA in co Ethernet is not used for packet=20 forwarding, hence it should not be signaled as a part of the = (control plane)=20 label, which is information that must be put by an upstream node = into the=20 packet header, so that the downstream node could recognize and = properly=20 forward the packet.
    The conclusions in the context of co = Ethernet:
    <!--[if=20 !supportLists]-->a)    =20 <!--[endif]-->Data plane label is something = determined=20 only by IEEE, because it exists independently from any Control = Plane:=20 Ethernet connections could be configured by NMS without any Control = Plane=20 (no control plane labels at all). As far as CCAMP is concerned, data = plane=20 label is untouchable;
    <!--[if=20 !supportLists]-->b)   =20 <!--[endif]-->Control plane label is always a = subset of=20 data plane and is an essential subject of CCAMP discussions: is it = DMAC/VID?=20 just VID?  nothing as in case of statically = configured=20 connections? Is it network-scope? node-scope? link-scope? Stuff like = that.
    Cheers,
    Igor

    <!--[if=20 = !supportLineBreakNewLine]-->
    <!--[endif]-->

    >= ;=20 So, IMO IEEE should be responsible for the definition of data =
    > plane=20 labels, while CCAMP for control plane labels.

    a label = distribution=20 protocol is a set of procedures by which one node
    informs another = of the=20 label/FEC bindings it has made

    if these labels are = distributed via=20 the gmpls control plane driving
    population of the LIBs to which=20 difference are u pointing out here ? so,
    not sure to see the = point=20 (whatever the number of levels of indirection
    between the fwd'ing = plane=20 encoding and control plane encoding u will
    always fall back on = the=20 former, the label distribution protocol
    exchanges a piece of = information=20 used by the nodes to perform their
    forwarding decision)=20

    -d.

    > -----Original Message-----
    > From: = Igor=20 Bryskin [mailto:i_bryskin@yahoo.com]
    > Sent: Friday, = September 07,=20 2007 9:21 PM
    > To: neil.2.harrison@bt.com; PAPADIMITRIOU = Dimitri;=20
    > adrian@olddog.co.uk; zali@cisco.com;
    >=20 Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; = gels@rtg.ietf.org
    >=20 Cc: rcallon@juniper.net
    > Subject: RE: Closing the GELS = Mailing=20 List
    >
    > Hi Neil,
    >
    > I think there is a=20 difference between a "data plane label"
    > which is a Layer=20 Information (LI) used by a given server
    > layer and a = "control plane=20 label", which is a piece of
    > information signaled between = adjacent=20 controllers for the
    > purpose of connection provisioning. IMO = the=20 former is always
    > a superset of the latter. Let's take, for=20 instance,
    > connection oriented Ethernet. MAC SA is a very = important=20 part
    > of the data plane label because it identifies the = source of=20
    > the connection. However, the connection frames are = forwarded=20
    > according to MAC DA/VID, and hence connection ingress node, =
    > for example, needs only be signaled with this tuple by the =
    >=20 downstream neighbor, hence the control plane label is MAC
    > = DA/VID=20 (or just VID, for those who like the idea of the VID
    > = cross-connects=20 architecture).
    >
    > So, IMO IEEE should be responsible = for the=20 definition of data
    > plane labels, while CCAMP for control = plane=20 labels.
    >
    > Cheers,
    > Igor
    >
    > =
    >=20 neil.2.harrison@bt.com wrote:
    >
    > Dimitri wrote 07 = September=20 2007 16:36 in response to Adrian
    >
    > > > =
    > >=20 > This is also something we would expect to describe = within
    > >=20 > CCAMP although
    > > > "what is a label" would come = to us=20 from the data plane
    > > specification.
    > > =
    > >=20 do i interpreet correctly your statement that if the
    > >=20 specification that CCAMP is going to receive from IEEE does
    > = >=20 not speak about "label" and its encoding there will be no
    > = >=20 place to discuss any "label processing" and "label
    > >=20 distribution" protocol in IETF - being domain-wide or
    >=20 link-local
    > > -
    > >
    > > in that case, = isn't the=20 .1Q specification outside scope of
    > > this effort since = not=20 referring - as of today at least - to
    > > any "label" = semantic as=20 part of the Ethernet frame header
    > > information field = ?
    >=20 >
    > > thanks,
    > > -d.
    >
    > What do = you=20 think a MAC DA, MAC SA and VID are? These
    > are all = 'labels'.
    >=20
    > You also have to remember that the nature of the labels =
    >=20 required in a
    > traffic unit are determined by the type of the = network=20
    > mode one is
    > dealing with.
    >
    > In the = co-cs and=20 co-ps modes we have a construction known as a
    > 'connection'. = This=20 implies specific architectural
    > requirements....but
    > = the most=20 significant, for this discussion at least, is
    > that a=20 connection
    > must have a single source. What this means is = that one=20
    > does not have to
    > incorporate a SA label in a co = mode=20 traffic
    > unit....under defect-free
    > conditions it is=20 redundant information as the
    > connection itself = provides
    > the=20 source information. {Compare this to the cl-ps mode
    > which = does=20 not
    > have connections...here having a SA in the traffic unit =
    >=20 is essential}
    >
    > Ergo why co-cs and co-ps mode = technologies to=20 date that
    > respect the
    > requirements of a connection = have=20 only focussed on
    > incorporating a DA
    > (forwarding) = label.=20 Further, these forwarding labels
    > only need to be
    > = distinct=20 in resolving some number (N say) of different
    > client = layer
    >=20 (link-connection) instances within a server layer
    > (network=20 connection)
    > resource partition. However, there are = advantages from=20
    > having both a SA
    > and DA label in a co-ps traffic = unit that=20 are network
    > unique and not
    > just link-connection = unique (ie=20 not swapped)....the
    > inherent robustness
    > under=20 misconnectivity defects (without any adjunct OAM
    > flow) is = one=20 of
    > these. And of course, these are the nature of the =
    > native=20 labels one
    > already gets in Ethernet due to its cl-ps mode = origins.=20
    > So why would
    > one even contemplate not using these = since=20 they are
    > already there?
    >
    > The VID label is = slightly=20 different in that one can
    > consider it as a
    > 'route=20 discriminator label' and a local extension to
    > the SA or DA, = ie=20 it
    > provides the ability to identify disjoint paths between =
    >=20 nodal end
    > points.
    >
    > The mere fact IEEE may = not refer=20 to the above
    > quantities as 'labels'
    > does not change = the=20 fact that this is what they are. So
    > I'm not clear
    > = what your=20 real point is here.
    >
    > regards, Neil
    >
    > =
    >=20
    >
    > ________________________________
    >
    > = Sick=20 sense of humor? Visit Yahoo! TV's Comedy with an Edge
    > = >=20 ions/222> to see what's on, when.
    >=20



    Ready for the edge of your seat? Check = out=20 tonight's top picks on Yahoo! TV.
    ------_=_NextPart_001_01C7F225.293E5CF2-- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 08 Sep 2007 13:36:53 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=S3lpUEU8LC2a0BCzkszcs6TgLFBFXMSpjKDSb/zhpNUa3EEd2SHsnOGQsmwYqS7SymUEBjNyFokPzAJoscxThA9+S6qRu8kUy2KJqh4qm78IiFkz9fr6HMaKj56HUt+7QhK/ENuTYkFUiweD1s+Vp62Y+WLxWWCA7ergiiRGmwo=; Date: Sat, 8 Sep 2007 06:36:15 -0700 (PDT) From: Igor Bryskin Subject: RE: Closing the GELS Mailing List To: PAPADIMITRIOU Dimitri , neil.2.harrison@bt.com, adrian@olddog.co.uk, zali@cisco.com, Attila.Takacs@ericsson.com, ccamp@ops.ietf.org, gels@rtg.ietf.org Cc: rcallon@juniper.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2017222141-1189258575=:29167" Content-Transfer-Encoding: 8bit Message-ID: <216751.29167.qm@web36808.mail.mud.yahoo.com> --0-2017222141-1189258575=:29167 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dimitri, As Neil correctly pointed out, there is a great advantage in having connection source ID within label of every packet forwarded over the connection (and MPLS’s great deficiency is the lack of LSP source ID in the MPLS label). The source ID must be within the (data plane) label and not anywhere else, because the label constitutes Layer Information (LI) in ITU terms, and only LI is accessible to a server layer that claims transparency for its clients. On the other hand source MA in co Ethernet is not used for packet forwarding, hence it should not be signaled as a part of the (control plane) label, which is information that must be put by an upstream node into the packet header, so that the downstream node could recognize and properly forward the packet. The conclusions in the context of co Ethernet: a) Data plane label is something determined only by IEEE, because it exists independently from any Control Plane: Ethernet connections could be configured by NMS without any Control Plane (no control plane labels at all). As far as CCAMP is concerned, data plane label is untouchable; b) Control plane label is always a subset of data plane and is an essential subject of CCAMP discussions: is it DMAC/VID? just VID? nothing as in case of statically configured connections? Is it network-scope? node-scope? link-scope? Stuff like that. Cheers, Igor > So, IMO IEEE should be responsible for the definition of data > plane labels, while CCAMP for control plane labels. a label distribution protocol is a set of procedures by which one node informs another of the label/FEC bindings it has made if these labels are distributed via the gmpls control plane driving population of the LIBs to which difference are u pointing out here ? so, not sure to see the point (whatever the number of levels of indirection between the fwd'ing plane encoding and control plane encoding u will always fall back on the former, the label distribution protocol exchanges a piece of information used by the nodes to perform their forwarding decision) -d. > -----Original Message----- > From: Igor Bryskin [mailto:i_bryskin@yahoo.com] > Sent: Friday, September 07, 2007 9:21 PM > To: neil.2.harrison@bt.com; PAPADIMITRIOU Dimitri; > adrian@olddog.co.uk; zali@cisco.com; > Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org > Cc: rcallon@juniper.net > Subject: RE: Closing the GELS Mailing List > > Hi Neil, > > I think there is a difference between a "data plane label" > which is a Layer Information (LI) used by a given server > layer and a "control plane label", which is a piece of > information signaled between adjacent controllers for the > purpose of connection provisioning. IMO the former is always > a superset of the latter. Let's take, for instance, > connection oriented Ethernet. MAC SA is a very important part > of the data plane label because it identifies the source of > the connection. However, the connection frames are forwarded > according to MAC DA/VID, and hence connection ingress node, > for example, needs only be signaled with this tuple by the > downstream neighbor, hence the control plane label is MAC > DA/VID (or just VID, for those who like the idea of the VID > cross-connects architecture). > > So, IMO IEEE should be responsible for the definition of data > plane labels, while CCAMP for control plane labels. > > Cheers, > Igor > > > neil.2.harrison@bt.com wrote: > > Dimitri wrote 07 September 2007 16:36 in response to Adrian > > > > > > > This is also something we would expect to describe within > > > CCAMP although > > > "what is a label" would come to us from the data plane > > specification. > > > > do i interpreet correctly your statement that if the > > specification that CCAMP is going to receive from IEEE does > > not speak about "label" and its encoding there will be no > > place to discuss any "label processing" and "label > > distribution" protocol in IETF - being domain-wide or > link-local > > - > > > > in that case, isn't the .1Q specification outside scope of > > this effort since not referring - as of today at least - to > > any "label" semantic as part of the Ethernet frame header > > information field ? > > > > thanks, > > -d. > > What do you think a MAC DA, MAC SA and VID are? These > are all 'labels'. > > You also have to remember that the nature of the labels > required in a > traffic unit are determined by the type of the network > mode one is > dealing with. > > In the co-cs and co-ps modes we have a construction known as a > 'connection'. This implies specific architectural > requirements....but > the most significant, for this discussion at least, is > that a connection > must have a single source. What this means is that one > does not have to > incorporate a SA label in a co mode traffic > unit....under defect-free > conditions it is redundant information as the > connection itself provides > the source information. {Compare this to the cl-ps mode > which does not > have connections...here having a SA in the traffic unit > is essential} > > Ergo why co-cs and co-ps mode technologies to date that > respect the > requirements of a connection have only focussed on > incorporating a DA > (forwarding) label. Further, these forwarding labels > only need to be > distinct in resolving some number (N say) of different > client layer > (link-connection) instances within a server layer > (network connection) > resource partition. However, there are advantages from > having both a SA > and DA label in a co-ps traffic unit that are network > unique and not > just link-connection unique (ie not swapped)....the > inherent robustness > under misconnectivity defects (without any adjunct OAM > flow) is one of > these. And of course, these are the nature of the > native labels one > already gets in Ethernet due to its cl-ps mode origins. > So why would > one even contemplate not using these since they are > already there? > > The VID label is slightly different in that one can > consider it as a > 'route discriminator label' and a local extension to > the SA or DA, ie it > provides the ability to identify disjoint paths between > nodal end > points. > > The mere fact IEEE may not refer to the above > quantities as 'labels' > does not change the fact that this is what they are. So > I'm not clear > what your real point is here. > > regards, Neil > > > > > ________________________________ > > Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge > > ions/222> to see what's on, when. > --------------------------------- Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. --0-2017222141-1189258575=:29167 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
    Dimitri,
    As Neil correctly pointed out, there is a great advantage in having connection source ID within label of every packet forwarded over the connection (and MPLS’s great deficiency is the lack of LSP source ID in the MPLS label). The source ID must be within the (data plane) label and not anywhere else, because the label constitutes Layer Information (LI) in ITU terms, and only LI is accessible to a server layer that claims transparency for its clients. On the other hand source MA in co Ethernet is not used for packet forwarding, hence it should not be signaled as a part of the (control plane) label, which is information that must be put by an upstream node into the packet header, so that the downstream node could recognize and properly forward the packet.
     
    The conclusions in the context of co Ethernet:
     
    a)     Data plane label is something determined only by IEEE, because it exists independently from any Control Plane: Ethernet connections could be configured by NMS without any Control Plane (no control plane labels at all). As far as CCAMP is concerned, data plane label is untouchable;
    b)    Control plane label is always a subset of data plane and is an essential subject of CCAMP discussions: is it DMAC/VID? just VID?  nothing as in case of statically configured connections? Is it network-scope? node-scope? link-scope? Stuff like that.
     
    Cheers,
    Igor




    > So, IMO IEEE should be responsible for the definition of data
    > plane labels, while CCAMP for control plane labels.

    a label distribution protocol is a set of procedures by which one node
    informs another of the label/FEC bindings it has made

    if these labels are distributed via the gmpls control plane driving
    population of the LIBs to which difference are u pointing out here ? so,
    not sure to see the point (whatever the number of levels of indirection
    between the fwd'ing plane encoding and control plane encoding u will
    always fall back on the former, the label distribution protocol
    exchanges a piece of information used by the nodes to perform their
    forwarding decision)

    -d.

    > -----Original Message-----
    > From: Igor Bryskin [mailto:i_bryskin@yahoo.com]
    > Sent: Friday, September 07, 2007 9:21 PM
    > To: neil.2.harrison@bt.com; PAPADIMITRIOU Dimitri;
    > adrian@olddog.co.uk; zali@cisco.com;
    > Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org
    > Cc: rcallon@juniper.net
    > Subject: RE: Closing the GELS Mailing List
    >
    > Hi Neil,
    >
    > I think there is a difference between a "data plane label"
    > which is a Layer Information (LI) used by a given server
    > layer and a "control plane label", which is a piece of
    > information signaled between adjacent controllers for the
    > purpose of connection provisioning. IMO the former is always
    > a superset of the latter. Let's take, for instance,
    > connection oriented Ethernet. MAC SA is a very important part
    > of the data plane label because it identifies the source of
    > the connection. However, the connection frames are forwarded
    > according to MAC DA/VID, and hence connection ingress node,
    > for example, needs only be signaled with this tuple by the
    > downstream neighbor, hence the control plane label is MAC
    > DA/VID (or just VID, for those who like the idea of the VID
    > cross-connects architecture).
    >
    > So, IMO IEEE should be responsible for the definition of data
    > plane labels, while CCAMP for control plane labels.
    >
    > Cheers,
    > Igor
    >
    >
    > neil.2.harrison@bt.com wrote:
    >
    > Dimitri wrote 07 September 2007 16:36 in response to Adrian
    >
    > > >
    > > > This is also something we would expect to describe within
    > > > CCAMP although
    > > > "what is a label" would come to us from the data plane
    > > specification.
    > >
    > > do i interpreet correctly your statement that if the
    > > specification that CCAMP is going to receive from IEEE does
    > > not speak about "label" and its encoding there will be no
    > > place to discuss any "label processing" and "label
    > > distribution" protocol in IETF - being domain-wide or
    > link-local
    > > -
    > >
    > > in that case, isn't the .1Q specification outside scope of
    > > this effort since not referring - as of today at least - to
    > > any "label" semantic as part of the Ethernet frame header
    > > information field ?
    > >
    > > thanks,
    > > -d.
    >
    > What do you think a MAC DA, MAC SA and VID are? These
    > are all 'labels'.
    >
    > You also have to remember that the nature of the labels
    > required in a
    > traffic unit are determined by the type of the network
    > mode one is
    > dealing with.
    >
    > In the co-cs and co-ps modes we have a construction known as a
    > 'connection'. This implies specific architectural
    > requirements....but
    > the most significant, for this discussion at least, is
    > that a connection
    > must have a single source. What this means is that one
    > does not have to
    > incorporate a SA label in a co mode traffic
    > unit....under defect-free
    > conditions it is redundant information as the
    > connection itself provides
    > the source information. {Compare this to the cl-ps mode
    > which does not
    > have connections...here having a SA in the traffic unit
    > is essential}
    >
    > Ergo why co-cs and co-ps mode technologies to date that
    > respect the
    > requirements of a connection have only focussed on
    > incorporating a DA
    > (forwarding) label. Further, these forwarding labels
    > only need to be
    > distinct in resolving some number (N say) of different
    > client layer
    > (link-connection) instances within a server layer
    > (network connection)
    > resource partition. However, there are advantages from
    > having both a SA
    > and DA label in a co-ps traffic unit that are network
    > unique and not
    > just link-connection unique (ie not swapped)....the
    > inherent robustness
    > under misconnectivity defects (without any adjunct OAM
    > flow) is one of
    > these. And of course, these are the nature of the
    > native labels one
    > already gets in Ethernet due to its cl-ps mode origins.
    > So why would
    > one even contemplate not using these since they are
    > already there?
    >
    > The VID label is slightly different in that one can
    > consider it as a
    > 'route discriminator label' and a local extension to
    > the SA or DA, ie it
    > provides the ability to identify disjoint paths between
    > nodal end
    > points.
    >
    > The mere fact IEEE may not refer to the above
    > quantities as 'labels'
    > does not change the fact that this is what they are. So
    > I'm not clear
    > what your real point is here.
    >
    > regards, Neil
    >
    >
    >
    >
    > ________________________________
    >
    > Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge
    > > ions/222> to see what's on, when.
    >



    Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. --0-2017222141-1189258575=:29167-- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 08 Sep 2007 12:39:45 +0000 Message-ID: <069d01c7f214$ecd50680$0302a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: liaison to IETF (ccamp, MPLS, BFD, PWE3, and L3VPN) on MFA Forum MPLS ICI Date: Sat, 8 Sep 2007 13:32:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit FYI, The MFA would like a response to their liaison by 18th October. Adrian ----- Original Message ----- From: "David Sinicrope (RL/TNT)" To: "Adrian Farrel" ; "J. Rao Cherukuri" Cc: "Ross Callon" ; ; ; ; "Bocci, Matthew (Matthew)" ; ; ; ; "Ronald Bonica" ; "Stewart Bryant (stbryant)" ; ; ; ; "George Swallow (swallow)" ; "Loa Andersson" Sent: Friday, September 07, 2007 11:28 PM Subject: RE: liaison to IETF (ccamp, MPLS, BFD, PWE3, and L3VPN) on MFA Forum MPLS ICI Hi Adrian, Our next MFA Forum Technical Committee meeting is scheduled for October 22-26. If at all possible, we would like to have comments and feedback from the IETF by 10/18/2007 so that we could review and address them during that meeting. I realize that for the size of the document a little over 5 weeks for review and comment is very short notice. If not by 10/18/2007, then as soon as possible afterwards would help us. We are aiming to complete the document by year end and would need to have IETF feedback resolved and incorporated by the end of November at the latest to meet that goal. Please feel free to contact me with any other questions you may have. Thank-you for your help and support. Best Regards, David -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Friday, September 07, 2007 5:44 PM To: J. Rao Cherukuri; David Sinicrope (RL/TNT) Cc: Ross Callon; townsley@cisco.com; jari.arkko@piuha.net; andrew.g.malis@verizon.com; Bocci, Matthew (Matthew); nabil.n.bitar@verizon.com; dbrungard@att.com; rick.wilder@alcatel-lucent.com; Ronald Bonica; Stewart Bryant (stbryant); danny@arbor.net; dward@cisco.com; jhaas@pfrc.org; George Swallow (swallow); Loa Andersson Subject: Re: liaison to IETF (ccamp, MPLS, BFD, PWE3, and L3VPN) on MFA Forum MPLS ICI Rao, David, > This document is in our first level ballot procedure. > Please review and provide comments. Please suggest an appropriate timescale for review feedback. Thanks, Adrian ----- Original Message ----- From: "J. Rao Cherukuri" To: ; ; ; ; ; "Ronald Bonica" ; "Stewart Bryant (stbryant)" ; ; ; ; "George Swallow (swallow)" ; "Loa Andersson" Cc: "Ross Callon" ; ; ; "David Sinicrope (RL/TNT)" ; ; "Bocci, Matthew (Matthew)" ; "J. Rao Cherukuri" ; Sent: Friday, September 07, 2007 1:28 AM Subject: liaison to IETF (ccamp, MPLS, BFD, PWE3, and L3VPN) on MFA Forum MPLS ICI Dear All, The MFA Forum is currently working on an MPLS Inter-Carrier Interconnect (MPLS-ICI) specification to support IP VPNs, MPLS Pseudo Wires, Data Trunks, and VoIP. This specification is being driven by the MFA Forum service provider members. The objective of this Technical Specification is to enable a set of MPLS services, across administrative domains operated by different carriers. The MPLS ICI is a bi-directional IP-MPLS logical link between an Autonomous System Border Router (ASBR) in one service provider network and an ASBR in another service provider network. This document is targeted to equipment vendors to specify the necessary ASBR requirements and to service providers to provide guidance on how to use these capabilities. This document uses protocols developed in appropriate standard bodies (e.g., IETF, ITU) where applicable. This document is in our first level ballot procedure. Please review and provide comments. Thank you for your consideration of this matter. Cordially, David Sinicrope, A&D Chair, MFA Forum Rao Cherukuri Chairman, MFA Forum Technical Committee (draft MPLS ICI) Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 08 Sep 2007 08:05:14 +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: Closing the GELS Mailing List Date: Sat, 8 Sep 2007 10:02:44 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E3800132149A@FRVELSMBS22.ad2.ad.alcatel.com> Thread-Topic: Closing the GELS Mailing List thread-index: AcfxhFFC5MDKHllkRmqpnDUfKCOC6AACP26g From: "PAPADIMITRIOU Dimitri" To: "Igor Bryskin" , , , , , , Cc: igor, > So, IMO IEEE should be responsible for the definition of data=20 > plane labels, while CCAMP for control plane labels. a label distribution protocol is a set of procedures by which one node informs another of the label/FEC bindings it has made if these labels are distributed via the gmpls control plane driving population of the LIBs to which difference are u pointing out here ? so, not sure to see the point (whatever the number of levels of indirection between the fwd'ing plane encoding and control plane encoding u will always fall back on the former, the label distribution protocol exchanges a piece of information used by the nodes to perform their forwarding decision)=20 -d. > -----Original Message----- > From: Igor Bryskin [mailto:i_bryskin@yahoo.com]=20 > Sent: Friday, September 07, 2007 9:21 PM > To: neil.2.harrison@bt.com; PAPADIMITRIOU Dimitri;=20 > adrian@olddog.co.uk; zali@cisco.com;=20 > Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org > Cc: rcallon@juniper.net > Subject: RE: Closing the GELS Mailing List >=20 > Hi Neil, > =20 > I think there is a difference between a "data plane label"=20 > which is a Layer Information (LI) used by a given server=20 > layer and a "control plane label", which is a piece of=20 > information signaled between adjacent controllers for the=20 > purpose of connection provisioning. IMO the former is always=20 > a superset of the latter. Let's take, for instance,=20 > connection oriented Ethernet. MAC SA is a very important part=20 > of the data plane label because it identifies the source of=20 > the connection. However, the connection frames are forwarded=20 > according to MAC DA/VID, and hence connection ingress node,=20 > for example, needs only be signaled with this tuple by the=20 > downstream neighbor, hence the control plane label is MAC=20 > DA/VID (or just VID, for those who like the idea of the VID=20 > cross-connects architecture). > =20 > So, IMO IEEE should be responsible for the definition of data=20 > plane labels, while CCAMP for control plane labels. > =20 > Cheers, > Igor=20 >=20 >=20 > neil.2.harrison@bt.com wrote: >=20 > Dimitri wrote 07 September 2007 16:36 in response to Adrian=20 > =09 > > >=20 > > > This is also something we would expect to describe within > > > CCAMP although=20 > > > "what is a label" would come to us from the data plane=20 > > specification. > >=20 > > do i interpreet correctly your statement that if the=20 > > specification that CCAMP is going to receive from IEEE does=20 > > not speak about "label" and its encoding there will be no=20 > > place to discuss any "label processing" and "label=20 > > distribution" protocol in IETF - being domain-wide or=20 > link-local > > - > >=20 > > in that case, isn't the .1Q specification outside scope of=20 > > this effort since not referring - as of today at least - to=20 > > any "label" semantic as part of the Ethernet frame header=20 > > information field ? > >=20 > > thanks, > > -d. > =09 > What do you think a MAC DA, MAC SA and VID are? These=20 > are all 'labels'. > =09 > You also have to remember that the nature of the labels=20 > required in a > traffic unit are determined by the type of the network=20 > mode one is > dealing with. > =09 > In the co-cs and co-ps modes we have a construction known as a > 'connection'. This implies specific architectural=20 > requirements....but > the most significant, for this discussion at least, is=20 > that a connection > must have a single source. What this means is that one=20 > does not have to > incorporate a SA label in a co mode traffic=20 > unit....under defect-free > conditions it is redundant information as the=20 > connection itself provides > the source information. {Compare this to the cl-ps mode=20 > which does not > have connections...here having a SA in the traffic unit=20 > is essential} > =09 > Ergo why co-cs and co-ps mode technologies to date that=20 > respect the > requirements of a connection have only focussed on=20 > incorporating a DA > (forwarding) label. Further, these forwarding labels=20 > only need to be > distinct in resolving some number (N say) of different=20 > client layer > (link-connection) instances within a server layer=20 > (network connection) > resource partition. However, there are advantages from=20 > having both a SA > and DA label in a co-ps traffic unit that are network=20 > unique and not > just link-connection unique (ie not swapped)....the=20 > inherent robustness > under misconnectivity defects (without any adjunct OAM=20 > flow) is one of > these. And of course, these are the nature of the=20 > native labels one > already gets in Ethernet due to its cl-ps mode origins.=20 > So why would > one even contemplate not using these since they are=20 > already there? > =09 > The VID label is slightly different in that one can=20 > consider it as a > 'route discriminator label' and a local extension to=20 > the SA or DA, ie it > provides the ability to identify disjoint paths between=20 > nodal end > points. > =09 > The mere fact IEEE may not refer to the above=20 > quantities as 'labels' > does not change the fact that this is what they are. So=20 > I'm not clear > what your real point is here. > =09 > regards, Neil > =09 > =09 >=20 >=20 > ________________________________ >=20 > Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge=20 > ions/222> to see what's on, when.=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 08 Sep 2007 02:39:59 +0000 Message-ID: <067401c7f19a$a0755490$0302a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: liaison to IETF (ccamp, MPLS, BFD, PWE3, and L3VPN) on MFA Forum MPLS ICI Date: Fri, 7 Sep 2007 22:57:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, Here is another liaison from the MFA Forum. This one asks for our review of a new specification, but gives no deadline for the review. See the liaison and the specification at www.olddog.co.uk/ccamp.htm Cheers, Adrian ----- Original Message ----- From: "J. Rao Cherukuri" To: ; ; ; ; ; "Ronald Bonica" ; "Stewart Bryant (stbryant)" ; ; ; ; "George Swallow (swallow)" ; "Loa Andersson" Cc: "Ross Callon" ; ; ; "David Sinicrope (RL/TNT)" ; ; "Bocci, Matthew (Matthew)" ; "J. Rao Cherukuri" ; Sent: Friday, September 07, 2007 1:28 AM Subject: liaison to IETF (ccamp, MPLS, BFD, PWE3, and L3VPN) on MFA Forum MPLS ICI Dear All, The MFA Forum is currently working on an MPLS Inter-Carrier Interconnect (MPLS-ICI) specification to support IP VPNs, MPLS Pseudo Wires, Data Trunks, and VoIP. This specification is being driven by the MFA Forum service provider members. The objective of this Technical Specification is to enable a set of MPLS services, across administrative domains operated by different carriers. The MPLS ICI is a bi-directional IP-MPLS logical link between an Autonomous System Border Router (ASBR) in one service provider network and an ASBR in another service provider network. This document is targeted to equipment vendors to specify the necessary ASBR requirements and to service providers to provide guidance on how to use these capabilities. This document uses protocols developed in appropriate standard bodies (e.g., IETF, ITU) where applicable. This document is in our first level ballot procedure. Please review and provide comments. Thank you for your consideration of this matter. Cordially, David Sinicrope, A&D Chair, MFA Forum Rao Cherukuri Chairman, MFA Forum Technical Committee (draft MPLS ICI) Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Sep 2007 21:59:35 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=NI6v1U2c0lMJxzf/VLSFlED/8B0KiBag29kv7+9TxayHt3tVJoVNHT0f2WyrP7XH1rcJB1MYrT8qJDxvnkD8YnPSXm93hzHvrlKI5d1yqVGtF5Z54ngMh79wa4Ee5pKjWuEQajiG2a2QWrsw7B5eOK2B+8rrd/AbkQZxnd3n/6g=; Date: Fri, 7 Sep 2007 14:58:42 -0700 (PDT) From: Igor Bryskin Subject: RE: Closing the GELS Mailing List To: neil.2.harrison@bt.com, Dimitri.Papadimitriou@alcatel-lucent.be, adrian@olddog.co.uk, zali@cisco.com, Attila.Takacs@ericsson.com, ccamp@ops.ietf.org, gels@rtg.ietf.org Cc: rcallon@juniper.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-303205946-1189202322=:36343" Content-Transfer-Encoding: 8bit Message-ID: <93117.36343.qm@web36802.mail.mud.yahoo.com> --0-303205946-1189202322=:36343 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I fully understand what are saying and I think we are in agreement here: I am not saying that SA is unimportant, quite on the contrary. What I am saying is that SA is not a label in the CP signaling sense, rather, it is a property that is signaled in the opposite direction compared to one the label is signaled (like bandwidth, link affinities, etc.) Igor neil.2.harrison@bt.com wrote: Message Hi Igor, I'd disagree with you for the reasons I attempted to explain to Dimitri, ie depends on the network mode....in the cl-ps mode the SA *label* is pretty important. The only reason we have usually not traditionally incorporated a SA label in co mode network traffic units is that, under misconnectivity defect-free conditions, it is redundant information...the connection itself provides that information. However, there are important benefits to be had from having a SA in each/every traffic unit, and if these are already there 'for free' then it would be sheer folly not to recognise them for what they are and use them. regards, Neil...have great weekend yourself, I'm signing off now. -----Original Message----- From: Igor Bryskin [mailto:i_bryskin@yahoo.com] Sent: 07 September 2007 22:33 To: Harrison,N,Neil,JCGA1 R; Dimitri.Papadimitriou@alcatel-lucent.be; adrian@olddog.co.uk; zali@cisco.com; Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org Cc: rcallon@juniper.net Subject: RE: Closing the GELS Mailing List True, however one can argue that SA is not a label, rather a connection property that the connection ingress knows about and signales downstream (just like bandwidth, for example), while the label is something it does not know yet and needs to get it from downstream so that the downstream node could recognize frames labeled with the label and forward them accordingly. Have a great weekend. Igor neil.2.harrison@bt.com wrote: Hi Igor...I understand what you mean...and yes for *forwarding* purposes (on the assumption the requirements of a connection are met) you are right. It is, however, also important for the CP to tell the sink(s) of the connection what SA it expects to appear in the CV OAM pkts and this esp important if the co-ps mode layer network is based on the less optimal label-swapping paradigm. Of course, if we don't use label-swapping as in the case of PBB-TE then the CV function (of correct connectivity verification) appears 'for free' in each/every traffic unit....not just the OAM pkts, which are really only now required to distinguish a quiescent traffic case from a simple broken connection. regards, Neil -----Original Message----- From: Igor Bryskin [mailto:i_bryskin@yahoo.com] Sent: 07 September 2007 20:21 To: Harrison,N,Neil,JCGA1 R; Dimitri.Papadimitriou@alcatel-lucent.be; adrian@olddog.co.uk; zali@cisco.com; Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org Cc: rcallon@juniper.net Subject: RE: Closing the GELS Mailing List Hi Neil, I think there is a difference between a "data plane label" which is a Layer Information (LI) used by a given server layer and a "control plane label", which is a piece of information signaled between adjacent controllers for the purpose of connection provisioning. IMO the former is always a superset of the latter. Let's take, for instance, connection oriented Ethernet. MAC SA is a very important part of the data plane label because it identifies the source of the connection. However, the connection frames are forwarded according to MAC DA/VID, and hence connection ingress node, for example, needs only be signaled with this tuple by the downstream neighbor, hence the control plane label is MAC DA/VID (or just VID, for those who like the idea of the VID cross-connects architecture). So, IMO IEEE should be responsible for the definition of data plane labels, while CCAMP for control plane labels. Cheers, Igor neil.2.harrison@bt.com wrote: Dimitri wrote 07 September 2007 16:36 in response to Adrian > > > > This is also something we would expect to describe within > > CCAMP although > > "what is a label" would come to us from the data plane > specification. > > do i interpreet correctly your statement that if the > specification that CCAMP is going to receive from IEEE does > not speak about "label" and its encoding there will be no > place to discuss any "label processing" and "label > distribution" protocol in IETF - being domain-wide or link-local > - > > in that case, isn't the .1Q specification outside scope of > this effort since not referring - as of today at least - to > any "label" semantic as part of the Ethernet frame header > information field ? > > thanks, > -d. What do you think a MAC DA, MAC SA and VID are? These are all 'labels'. You also have to remember that the nature of the labels required in a traffic unit are determined by the type of the network mode one is dealing with. In the co-cs and co-ps modes we have a construction known as a 'connection'. This implies specific architectural requirements....but the most significant, for this discussion at least, is that a connection must have a single source. What this means is that one does not have to incorporate a SA label in a co mode traffic unit....under defect-free conditions it is redundant information as the connection itself provides the source information. {Compare this to the cl-ps mode which does not have connections...here having a SA in the traffic unit is essential} Ergo why co-cs and co-ps mode technologies to date that respect the requirements of a connection have only focussed on incorporating a DA (forwarding) label. Further, these forwarding labels only need to be distinct in resolving some number (N say) of different client layer (link-connection) instances within a server layer (network connection) resource partition. However, there are advantages from having both a SA and DA label in a co-ps traffic unit that are network unique and not just link-connection unique (ie not swapped)....the inherent robustness under misconnectivity defects (without any adjunct OAM flow) is one of these. And of course, these are the nature of the native labels one already gets in Ethernet due to its cl-ps mode origins. So why would one even contemplate not using these since they are already there? The VID label is slightly different in that one can consider it as a 'route discriminator label' and a local extension to the SA or DA, ie it provides the ability to identify disjoint paths between nodal end points. The mere fact IEEE may not refer to the above quantities as 'labels' does not change the fact that this is what they are. So I'm not clear what your real point is here. regards, Neil --------------------------------- Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when. --------------------------------- Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. --------------------------------- Shape Yahoo! in your own image. Join our Network Research Panel today! --0-303205946-1189202322=:36343 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I fully understand what are saying and I think we are in agreement here: I am not saying that SA is unimportant, quite on the contrary. What I am saying is that SA is not a label in the CP signaling sense, rather, it is a property that is signaled in the opposite direction compared to one the label is signaled (like bandwidth, link affinities, etc.)

    Igor

    neil.2.harrison@bt.com wrote:
    Message
    Hi Igor, I'd disagree with you for the reasons I attempted to explain to Dimitri, ie depends on the network mode....in the cl-ps mode the SA *label* is pretty important.  The only reason we have usually not traditionally incorporated a SA label in co mode network traffic units is that, under misconnectivity defect-free conditions, it is redundant information...the connection itself provides that information.  However, there are important benefits to be had from having a SA in each/every traffic unit, and if these are already there 'for free' then it would be sheer folly not to recognise them for what they are and use them.
     
    regards, Neil...have great weekend yourself, I'm signing off now.
    -----Original Message-----
    From: Igor Bryskin [mailto:i_bryskin@yahoo.com]
    Sent: 07 September 2007 22:33
    To: Harrison,N,Neil,JCGA1 R; Dimitri.Papadimitriou@alcatel-lucent.be; adrian@olddog.co.uk; zali@cisco.com; Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org
    Cc: rcallon@juniper.net
    Subject: RE: Closing the GELS Mailing List

    True, however one can argue that SA is not a label, rather a connection property that the connection ingress knows about and signales downstream (just like bandwidth, for example), while the label is something it does not know yet and needs to get it from downstream so that the downstream node could recognize frames labeled with the label and forward them accordingly.

    Have a great weekend.
    Igor

    neil.2.harrison@bt.com wrote:
    Hi Igor...I understand what you mean...and yes for *forwarding* purposes (on the assumption the requirements of a connection are met) you are right.  It is, however, also important for the CP to tell the sink(s) of the connection what SA it expects to appear in the CV OAM pkts and this esp important if the co-ps mode layer network is based on the less optimal label-swapping paradigm.  Of course, if we don't use label-swapping as in the case of PBB-TE then the CV function (of correct connectivity verification) appears 'for free' in each/every traffic unit....not just the OAM pkts, which are really only now required to distinguish a quiescent traffic case from a simple broken connection.
     
    regards, Neil
    -----Original Message-----
    From: Igor Bryskin [mailto:i_bryskin@yahoo.com]
    Sent: 07 September 2007 20:21
    To: Harrison,N,Neil,JCGA1 R; Dimitri.Papadimitriou@alcatel-lucent.be; adrian@olddog.co.uk; zali@cisco.com; Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org
    Cc: rcallon@juniper.net
    Subject: RE: Closing the GELS Mailing List

    Hi Neil,
    I think there is a difference between a "data plane label" which is a Layer Information (LI) used by a given server layer and a "control plane label", which is a piece of information signaled between adjacent controllers for the purpose of connection provisioning. IMO the former is always a superset of the latter. Let's take, for instance, connection oriented Ethernet. MAC SA is a very important part of the data plane label because it identifies the source of the connection. However, the connection frames are forwarded according to MAC DA/VID, and hence connection ingress node, for example, needs only be signaled with this tuple by the downstream neighbor, hence the control plane label is MAC DA/VID (or just VID, for those who like the idea of the VID cross-connects architecture).
    So, IMO IEEE should be responsible for the definition of data plane labels, while CCAMP for control plane labels.
    Cheers,
    Igor


    neil.2.harrison@bt.com wrote:
    Dimitri wrote 07 September 2007 16:36 in response to Adrian

    > >
    > > This is also something we would expect to describe within
    > > CCAMP although
    > > "what is a label" would come to us from the data plane
    > specification.
    >
    > do i interpreet correctly your statement that if the
    > specification that CCAMP is going to receive from IEEE does
    > not speak about "label" and its encoding there will be no
    > place to discuss any "label processing" and "label
    > distribution" protocol in IETF - being domain-wide or link-local
    > -
    >
    > in that case, isn't the .1Q specification outside scope of
    > this effort since not referring - as of today at least - to
    > any "label" semantic as part of the Ethernet frame header
    > information field ?
    >
    > thanks,
    > -d.

    What do you think a MAC DA, MAC SA and VID are? These are all 'labels'.

    You also have to remember that the nature of the labels required in a
    traffic unit are determined by the type of the network mode one is
    dealing with.

    In the co-cs and co-ps modes we have a construction known as a
    'connection'. This implies specific architectural requirements....but
    the most significant, for this discussion at least, is that a connection
    must have a single source. What this means is that one does not have to
    incorporate a SA label in a co mode traffic unit....under defect-free
    conditions it is redundant information as the connection itself provides
    the source information. {Compare this to the cl-ps mode which does not
    have connections...here having a SA in the traffic unit is essential}

    Ergo why co-cs and co-ps mode technologies to date that respect the
    requirements of a connection have only focussed on incorporating a DA
    (forwarding) label. Further, these forwarding labels only need to be
    distinct in resolving some number (N say) of different client layer
    (link-connection) instances within a server layer (network connection)
    resource partition. However, there are advantages from having both a SA
    and DA label in a co-ps traffic unit that are network unique and not
    just link-connection unique (ie not swapped)....the inherent robustness
    under misconnectivity defects (without any adjunct OAM flow) is one of
    these. And of course, these are the nature of the native labels one
    already gets in Ethernet due to its cl-ps mode origins. So why would
    one even contemplate not using these since they are already there?

    The VID label is slightly different in that one can consider it as a
    'route discriminator label' and a local extension to the SA or DA, ie it
    provides the ability to identify disjoint paths between nodal end
    points.

    The mere fact IEEE may not refer to the above quantities as 'labels'
    does not change the fact that this is what they are. So I'm not clear
    what your real point is here.

    regards, Neil



    Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when.


    Yahoo! oneSearch: Finally, mobile search that gives answers, not web links.


    Shape Yahoo! in your own image. Join our Network Research Panel today! --0-303205946-1189202322=:36343-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Sep 2007 21:43:01 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F198.02B4D2B3" Subject: RE: Closing the GELS Mailing List Date: Fri, 7 Sep 2007 22:42:27 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C0106EDE0@E03MVB2-UKBR.domain1.systemhost.net> Thread-Topic: Closing the GELS Mailing List Thread-Index: AcfxlqknD8rstOxnQgqub0LmpWd5LgAAFLWw From: To: , , , , , , Cc: This is a multi-part message in MIME format. ------_=_NextPart_001_01C7F198.02B4D2B3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Igor, I'd disagree with you for the reasons I attempted to explain to Dimitri, ie depends on the network mode....in the cl-ps mode the SA *label* is pretty important. The only reason we have usually not traditionally incorporated a SA label in co mode network traffic units is that, under misconnectivity defect-free conditions, it is redundant information...the connection itself provides that information. However, there are important benefits to be had from having a SA in each/every traffic unit, and if these are already there 'for free' then it would be sheer folly not to recognise them for what they are and use them. =20 regards, Neil...have great weekend yourself, I'm signing off now. -----Original Message----- From: Igor Bryskin [mailto:i_bryskin@yahoo.com]=20 Sent: 07 September 2007 22:33 To: Harrison,N,Neil,JCGA1 R; Dimitri.Papadimitriou@alcatel-lucent.be; adrian@olddog.co.uk; zali@cisco.com; Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org Cc: rcallon@juniper.net Subject: RE: Closing the GELS Mailing List True, however one can argue that SA is not a label, rather a connection property that the connection ingress knows about and signales downstream (just like bandwidth, for example), while the label is something it does not know yet and needs to get it from downstream so that the downstream node could recognize frames labeled with the label and forward them accordingly. Have a great weekend. Igor neil.2.harrison@bt.com wrote:=20 Hi Igor...I understand what you mean...and yes for *forwarding* purposes (on the assumption the requirements of a connection are met) you are right. It is, however, also important for the CP to tell the sink(s) of the connection what SA it expects to appear in the CV OAM pkts and this esp important if the co-ps mode layer network is based on the less optimal label-swapping paradigm. Of course, if we don't use label-swapping as in the case of PBB-TE then the CV function (of correct connectivity verification) appears 'for free' in each/every traffic unit....not just the OAM pkts, which are really only now required to distinguish a quiescent traffic case from a simple broken connection. =20 regards, Neil -----Original Message----- From: Igor Bryskin [mailto:i_bryskin@yahoo.com]=20 Sent: 07 September 2007 20:21 To: Harrison,N,Neil,JCGA1 R; Dimitri.Papadimitriou@alcatel-lucent.be; adrian@olddog.co.uk; zali@cisco.com; Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org Cc: rcallon@juniper.net Subject: RE: Closing the GELS Mailing List Hi Neil, I think there is a difference between a "data plane label" which is a Layer Information (LI) used by a given server layer and a "control plane label", which is a piece of information signaled between adjacent controllers for the purpose of connection provisioning. IMO the former is always a superset of the latter. Let's take, for instance, connection oriented Ethernet. MAC SA is a very important part of the data plane label because it identifies the source of the connection. However, the connection frames are forwarded according to MAC DA/VID, and hence connection ingress node, for example, needs only be signaled with this tuple by the downstream neighbor, hence the control plane label is MAC DA/VID (or just VID, for those who like the idea of the VID cross-connects architecture). So, IMO IEEE should be responsible for the definition of data plane labels, while CCAMP for control plane labels. Cheers, Igor=20 neil.2.harrison@bt.com wrote:=20 Dimitri wrote 07 September 2007 16:36 in response to Adrian=20 > >=20 > > This is also something we would expect to describe within > > CCAMP although=20 > > "what is a label" would come to us from the data plane=20 > specification. >=20 > do i interpreet correctly your statement that if the=20 > specification that CCAMP is going to receive from IEEE does=20 > not speak about "label" and its encoding there will be no=20 > place to discuss any "label processing" and "label=20 > distribution" protocol in IETF - being domain-wide or link-local > - >=20 > in that case, isn't the .1Q specification outside scope of=20 > this effort since not referring - as of today at least - to=20 > any "label" semantic as part of the Ethernet frame header=20 > information field ? >=20 > thanks, > -d. What do you think a MAC DA, MAC SA and VID are? These are all 'labels'. You also have to remember that the nature of the labels required in a traffic unit are determined by the type of the network mode one is dealing with. In the co-cs and co-ps modes we have a construction known as a 'connection'. This implies specific architectural requirements....but the most significant, for this discussion at least, is that a connection must have a single source. What this means is that one does not have to incorporate a SA label in a co mode traffic unit....under defect-free conditions it is redundant information as the connection itself provides the source information. {Compare this to the cl-ps mode which does not have connections...here having a SA in the traffic unit is essential} Ergo why co-cs and co-ps mode technologies to date that respect the requirements of a connection have only focussed on incorporating a DA (forwarding) label. Further, these forwarding labels only need to be distinct in resolving some number (N say) of different client layer (link-connection) instances within a server layer (network connection) resource partition. However, there are advantages from having both a SA and DA label in a co-ps traffic unit that are network unique and not just link-connection unique (ie not swapped)....the inherent robustness under misconnectivity defects (without any adjunct OAM flow) is one of these. And of course, these are the nature of the native labels one already gets in Ethernet due to its cl-ps mode origins. So why would one even contemplate not using these since they are already there? The VID label is slightly different in that one can consider it as a 'route discriminator label' and a local extension to the SA or DA, ie it provides the ability to identify disjoint paths between nodal end points. The mere fact IEEE may not refer to the above quantities as 'labels' does not change the fact that this is what they are. So I'm not clear what your real point is here. regards, Neil _____ =20 Sick sense of humor? Visit Yahoo! TV's Comedy = with an Edge to see what's on, when.=20 _____ =20 Yahoo! oneSearch: Finally, mobile search that gives answers, not web links.=20 ------_=_NextPart_001_01C7F198.02B4D2B3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
    Hi Igor, I'd disagree with you for the reasons I attempted to = explain to=20 Dimitri, ie depends on the network mode....in the cl-ps mode the SA = *label* is=20 pretty important.  The only reason we have usually not = traditionally=20 incorporated a SA label in co mode network traffic units is that, under=20 misconnectivity defect-free conditions, it is redundant = information...the=20 connection itself provides that information.  However, there are = important=20 benefits to be had from having a SA in each/every traffic unit, and if = these are=20 already there 'for free' then it would be sheer folly not to recognise = them for=20 what they are and use them.
     
    regards, Neil...have great weekend yourself, I'm signing off=20 now.
    -----Original Message-----
    From: Igor = Bryskin=20 [mailto:i_bryskin@yahoo.com]
    Sent: 07 September 2007=20 22:33
    To: Harrison,N,Neil,JCGA1 R;=20 Dimitri.Papadimitriou@alcatel-lucent.be; adrian@olddog.co.uk; = zali@cisco.com;=20 Attila.Takacs@ericsson.com; ccamp@ops.ietf.org;=20 gels@rtg.ietf.org
    Cc: rcallon@juniper.net
    Subject: = RE:=20 Closing the GELS Mailing List

    True, however one = can argue=20 that SA is not a label, rather a connection property that the = connection=20 ingress knows about and signales downstream (just like bandwidth, for=20 example), while the label is something it does not know yet and needs = to get=20 it from downstream so that the downstream node could recognize frames = labeled=20 with the label and forward them accordingly.

    Have a great=20 weekend.
    Igor

    neil.2.harrison@bt.com wrote:
    Hi Igor...I understand what you mean...and yes for = *forwarding*=20 purposes (on the assumption the requirements of a connection are = met) you=20 are right.  It is, however, also important for the CP to tell = the=20 sink(s) of the connection what SA it expects to appear in the CV OAM = pkts=20 and this esp important if the co-ps mode layer network is based on = the less=20 optimal label-swapping paradigm.  Of course, if we don't use=20 label-swapping as in the case of PBB-TE then the CV function (of = correct=20 connectivity verification) appears 'for free' in each/every traffic=20 unit....not just the OAM pkts, which are really only now required to = distinguish a quiescent traffic case from a simple broken=20 connection.
     
    regards, Neil
    -----Original Message-----
    From: = Igor Bryskin=20 [mailto:i_bryskin@yahoo.com]
    Sent: 07 September 2007=20 20:21
    To: Harrison,N,Neil,JCGA1 R;=20 Dimitri.Papadimitriou@alcatel-lucent.be; adrian@olddog.co.uk;=20 zali@cisco.com; Attila.Takacs@ericsson.com; ccamp@ops.ietf.org;=20 gels@rtg.ietf.org
    Cc: = rcallon@juniper.net
    Subject: RE:=20 Closing the GELS Mailing List

    Hi Neil,
    I think there is a difference between a = "data=20 plane label" which is a Layer Information (LI) used by a given = server=20 layer and a "control plane label", which is a piece of information = signaled between adjacent controllers for the purpose of = connection=20 provisioning. IMO the former is always a superset of the latter. = Let's=20 take, for instance, connection oriented Ethernet. MAC SA is a very = important part of the data plane label because it identifies the = source of=20 the connection. However, the connection frames are forwarded = according to=20 MAC DA/VID, and hence connection ingress node, for example, needs = only be=20 signaled with this tuple by the downstream neighbor, hence the = control=20 plane label is MAC DA/VID (or just VID, for those who like the = idea of the=20 VID cross-connects architecture).
    So, IMO IEEE should be responsible for = the=20 definition of data plane labels, while CCAMP for control plane=20 labels.
    Cheers,
    Igor=20


    neil.2.harrison@bt.com = wrote:=20
    Dimitri=20 wrote 07 September 2007 16:36 in response to Adrian=20

    > >
    > > This is also something = we would=20 expect to describe within
    > > CCAMP although
    > = >=20 "what is a label" would come to us from the data plane
    >=20 specification.
    >
    > do i interpreet correctly your = statement=20 that if the
    > specification that CCAMP is going to = receive from=20 IEEE does
    > not speak about "label" and its encoding = there will=20 be no
    > place to discuss any "label processing" and = "label=20
    > distribution" protocol in IETF - being domain-wide or=20 link-local
    > -
    >
    > in that case, isn't the = .1Q=20 specification outside scope of
    > this effort since not = referring=20 - as of today at least - to
    > any "label" semantic as = part of the=20 Ethernet frame header
    > information field ?
    > =
    >=20 thanks,
    > -d.

    What do you think a MAC DA, MAC SA = and VID=20 are? These are all 'labels'.

    You also have to remember = that the=20 nature of the labels required in a
    traffic unit are = determined by the=20 type of the network mode one is
    dealing with.

    In the = co-cs and=20 co-ps modes we have a construction known as a
    'connection'. = This=20 implies specific architectural requirements....but
    the most=20 significant, for this discussion at least, is that a = connection
    must=20 have a single source. What this means is that one does not have=20 to
    incorporate a SA label in a co mode traffic unit....under=20 defect-free
    conditions it is redundant information as the = connection=20 itself provides
    the source information. {Compare this to the = cl-ps=20 mode which does not
    have connections...here having a SA in = the=20 traffic unit is essential}

    Ergo why co-cs and co-ps mode=20 technologies to date that respect the
    requirements of a = connection=20 have only focussed on incorporating a DA
    (forwarding) label. = Further,=20 these forwarding labels only need to be
    distinct in resolving = some=20 number (N say) of different client layer
    (link-connection) = instances=20 within a server layer (network connection)
    resource = partition.=20 However, there are advantages from having both a SA
    and DA = label in a=20 co-ps traffic unit that are network unique and not
    just=20 link-connection unique (ie not swapped)....the inherent=20 robustness
    under misconnectivity defects (without any adjunct = OAM=20 flow) is one of
    these. And of course, these are the nature of = the=20 native labels one
    already gets in Ethernet due to its cl-ps = mode=20 origins. So why would
    one even contemplate not using these = since they=20 are already there?

    The VID label is slightly different in = that=20 one can consider it as a
    'route discriminator label' and a = local=20 extension to the SA or DA, ie it
    provides the ability to = identify=20 disjoint paths between nodal end
    points.

    The mere fact = IEEE=20 may not refer to the above quantities as 'labels'
    does not = change the=20 fact that this is what they are. So I'm not clear
    what your = real=20 point is here.

    regards, = Neil



    Sick sense of humor? Visit Yahoo! TV's Comedy=20 with an Edge to see what's on, when. =


    Yahoo! oneSearch: Finally, mobile=20 search that gives answers, not web links. = ------_=_NextPart_001_01C7F198.02B4D2B3-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Sep 2007 21:33:31 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=bNAjNAxqf7FUYelP/dimqfK8HXLNo05an8IO6UtEJeEaXfZSMl8sS1nCZcg7cdMzpqMuSOw6EZ3Z4WKeYWVLJa17OrTW6FMG18/LH7hmM5BCQjrU7LPdAAq/bZ5DhwaEUgKGBRxZt13BkHlO0fz5tlsBijnhEmS44p1As1Mpixc=; Date: Fri, 7 Sep 2007 14:32:55 -0700 (PDT) From: Igor Bryskin Subject: RE: Closing the GELS Mailing List To: neil.2.harrison@bt.com, Dimitri.Papadimitriou@alcatel-lucent.be, adrian@olddog.co.uk, zali@cisco.com, Attila.Takacs@ericsson.com, ccamp@ops.ietf.org, gels@rtg.ietf.org Cc: rcallon@juniper.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2106601530-1189200775=:97472" Content-Transfer-Encoding: 8bit Message-ID: <629295.97472.qm@web36806.mail.mud.yahoo.com> --0-2106601530-1189200775=:97472 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit True, however one can argue that SA is not a label, rather a connection property that the connection ingress knows about and signales downstream (just like bandwidth, for example), while the label is something it does not know yet and needs to get it from downstream so that the downstream node could recognize frames labeled with the label and forward them accordingly. Have a great weekend. Igor neil.2.harrison@bt.com wrote: Message Hi Igor...I understand what you mean...and yes for *forwarding* purposes (on the assumption the requirements of a connection are met) you are right. It is, however, also important for the CP to tell the sink(s) of the connection what SA it expects to appear in the CV OAM pkts and this esp important if the co-ps mode layer network is based on the less optimal label-swapping paradigm. Of course, if we don't use label-swapping as in the case of PBB-TE then the CV function (of correct connectivity verification) appears 'for free' in each/every traffic unit....not just the OAM pkts, which are really only now required to distinguish a quiescent traffic case from a simple broken connection. regards, Neil -----Original Message----- From: Igor Bryskin [mailto:i_bryskin@yahoo.com] Sent: 07 September 2007 20:21 To: Harrison,N,Neil,JCGA1 R; Dimitri.Papadimitriou@alcatel-lucent.be; adrian@olddog.co.uk; zali@cisco.com; Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org Cc: rcallon@juniper.net Subject: RE: Closing the GELS Mailing List Hi Neil, I think there is a difference between a "data plane label" which is a Layer Information (LI) used by a given server layer and a "control plane label", which is a piece of information signaled between adjacent controllers for the purpose of connection provisioning. IMO the former is always a superset of the latter. Let's take, for instance, connection oriented Ethernet. MAC SA is a very important part of the data plane label because it identifies the source of the connection. However, the connection frames are forwarded according to MAC DA/VID, and hence connection ingress node, for example, needs only be signaled with this tuple by the downstream neighbor, hence the control plane label is MAC DA/VID (or just VID, for those who like the idea of the VID cross-connects architecture). So, IMO IEEE should be responsible for the definition of data plane labels, while CCAMP for control plane labels. Cheers, Igor neil.2.harrison@bt.com wrote: Dimitri wrote 07 September 2007 16:36 in response to Adrian > > > > This is also something we would expect to describe within > > CCAMP although > > "what is a label" would come to us from the data plane > specification. > > do i interpreet correctly your statement that if the > specification that CCAMP is going to receive from IEEE does > not speak about "label" and its encoding there will be no > place to discuss any "label processing" and "label > distribution" protocol in IETF - being domain-wide or link-local > - > > in that case, isn't the .1Q specification outside scope of > this effort since not referring - as of today at least - to > any "label" semantic as part of the Ethernet frame header > information field ? > > thanks, > -d. What do you think a MAC DA, MAC SA and VID are? These are all 'labels'. You also have to remember that the nature of the labels required in a traffic unit are determined by the type of the network mode one is dealing with. In the co-cs and co-ps modes we have a construction known as a 'connection'. This implies specific architectural requirements....but the most significant, for this discussion at least, is that a connection must have a single source. What this means is that one does not have to incorporate a SA label in a co mode traffic unit....under defect-free conditions it is redundant information as the connection itself provides the source information. {Compare this to the cl-ps mode which does not have connections...here having a SA in the traffic unit is essential} Ergo why co-cs and co-ps mode technologies to date that respect the requirements of a connection have only focussed on incorporating a DA (forwarding) label. Further, these forwarding labels only need to be distinct in resolving some number (N say) of different client layer (link-connection) instances within a server layer (network connection) resource partition. However, there are advantages from having both a SA and DA label in a co-ps traffic unit that are network unique and not just link-connection unique (ie not swapped)....the inherent robustness under misconnectivity defects (without any adjunct OAM flow) is one of these. And of course, these are the nature of the native labels one already gets in Ethernet due to its cl-ps mode origins. So why would one even contemplate not using these since they are already there? The VID label is slightly different in that one can consider it as a 'route discriminator label' and a local extension to the SA or DA, ie it provides the ability to identify disjoint paths between nodal end points. The mere fact IEEE may not refer to the above quantities as 'labels' does not change the fact that this is what they are. So I'm not clear what your real point is here. regards, Neil --------------------------------- Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when. --------------------------------- Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. --0-2106601530-1189200775=:97472 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit True, however one can argue that SA is not a label, rather a connection property that the connection ingress knows about and signales downstream (just like bandwidth, for example), while the label is something it does not know yet and needs to get it from downstream so that the downstream node could recognize frames labeled with the label and forward them accordingly.

    Have a great weekend.
    Igor

    neil.2.harrison@bt.com wrote:
    Message
    Hi Igor...I understand what you mean...and yes for *forwarding* purposes (on the assumption the requirements of a connection are met) you are right.  It is, however, also important for the CP to tell the sink(s) of the connection what SA it expects to appear in the CV OAM pkts and this esp important if the co-ps mode layer network is based on the less optimal label-swapping paradigm.  Of course, if we don't use label-swapping as in the case of PBB-TE then the CV function (of correct connectivity verification) appears 'for free' in each/every traffic unit....not just the OAM pkts, which are really only now required to distinguish a quiescent traffic case from a simple broken connection.
     
    regards, Neil
    -----Original Message-----
    From: Igor Bryskin [mailto:i_bryskin@yahoo.com]
    Sent: 07 September 2007 20:21
    To: Harrison,N,Neil,JCGA1 R; Dimitri.Papadimitriou@alcatel-lucent.be; adrian@olddog.co.uk; zali@cisco.com; Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org
    Cc: rcallon@juniper.net
    Subject: RE: Closing the GELS Mailing List

    Hi Neil,
    I think there is a difference between a "data plane label" which is a Layer Information (LI) used by a given server layer and a "control plane label", which is a piece of information signaled between adjacent controllers for the purpose of connection provisioning. IMO the former is always a superset of the latter. Let's take, for instance, connection oriented Ethernet. MAC SA is a very important part of the data plane label because it identifies the source of the connection. However, the connection frames are forwarded according to MAC DA/VID, and hence connection ingress node, for example, needs only be signaled with this tuple by the downstream neighbor, hence the control plane label is MAC DA/VID (or just VID, for those who like the idea of the VID cross-connects architecture).
    So, IMO IEEE should be responsible for the definition of data plane labels, while CCAMP for control plane labels.
    Cheers,
    Igor


    neil.2.harrison@bt.com wrote:
    Dimitri wrote 07 September 2007 16:36 in response to Adrian

    > >
    > > This is also something we would expect to describe within
    > > CCAMP although
    > > "what is a label" would come to us from the data plane
    > specification.
    >
    > do i interpreet correctly your statement that if the
    > specification that CCAMP is going to receive from IEEE does
    > not speak about "label" and its encoding there will be no
    > place to discuss any "label processing" and "label
    > distribution" protocol in IETF - being domain-wide or link-local
    > -
    >
    > in that case, isn't the .1Q specification outside scope of
    > this effort since not referring - as of today at least - to
    > any "label" semantic as part of the Ethernet frame header
    > information field ?
    >
    > thanks,
    > -d.

    What do you think a MAC DA, MAC SA and VID are? These are all 'labels'.

    You also have to remember that the nature of the labels required in a
    traffic unit are determined by the type of the network mode one is
    dealing with.

    In the co-cs and co-ps modes we have a construction known as a
    'connection'. This implies specific architectural requirements....but
    the most significant, for this discussion at least, is that a connection
    must have a single source. What this means is that one does not have to
    incorporate a SA label in a co mode traffic unit....under defect-free
    conditions it is redundant information as the connection itself provides
    the source information. {Compare this to the cl-ps mode which does not
    have connections...here having a SA in the traffic unit is essential}

    Ergo why co-cs and co-ps mode technologies to date that respect the
    requirements of a connection have only focussed on incorporating a DA
    (forwarding) label. Further, these forwarding labels only need to be
    distinct in resolving some number (N say) of different client layer
    (link-connection) instances within a server layer (network connection)
    resource partition. However, there are advantages from having both a SA
    and DA label in a co-ps traffic unit that are network unique and not
    just link-connection unique (ie not swapped)....the inherent robustness
    under misconnectivity defects (without any adjunct OAM flow) is one of
    these. And of course, these are the nature of the native labels one
    already gets in Ethernet due to its cl-ps mode origins. So why would
    one even contemplate not using these since they are already there?

    The VID label is slightly different in that one can consider it as a
    'route discriminator label' and a local extension to the SA or DA, ie it
    provides the ability to identify disjoint paths between nodal end
    points.

    The mere fact IEEE may not refer to the above quantities as 'labels'
    does not change the fact that this is what they are. So I'm not clear
    what your real point is here.

    regards, Neil



    Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when.


    Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. --0-2106601530-1189200775=:97472-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Sep 2007 21:16:18 +0000 Message-ID: <054301c7f17e$88545530$0302a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "PAPADIMITRIOU Dimitri" , Subject: Re: Closing the GELS Mailing List Date: Fri, 7 Sep 2007 19:40:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi Dimitri, >>> beside the fact that there is an assumption on what >>> label means and how it is represented in data plane >> >> This is also something we would expect to describe within >> CCAMP although "what is a label" would come to us from >> the data plane specification. > > do i interpreet correctly your statement that if the specification > that CCAMP is going to receive from IEEE does not speak > about "label" and its encoding there will be no place to discuss > any "label processing" and "label distribution" protocol in IETF > - being domain-wide or link-local I expect the IEEE specification to define the forwarding paradigm. For example: Frames in 802.1Qay are forwarded based on the checksum value carried in the frame. I expect us to build a GMPLS solution that can be used to configure/install that forwarding paradigm. If (for example) the destination MAC is the forwarding trigger, and the destination MAC is also intended to have genuine network-wide scope and identify the recipient of the frame to the whole network, then the label is (by definition) network-scoped. > in that case, isn't the .1Q specification outside scope of this effort > since not referring - as of today at least - to any "label" semantic as > part of the Ethernet frame header information field ? No. That is like saying that TDM and lambda were out of scope for GMPLS because their definitions didn't refer to labels. The point is that a label is the identifier by which traffic on an interface may be identified for forwarding. The data plane spec should indicate what that identifier is, and we call that a label and have to pass it around in signaling. I have no idea whether that means that the .1Q spec is in scope or not. A Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Sep 2007 20:56:45 +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: Closing the GELS Mailing List Date: Fri, 7 Sep 2007 21:55:07 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C0106EDD6@E03MVB2-UKBR.domain1.systemhost.net> Thread-Topic: Closing the GELS Mailing List Thread-Index: AcfxLW80ieuPuOItQ0mTVyeeZdSmJAANdDTwAASP4EAAATdYkAAA1EUA From: To: , , , , , Cc: OK, thanks. I tend to take my cues from the unified modelling work where I can see (and challenge if need be) the logical derivation of how labelling and resource partitioning work in each network mode....I don't see that degree of rigour in the shorter statement below. Is there something technically incorrect in what I stated previously? regards, Neil > -----Original Message----- > From: PAPADIMITRIOU Dimitri > [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20 > Sent: 07 September 2007 19:23 > To: Harrison,N,Neil,JCGA1 R; adrian@olddog.co.uk;=20 > zali@cisco.com; Attila.Takacs@ericsson.com;=20 > ccamp@ops.ietf.org; gels@rtg.ietf.org > Cc: rcallon@juniper.net > Subject: RE: Closing the GELS Mailing List >=20 >=20 > point is: >=20 > whether the ethernet frame header fields can be interpreted > as "labels" that follows label switching rules applicable to=20 > an LSR and what are the implications on forwarding component=20 > behaviour when considering such "label encoding" >=20 >=20 > note: per 3031 a label is: a short fixed length physically > contiguous identifier which is used to identify a FEC,=20 > usually of local significance.=20 > =20 > -d. > > -----Original Message----- > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > Sent: Friday, September 07, 2007 8:07 PM > > To: PAPADIMITRIOU Dimitri; adrian@olddog.co.uk; > > zali@cisco.com; Attila.Takacs@ericsson.com;=20 > > ccamp@ops.ietf.org; gels@rtg.ietf.org > > Cc: rcallon@juniper.net > > Subject: RE: Closing the GELS Mailing List > >=20 > > Dimitri wrote 07 September 2007 16:36 in response to Adrian > > >=20 > > > >=20 > > > > This is also something we would expect to describe within CCAMP > > > > although "what is a label" would come to us from the data plane > > > specification. > > >=20 > > > do i interpreet correctly your statement that if the specification > > > that CCAMP is going to receive from IEEE does not speak about=20 > > > "label" and its encoding there will be no place to discuss any=20 > > > "label processing" and "label distribution" protocol in IETF -=20 > > > being domain-wide or link-local > > > - > > >=20 > > > in that case, isn't the .1Q specification outside scope of this=20 > > > effort since not referring - as of today at least - to any "label" > > > semantic as part of the Ethernet frame header information field ? > > >=20 > > > thanks, > > > -d. > >=20 > > What do you think a MAC DA, MAC SA and VID are? These are all=20 > > 'labels'. > >=20 > > You also have to remember that the nature of the labels > required in a > > traffic unit are determined by the type of the network mode one is > > dealing with. > >=20 > > In the co-cs and co-ps modes we have a construction known as a > > 'connection'. This implies specific architectural=20 > requirements....but > > the most significant, for this discussion at least, is that a > > connection must have a single source. What this means is that one=20 > > does not have to > > incorporate a SA label in a co mode traffic unit....under=20 > defect-free > > conditions it is redundant information as the connection > > itself provides > > the source information. {Compare this to the cl-ps mode=20 > > which does not > > have connections...here having a SA in the traffic unit is=20 > essential} > >=20 > > Ergo why co-cs and co-ps mode technologies to date that respect the > > requirements of a connection have only focussed on=20 > incorporating a DA > > (forwarding) label. Further, these forwarding labels only > need to be > > distinct in resolving some number (N say) of different client layer > > (link-connection) instances within a server layer (network > connection) > > resource partition. However, there are advantages from > having both a > > SA and DA label in a co-ps traffic unit that are network unique and > > not just link-connection unique (ie not swapped)....the inherent > > robustness > > under misconnectivity defects (without any adjunct OAM=20 > flow) is one of > > these. And of course, these are the nature of the native labels one > > already gets in Ethernet due to its cl-ps mode origins. So > why would > > one even contemplate not using these since they are already there? > >=20 > > The VID label is slightly different in that one can > consider it as a > > 'route discriminator label' and a local extension to the SA > or DA, ie > > it provides the ability to identify disjoint paths between nodal end > > points. > >=20 > > The mere fact IEEE may not refer to the above quantities as > 'labels' > > does not change the fact that this is what they are. So > I'm not clear > > what your real point is here. > >=20 > > regards, Neil > >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Sep 2007 20:56:37 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F191.665EE1C3" Subject: RE: Closing the GELS Mailing List Date: Fri, 7 Sep 2007 21:54:51 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C0106EDD5@E03MVB2-UKBR.domain1.systemhost.net> Thread-Topic: Closing the GELS Mailing List Thread-Index: AcfxhEuTFFhWytl+TVC9R5M3ZflIdwAB08YQ From: To: , , , , , , Cc: This is a multi-part message in MIME format. ------_=_NextPart_001_01C7F191.665EE1C3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Igor...I understand what you mean...and yes for *forwarding* purposes (on the assumption the requirements of a connection are met) you are right. It is, however, also important for the CP to tell the sink(s) of the connection what SA it expects to appear in the CV OAM pkts and this esp important if the co-ps mode layer network is based on the less optimal label-swapping paradigm. Of course, if we don't use label-swapping as in the case of PBB-TE then the CV function (of correct connectivity verification) appears 'for free' in each/every traffic unit....not just the OAM pkts, which are really only now required to distinguish a quiescent traffic case from a simple broken connection. =20 regards, Neil -----Original Message----- From: Igor Bryskin [mailto:i_bryskin@yahoo.com]=20 Sent: 07 September 2007 20:21 To: Harrison,N,Neil,JCGA1 R; Dimitri.Papadimitriou@alcatel-lucent.be; adrian@olddog.co.uk; zali@cisco.com; Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org Cc: rcallon@juniper.net Subject: RE: Closing the GELS Mailing List Hi Neil, I think there is a difference between a "data plane label" which is a Layer Information (LI) used by a given server layer and a "control plane label", which is a piece of information signaled between adjacent controllers for the purpose of connection provisioning. IMO the former is always a superset of the latter. Let's take, for instance, connection oriented Ethernet. MAC SA is a very important part of the data plane label because it identifies the source of the connection. However, the connection frames are forwarded according to MAC DA/VID, and hence connection ingress node, for example, needs only be signaled with this tuple by the downstream neighbor, hence the control plane label is MAC DA/VID (or just VID, for those who like the idea of the VID cross-connects architecture). So, IMO IEEE should be responsible for the definition of data plane labels, while CCAMP for control plane labels. Cheers, Igor=20 neil.2.harrison@bt.com wrote:=20 Dimitri wrote 07 September 2007 16:36 in response to Adrian=20 > >=20 > > This is also something we would expect to describe within > > CCAMP although=20 > > "what is a label" would come to us from the data plane=20 > specification. >=20 > do i interpreet correctly your statement that if the=20 > specification that CCAMP is going to receive from IEEE does=20 > not speak about "label" and its encoding there will be no=20 > place to discuss any "label processing" and "label=20 > distribution" protocol in IETF - being domain-wide or link-local > - >=20 > in that case, isn't the .1Q specification outside scope of=20 > this effort since not referring - as of today at least - to=20 > any "label" semantic as part of the Ethernet frame header=20 > information field ? >=20 > thanks, > -d. What do you think a MAC DA, MAC SA and VID are? These are all 'labels'. You also have to remember that the nature of the labels required in a traffic unit are determined by the type of the network mode one is dealing with. In the co-cs and co-ps modes we have a construction known as a 'connection'. This implies specific architectural requirements....but the most significant, for this discussion at least, is that a connection must have a single source. What this means is that one does not have to incorporate a SA label in a co mode traffic unit....under defect-free conditions it is redundant information as the connection itself provides the source information. {Compare this to the cl-ps mode which does not have connections...here having a SA in the traffic unit is essential} Ergo why co-cs and co-ps mode technologies to date that respect the requirements of a connection have only focussed on incorporating a DA (forwarding) label. Further, these forwarding labels only need to be distinct in resolving some number (N say) of different client layer (link-connection) instances within a server layer (network connection) resource partition. However, there are advantages from having both a SA and DA label in a co-ps traffic unit that are network unique and not just link-connection unique (ie not swapped)....the inherent robustness under misconnectivity defects (without any adjunct OAM flow) is one of these. And of course, these are the nature of the native labels one already gets in Ethernet due to its cl-ps mode origins. So why would one even contemplate not using these since they are already there? The VID label is slightly different in that one can consider it as a 'route discriminator label' and a local extension to the SA or DA, ie it provides the ability to identify disjoint paths between nodal end points. The mere fact IEEE may not refer to the above quantities as 'labels' does not change the fact that this is what they are. So I'm not clear what your real point is here. regards, Neil _____ =20 Sick sense of humor? Visit Yahoo! TV's Comedy = with an Edge to see what's on, when.=20 ------_=_NextPart_001_01C7F191.665EE1C3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
    Hi Igor...I understand what you mean...and yes for *forwarding* = purposes=20 (on the assumption the requirements of a connection are met) you are=20 right.  It is, however, also important for the CP to tell the = sink(s) of=20 the connection what SA it expects to appear in the CV OAM pkts and this = esp=20 important if the co-ps mode layer network is based on the less optimal=20 label-swapping paradigm.  Of course, if we don't use label-swapping = as in=20 the case of PBB-TE then the CV function (of correct connectivity = verification)=20 appears 'for free' in each/every traffic unit....not just the OAM pkts, = which=20 are really only now required to distinguish a quiescent traffic case = from a=20 simple broken connection.
     
    regards, Neil
    -----Original Message-----
    From: Igor = Bryskin=20 [mailto:i_bryskin@yahoo.com]
    Sent: 07 September 2007=20 20:21
    To: Harrison,N,Neil,JCGA1 R;=20 Dimitri.Papadimitriou@alcatel-lucent.be; adrian@olddog.co.uk; = zali@cisco.com;=20 Attila.Takacs@ericsson.com; ccamp@ops.ietf.org;=20 gels@rtg.ietf.org
    Cc: rcallon@juniper.net
    Subject: = RE:=20 Closing the GELS Mailing List

    Hi Neil,
    I think there is a difference between a = "data plane=20 label" which is a Layer Information (LI) used by a given server layer = and a=20 "control plane label", which is a piece of information signaled = between=20 adjacent controllers for the purpose of connection provisioning. IMO = the=20 former is always a superset of the latter. Let's take, for instance,=20 connection oriented Ethernet. MAC SA is a very important part of the = data=20 plane label because it identifies the source of the connection. = However, the=20 connection frames are forwarded according to MAC DA/VID, and hence = connection=20 ingress node, for example, needs only be signaled with this tuple by = the=20 downstream neighbor, hence the control plane label is MAC DA/VID (or = just VID,=20 for those who like the idea of the VID cross-connects=20 architecture).
    So, IMO IEEE should be responsible for the = definition=20 of data plane labels, while CCAMP for control plane = labels.
    Cheers,
    Igor=20


    neil.2.harrison@bt.com wrote:=20
    Dimitri=20 wrote 07 September 2007 16:36 in response to Adrian =

    >=20 >
    > > This is also something we would expect to = describe=20 within
    > > CCAMP although
    > > "what is a label" = would=20 come to us from the data plane
    > specification.
    > =
    > do i=20 interpreet correctly your statement that if the
    > = specification that=20 CCAMP is going to receive from IEEE does
    > not speak about = "label"=20 and its encoding there will be no
    > place to discuss any = "label=20 processing" and "label
    > distribution" protocol in IETF - = being=20 domain-wide or link-local
    > -
    >
    > in that case, = isn't the=20 .1Q specification outside scope of
    > this effort since not = referring=20 - as of today at least - to
    > any "label" semantic as part of = the=20 Ethernet frame header
    > information field ?
    >
    >=20 thanks,
    > -d.

    What do you think a MAC DA, MAC SA and = VID are?=20 These are all 'labels'.

    You also have to remember that the = nature of=20 the labels required in a
    traffic unit are determined by the type = of the=20 network mode one is
    dealing with.

    In the co-cs and co-ps = modes we=20 have a construction known as a
    'connection'. This implies = specific=20 architectural requirements....but
    the most significant, for this=20 discussion at least, is that a connection
    must have a single = source. What=20 this means is that one does not have to
    incorporate a SA label in = a co=20 mode traffic unit....under defect-free
    conditions it is redundant = information as the connection itself provides
    the source = information.=20 {Compare this to the cl-ps mode which does not
    have = connections...here=20 having a SA in the traffic unit is essential}

    Ergo why co-cs = and=20 co-ps mode technologies to date that respect the
    requirements of = a=20 connection have only focussed on incorporating a DA
    (forwarding) = label.=20 Further, these forwarding labels only need to be
    distinct in = resolving=20 some number (N say) of different client layer
    (link-connection) = instances=20 within a server layer (network connection)
    resource partition. = However,=20 there are advantages from having both a SA
    and DA label in a = co-ps=20 traffic unit that are network unique and not
    just link-connection = unique=20 (ie not swapped)....the inherent robustness
    under misconnectivity = defects=20 (without any adjunct OAM flow) is one of
    these. And of course, = these are=20 the nature of the native labels one
    already gets in Ethernet due = to its=20 cl-ps mode origins. So why would
    one even contemplate not using = these=20 since they are already there?

    The VID label is slightly = different in=20 that one can consider it as a
    'route discriminator label' and a = local=20 extension to the SA or DA, ie it
    provides the ability to identify = disjoint paths between nodal end
    points.

    The mere fact = IEEE may=20 not refer to the above quantities as 'labels'
    does not change the = fact=20 that this is what they are. So I'm not clear
    what your real point = is=20 here.

    regards, Neil



    Sick sense of humor? Visit Yahoo! TV's Comedy=20 with an Edge to see what's on, when. ------_=_NextPart_001_01C7F191.665EE1C3-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Sep 2007 20:00:27 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Closing the GELS Mailing List Date: Fri, 7 Sep 2007 21:59:20 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E38001321463@FRVELSMBS22.ad2.ad.alcatel.com> Thread-Topic: Closing the GELS Mailing List thread-index: AcfxLW80ieuPuOItQ0mTVyeeZdSmJAANdDTwAASP4EAAATdYkAABD4IQAAF0v+A= From: "PAPADIMITRIOU Dimitri" To: "Don Fedyk" , , , , , , Cc: don,=20 interesting 3 years ago you blaim me on the same list when i quoted this definition when discussing applicability of GMPLS to Ethernet ;-) the evolution of Ethernet forwarding components themselves leads to an open issue today compared to the situation we observed a couple of years ago. if this would not be true one would have not seen since this definition has been written end 2000 in rfc3945 that there has been lot's efforts in various bodies involved in Ethernet to incorporate as part of that technology properties that would facilitate Ethernet network operations -- and this due to its expected applicability in environments for which that technology has not been initially designed for -- and this is whole point actually (*) back to the point: when that definition was written down it was understood that adding GMPLS control plane to an Ethernet fowarding plane would lead to address such expectations. nevertheless, we ack'ed since the GELS BoF (held by Loa and myself) in 2005 that the "combination" would be possible if one of the following conditions hold - IEEE provides a data plane spec. that allows accommodating the fwd'ing behaviour determined by GMPLS (and all related routing paradigms) - IEEE ack's that some if its header's field can be processed equivalently to a per-platform/link-local switching "label" with all its resulting implications (if fact the answer was never totally clear at the end) - GMPLS evolves to sustain all control modes connectionless fwd'ing would allow (this option was not even discussed) =20 =3D> hence, the question remains open. i would love to see progress on that matter (at least that IEEE tells us yes or no) but for the time being we're left with unilateral interpretations that are blocking real progress from the std perspective (the problem is mainly not technical ... it is the problem that CCAMP faces each time its prefered control plane protocol suite tries to cover a technology) =20 (*) it was felt 2 or 3 years ago that operators could help and provide us with their expectation in that respect but no real outcome came out of various tentatives to obtain such type of operational feedback > -----Original Message----- > From: Don Fedyk [mailto:dwfedyk@nortel.com]=20 > Sent: Friday, September 07, 2007 8:47 PM > To: PAPADIMITRIOU Dimitri; neil.2.harrison@bt.com;=20 > adrian@olddog.co.uk; zali@cisco.com;=20 > Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org > Cc: rcallon@juniper.net > Subject: RE: Closing the GELS Mailing List >=20 > Dmitri=20 >=20 > Quoting from GMPLS RFC 3945 seems far more applicable given we are > talking a Generalized label switch router (LSR). >=20 > "2. Layer-2 Switch Capable (L2SC) interfaces: >=20 > 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 > Don=20 >=20 > -----Original Message----- >=20 > point is:=20 >=20 > whether the ethernet frame header fields can be interpreted=20 > as "labels" > that follows label switching rules applicable to an LSR and=20 > what are the > implications on forwarding component behaviour when considering such > "label encoding" >=20 >=20 > note: per 3031 a label is: a short fixed length physically contiguous > identifier which is used to identify a FEC, usually of local > significance.=20 > =20 > -d. > > -----Original Message----- > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 > > Sent: Friday, September 07, 2007 8:07 PM > > To: PAPADIMITRIOU Dimitri; adrian@olddog.co.uk;=20 > > zali@cisco.com; Attila.Takacs@ericsson.com;=20 > > ccamp@ops.ietf.org; gels@rtg.ietf.org > > Cc: rcallon@juniper.net > > Subject: RE: Closing the GELS Mailing List > >=20 > > Dimitri wrote 07 September 2007 16:36 in response to Adrian=20 > > >=20 > > > >=20 > > > > This is also something we would expect to describe within > > > > CCAMP although=20 > > > > "what is a label" would come to us from the data plane=20 > > > specification. > > >=20 > > > do i interpreet correctly your statement that if the=20 > > > specification that CCAMP is going to receive from IEEE does=20 > > > not speak about "label" and its encoding there will be no=20 > > > place to discuss any "label processing" and "label=20 > > > distribution" protocol in IETF - being domain-wide or link-local > > > - > > >=20 > > > in that case, isn't the .1Q specification outside scope of=20 > > > this effort since not referring - as of today at least - to=20 > > > any "label" semantic as part of the Ethernet frame header=20 > > > information field ? > > >=20 > > > thanks, > > > -d. > >=20 > > What do you think a MAC DA, MAC SA and VID are? These are=20 > > all 'labels'. > >=20 > > You also have to remember that the nature of the labels=20 > required in a > > traffic unit are determined by the type of the network mode one is > > dealing with. > >=20 > > In the co-cs and co-ps modes we have a construction known as a > > 'connection'. This implies specific architectural=20 > requirements....but > > the most significant, for this discussion at least, is that a=20 > > connection > > must have a single source. What this means is that one does=20 > > not have to > > incorporate a SA label in a co mode traffic unit....under=20 > defect-free > > conditions it is redundant information as the connection=20 > > itself provides > > the source information. {Compare this to the cl-ps mode=20 > > which does not > > have connections...here having a SA in the traffic unit is=20 > essential} > >=20 > > Ergo why co-cs and co-ps mode technologies to date that respect the > > requirements of a connection have only focussed on=20 > incorporating a DA > > (forwarding) label. Further, these forwarding labels only=20 > need to be > > distinct in resolving some number (N say) of different client layer > > (link-connection) instances within a server layer (network=20 > connection) > > resource partition. However, there are advantages from=20 > > having both a SA > > and DA label in a co-ps traffic unit that are network unique and not > > just link-connection unique (ie not swapped)....the inherent=20 > > robustness > > under misconnectivity defects (without any adjunct OAM=20 > flow) is one of > > these. And of course, these are the nature of the native labels one > > already gets in Ethernet due to its cl-ps mode origins. So=20 > why would > > one even contemplate not using these since they are already there? > >=20 > > The VID label is slightly different in that one can consider it as a > > 'route discriminator label' and a local extension to the SA=20 > > or DA, ie it > > provides the ability to identify disjoint paths between nodal end > > points. > >=20 > > The mere fact IEEE may not refer to the above quantities as 'labels' > > does not change the fact that this is what they are. So=20 > I'm not clear > > what your real point is here. > >=20 > > regards, Neil > >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Sep 2007 19:32:21 +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: Closing the GELS Mailing List Date: Fri, 7 Sep 2007 21:28:32 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E3800132145A@FRVELSMBS22.ad2.ad.alcatel.com> Thread-Topic: Closing the GELS Mailing List thread-index: Acfxfo1FWPWaKkHtTI6n07oaVlXTmgAA7BrA From: "PAPADIMITRIOU Dimitri" To: "Adrian Farrel" , , hi adrian, > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Sent: Friday, September 07, 2007 8:40 PM > To: PAPADIMITRIOU Dimitri; ccamp@ops.ietf.org > Subject: Re: Closing the GELS Mailing List >=20 > Hi Dimitri, >=20 > >>> beside the fact that there is an assumption on what > >>> label means and how it is represented in data plane > >> > >> This is also something we would expect to describe within > >> CCAMP although "what is a label" would come to us from > >> the data plane specification. > > > > do i interpreet correctly your statement that if the specification > > that CCAMP is going to receive from IEEE does not speak > > about "label" and its encoding there will be no place to discuss > > any "label processing" and "label distribution" protocol in IETF > > - being domain-wide or link-local >=20 > I expect the IEEE specification to define the forwarding paradigm. >=20 > For example: Frames in 802.1Qay are forwarded based on the=20 > checksum value > carried in the frame. >=20 > I expect us to build a GMPLS solution that can be used to=20 > configure/install > that forwarding paradigm. >=20 > If (for example) the destination MAC is the forwarding=20 > trigger, and the > destination MAC is also intended to have genuine network-wide=20 > scope and > identify the recipient of the frame to the whole network,=20 > then the label is > (by definition) network-scoped. >=20 > > in that case, isn't the .1Q specification outside scope of=20 > this effort > > since not referring - as of today at least - to any "label"=20 > semantic as > > part of the Ethernet frame header information field ? >=20 > No. That is like saying that TDM and lambda were out of scope=20 > for GMPLS because their definitions didn't refer to labels. we were confronted to that problem a couple of years ago. the difference with techno's that do not encode label in the "data plane" is that in the present case, the forwarding itself was label value dependent > The point is that a label is the identifier by which traffic=20 > on an interface > may be identified for forwarding. The data plane spec should=20 > indicate what > that identifier is, and we call that a label and have to pass=20 > it around in > signaling. this is already an extended version of a classical label def. now, speaking about "label" switching router induces a behaviour that was not felt "respectful" to the operations of an Ethernet switch. it was felt that the control plane was constraining the fwd'ing plane - in brief, the point was incorporating a source-initiated explicitly routed data path establishment (with or without the associated resource reservation) was inducing behaviour not currently supported by the Ethernet forwarding component - the reason for maintaining the GELS list at that time was explicitly to maintain a place where such discussion could happen > I have no idea whether that means that the .1Q spec is in=20 > scope or not. independently of this i think we're entering the discussion that was the key reason why efforts did not succeed... .1Q spec did not change since then in order to accommodate this. there is a simple hope that another ongoing effort would allow for such kind of behaviour. > A >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Sep 2007 19:22:37 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=OD1D2jvPCKagDP8ATAdRy+JU4Et6XhFmz+SZQF9ImvwzUe0Jvs0vXbIXS6QbU9ARNIgKAQ7clagYsrrJNoCGcDrKmyV+TkMkIzgpE66+65ytozj8rQegwpaDIH/z+skHQu8MfQExCMhZRw/s4uvNzdjDDprCebB9tWZB4pTk5/c=; Date: Fri, 7 Sep 2007 12:21:21 -0700 (PDT) From: Igor Bryskin Subject: RE: Closing the GELS Mailing List To: neil.2.harrison@bt.com, Dimitri.Papadimitriou@alcatel-lucent.be, adrian@olddog.co.uk, zali@cisco.com, Attila.Takacs@ericsson.com, ccamp@ops.ietf.org, gels@rtg.ietf.org Cc: rcallon@juniper.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1020572678-1189192881=:59428" Content-Transfer-Encoding: 8bit Message-ID: <150025.59428.qm@web36811.mail.mud.yahoo.com> --0-1020572678-1189192881=:59428 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Neil, I think there is a difference between a "data plane label" which is a Layer Information (LI) used by a given server layer and a "control plane label", which is a piece of information signaled between adjacent controllers for the purpose of connection provisioning. IMO the former is always a superset of the latter. Let's take, for instance, connection oriented Ethernet. MAC SA is a very important part of the data plane label because it identifies the source of the connection. However, the connection frames are forwarded according to MAC DA/VID, and hence connection ingress node, for example, needs only be signaled with this tuple by the downstream neighbor, hence the control plane label is MAC DA/VID (or just VID, for those who like the idea of the VID cross-connects architecture). So, IMO IEEE should be responsible for the definition of data plane labels, while CCAMP for control plane labels. Cheers, Igor neil.2.harrison@bt.com wrote: Dimitri wrote 07 September 2007 16:36 in response to Adrian > > > > This is also something we would expect to describe within > > CCAMP although > > "what is a label" would come to us from the data plane > specification. > > do i interpreet correctly your statement that if the > specification that CCAMP is going to receive from IEEE does > not speak about "label" and its encoding there will be no > place to discuss any "label processing" and "label > distribution" protocol in IETF - being domain-wide or link-local > - > > in that case, isn't the .1Q specification outside scope of > this effort since not referring - as of today at least - to > any "label" semantic as part of the Ethernet frame header > information field ? > > thanks, > -d. What do you think a MAC DA, MAC SA and VID are? These are all 'labels'. You also have to remember that the nature of the labels required in a traffic unit are determined by the type of the network mode one is dealing with. In the co-cs and co-ps modes we have a construction known as a 'connection'. This implies specific architectural requirements....but the most significant, for this discussion at least, is that a connection must have a single source. What this means is that one does not have to incorporate a SA label in a co mode traffic unit....under defect-free conditions it is redundant information as the connection itself provides the source information. {Compare this to the cl-ps mode which does not have connections...here having a SA in the traffic unit is essential} Ergo why co-cs and co-ps mode technologies to date that respect the requirements of a connection have only focussed on incorporating a DA (forwarding) label. Further, these forwarding labels only need to be distinct in resolving some number (N say) of different client layer (link-connection) instances within a server layer (network connection) resource partition. However, there are advantages from having both a SA and DA label in a co-ps traffic unit that are network unique and not just link-connection unique (ie not swapped)....the inherent robustness under misconnectivity defects (without any adjunct OAM flow) is one of these. And of course, these are the nature of the native labels one already gets in Ethernet due to its cl-ps mode origins. So why would one even contemplate not using these since they are already there? The VID label is slightly different in that one can consider it as a 'route discriminator label' and a local extension to the SA or DA, ie it provides the ability to identify disjoint paths between nodal end points. The mere fact IEEE may not refer to the above quantities as 'labels' does not change the fact that this is what they are. So I'm not clear what your real point is here. regards, Neil --------------------------------- Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when. --0-1020572678-1189192881=:59428 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
    Hi Neil,
     
    I think there is a difference between a "data plane label" which is a Layer Information (LI) used by a given server layer and a "control plane label", which is a piece of information signaled between adjacent controllers for the purpose of connection provisioning. IMO the former is always a superset of the latter. Let's take, for instance, connection oriented Ethernet. MAC SA is a very important part of the data plane label because it identifies the source of the connection. However, the connection frames are forwarded according to MAC DA/VID, and hence connection ingress node, for example, needs only be signaled with this tuple by the downstream neighbor, hence the control plane label is MAC DA/VID (or just VID, for those who like the idea of the VID cross-connects architecture).
     
    So, IMO IEEE should be responsible for the definition of data plane labels, while CCAMP for control plane labels.
     
    Cheers,
    Igor


    neil.2.harrison@bt.com wrote:
    Dimitri wrote 07 September 2007 16:36 in response to Adrian

    > >
    > > This is also something we would expect to describe within
    > > CCAMP although
    > > "what is a label" would come to us from the data plane
    > specification.
    >
    > do i interpreet correctly your statement that if the
    > specification that CCAMP is going to receive from IEEE does
    > not speak about "label" and its encoding there will be no
    > place to discuss any "label processing" and "label
    > distribution" protocol in IETF - being domain-wide or link-local
    > -
    >
    > in that case, isn't the .1Q specification outside scope of
    > this effort since not referring - as of today at least - to
    > any "label" semantic as part of the Ethernet frame header
    > information field ?
    >
    > thanks,
    > -d.

    What do you think a MAC DA, MAC SA and VID are? These are all 'labels'.

    You also have to remember that the nature of the labels required in a
    traffic unit are determined by the type of the network mode one is
    dealing with.

    In the co-cs and co-ps modes we have a construction known as a
    'connection'. This implies specific architectural requirements....but
    the most significant, for this discussion at least, is that a connection
    must have a single source. What this means is that one does not have to
    incorporate a SA label in a co mode traffic unit....under defect-free
    conditions it is redundant information as the connection itself provides
    the source information. {Compare this to the cl-ps mode which does not
    have connections...here having a SA in the traffic unit is essential}

    Ergo why co-cs and co-ps mode technologies to date that respect the
    requirements of a connection have only focussed on incorporating a DA
    (forwarding) label. Further, these forwarding labels only need to be
    distinct in resolving some number (N say) of different client layer
    (link-connection) instances within a server layer (network connection)
    resource partition. However, there are advantages from having both a SA
    and DA label in a co-ps traffic unit that are network unique and not
    just link-connection unique (ie not swapped)....the inherent robustness
    under misconnectivity defects (without any adjunct OAM flow) is one of
    these. And of course, these are the nature of the native labels one
    already gets in Ethernet due to its cl-ps mode origins. So why would
    one even contemplate not using these since they are already there?

    The VID label is slightly different in that one can consider it as a
    'route discriminator label' and a local extension to the SA or DA, ie it
    provides the ability to identify disjoint paths between nodal end
    points.

    The mere fact IEEE may not refer to the above quantities as 'labels'
    does not change the fact that this is what they are. So I'm not clear
    what your real point is here.

    regards, Neil



    Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when. --0-1020572678-1189192881=:59428-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Sep 2007 18:47:56 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Closing the GELS Mailing List Date: Fri, 7 Sep 2007 14:46:53 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4113DA7B3@zrtphxm2.corp.nortel.com> Thread-Topic: Closing the GELS Mailing List thread-index: AcfxLW80ieuPuOItQ0mTVyeeZdSmJAANdDTwAASP4EAAATdYkAABD4IQ From: "Don Fedyk" To: "PAPADIMITRIOU Dimitri" , , , , , , Cc: Dmitri=20 Quoting from GMPLS RFC 3945 seems far more applicable given we are talking a Generalized label switch router (LSR). "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. " Don=20 -----Original Message----- point is:=20 whether the ethernet frame header fields can be interpreted as "labels" that follows label switching rules applicable to an LSR and what are the implications on forwarding component behaviour when considering such "label encoding" note: per 3031 a label is: a short fixed length physically contiguous identifier which is used to identify a FEC, usually of local significance.=20 =20 -d. > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 > Sent: Friday, September 07, 2007 8:07 PM > To: PAPADIMITRIOU Dimitri; adrian@olddog.co.uk;=20 > zali@cisco.com; Attila.Takacs@ericsson.com;=20 > ccamp@ops.ietf.org; gels@rtg.ietf.org > Cc: rcallon@juniper.net > Subject: RE: Closing the GELS Mailing List >=20 > Dimitri wrote 07 September 2007 16:36 in response to Adrian >=20 > > >=20 > > > This is also something we would expect to describe within > > > CCAMP although=20 > > > "what is a label" would come to us from the data plane=20 > > specification. > >=20 > > do i interpreet correctly your statement that if the=20 > > specification that CCAMP is going to receive from IEEE does=20 > > not speak about "label" and its encoding there will be no=20 > > place to discuss any "label processing" and "label=20 > > distribution" protocol in IETF - being domain-wide or link-local > > - > >=20 > > in that case, isn't the .1Q specification outside scope of=20 > > this effort since not referring - as of today at least - to=20 > > any "label" semantic as part of the Ethernet frame header=20 > > information field ? > >=20 > > thanks, > > -d. >=20 > What do you think a MAC DA, MAC SA and VID are? These are=20 > all 'labels'. >=20 > You also have to remember that the nature of the labels required in a > traffic unit are determined by the type of the network mode one is > dealing with. >=20 > In the co-cs and co-ps modes we have a construction known as a > 'connection'. This implies specific architectural requirements....but > the most significant, for this discussion at least, is that a=20 > connection > must have a single source. What this means is that one does=20 > not have to > incorporate a SA label in a co mode traffic unit....under defect-free > conditions it is redundant information as the connection=20 > itself provides > the source information. {Compare this to the cl-ps mode=20 > which does not > have connections...here having a SA in the traffic unit is essential} >=20 > Ergo why co-cs and co-ps mode technologies to date that respect the > requirements of a connection have only focussed on incorporating a DA > (forwarding) label. Further, these forwarding labels only need to be > distinct in resolving some number (N say) of different client layer > (link-connection) instances within a server layer (network connection) > resource partition. However, there are advantages from=20 > having both a SA > and DA label in a co-ps traffic unit that are network unique and not > just link-connection unique (ie not swapped)....the inherent=20 > robustness > under misconnectivity defects (without any adjunct OAM flow) is one of > these. And of course, these are the nature of the native labels one > already gets in Ethernet due to its cl-ps mode origins. So why would > one even contemplate not using these since they are already there? >=20 > The VID label is slightly different in that one can consider it as a > 'route discriminator label' and a local extension to the SA=20 > or DA, ie it > provides the ability to identify disjoint paths between nodal end > points. >=20 > The mere fact IEEE may not refer to the above quantities as 'labels' > does not change the fact that this is what they are. So I'm not clear > what your real point is here. >=20 > regards, Neil >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Sep 2007 18:23:38 +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: Closing the GELS Mailing List Date: Fri, 7 Sep 2007 20:22:49 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E38001321453@FRVELSMBS22.ad2.ad.alcatel.com> Thread-Topic: Closing the GELS Mailing List thread-index: AcfxLW80ieuPuOItQ0mTVyeeZdSmJAANdDTwAASP4EAAATdYkA== From: "PAPADIMITRIOU Dimitri" To: , , , , , Cc: point is:=20 whether the ethernet frame header fields can be interpreted as "labels" that follows label switching rules applicable to an LSR and what are the implications on forwarding component behaviour when considering such "label encoding" note: per 3031 a label is: a short fixed length physically contiguous identifier which is used to identify a FEC, usually of local significance.=20 =20 -d. > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 > Sent: Friday, September 07, 2007 8:07 PM > To: PAPADIMITRIOU Dimitri; adrian@olddog.co.uk;=20 > zali@cisco.com; Attila.Takacs@ericsson.com;=20 > ccamp@ops.ietf.org; gels@rtg.ietf.org > Cc: rcallon@juniper.net > Subject: RE: Closing the GELS Mailing List >=20 > Dimitri wrote 07 September 2007 16:36 in response to Adrian >=20 > > >=20 > > > This is also something we would expect to describe within > > > CCAMP although=20 > > > "what is a label" would come to us from the data plane=20 > > specification. > >=20 > > do i interpreet correctly your statement that if the=20 > > specification that CCAMP is going to receive from IEEE does=20 > > not speak about "label" and its encoding there will be no=20 > > place to discuss any "label processing" and "label=20 > > distribution" protocol in IETF - being domain-wide or link-local > > - > >=20 > > in that case, isn't the .1Q specification outside scope of=20 > > this effort since not referring - as of today at least - to=20 > > any "label" semantic as part of the Ethernet frame header=20 > > information field ? > >=20 > > thanks, > > -d. >=20 > What do you think a MAC DA, MAC SA and VID are? These are=20 > all 'labels'. >=20 > You also have to remember that the nature of the labels required in a > traffic unit are determined by the type of the network mode one is > dealing with. >=20 > In the co-cs and co-ps modes we have a construction known as a > 'connection'. This implies specific architectural requirements....but > the most significant, for this discussion at least, is that a=20 > connection > must have a single source. What this means is that one does=20 > not have to > incorporate a SA label in a co mode traffic unit....under defect-free > conditions it is redundant information as the connection=20 > itself provides > the source information. {Compare this to the cl-ps mode=20 > which does not > have connections...here having a SA in the traffic unit is essential} >=20 > Ergo why co-cs and co-ps mode technologies to date that respect the > requirements of a connection have only focussed on incorporating a DA > (forwarding) label. Further, these forwarding labels only need to be > distinct in resolving some number (N say) of different client layer > (link-connection) instances within a server layer (network connection) > resource partition. However, there are advantages from=20 > having both a SA > and DA label in a co-ps traffic unit that are network unique and not > just link-connection unique (ie not swapped)....the inherent=20 > robustness > under misconnectivity defects (without any adjunct OAM flow) is one of > these. And of course, these are the nature of the native labels one > already gets in Ethernet due to its cl-ps mode origins. So why would > one even contemplate not using these since they are already there? >=20 > The VID label is slightly different in that one can consider it as a > 'route discriminator label' and a local extension to the SA=20 > or DA, ie it > provides the ability to identify disjoint paths between nodal end > points. >=20 > The mere fact IEEE may not refer to the above quantities as 'labels' > does not change the fact that this is what they are. So I'm not clear > what your real point is here. >=20 > regards, Neil >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Sep 2007 18:09:45 +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: Closing the GELS Mailing List Date: Fri, 7 Sep 2007 19:07:28 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C0106EDCA@E03MVB2-UKBR.domain1.systemhost.net> Thread-Topic: Closing the GELS Mailing List Thread-Index: AcfxLW80ieuPuOItQ0mTVyeeZdSmJAANdDTwAASP4EA= From: To: , , , , , Cc: Dimitri wrote 07 September 2007 16:36 in response to Adrian > >=20 > > This is also something we would expect to describe within > > CCAMP although=20 > > "what is a label" would come to us from the data plane=20 > specification. >=20 > do i interpreet correctly your statement that if the=20 > specification that CCAMP is going to receive from IEEE does=20 > not speak about "label" and its encoding there will be no=20 > place to discuss any "label processing" and "label=20 > distribution" protocol in IETF - being domain-wide or link-local > - >=20 > in that case, isn't the .1Q specification outside scope of=20 > this effort since not referring - as of today at least - to=20 > any "label" semantic as part of the Ethernet frame header=20 > information field ? >=20 > thanks, > -d. What do you think a MAC DA, MAC SA and VID are? These are all 'labels'. You also have to remember that the nature of the labels required in a traffic unit are determined by the type of the network mode one is dealing with. In the co-cs and co-ps modes we have a construction known as a 'connection'. This implies specific architectural requirements....but the most significant, for this discussion at least, is that a connection must have a single source. What this means is that one does not have to incorporate a SA label in a co mode traffic unit....under defect-free conditions it is redundant information as the connection itself provides the source information. {Compare this to the cl-ps mode which does not have connections...here having a SA in the traffic unit is essential} Ergo why co-cs and co-ps mode technologies to date that respect the requirements of a connection have only focussed on incorporating a DA (forwarding) label. Further, these forwarding labels only need to be distinct in resolving some number (N say) of different client layer (link-connection) instances within a server layer (network connection) resource partition. However, there are advantages from having both a SA and DA label in a co-ps traffic unit that are network unique and not just link-connection unique (ie not swapped)....the inherent robustness under misconnectivity defects (without any adjunct OAM flow) is one of these. And of course, these are the nature of the native labels one already gets in Ethernet due to its cl-ps mode origins. So why would one even contemplate not using these since they are already there? The VID label is slightly different in that one can consider it as a 'route discriminator label' and a local extension to the SA or DA, ie it provides the ability to identify disjoint paths between nodal end points. The mere fact IEEE may not refer to the above quantities as 'labels' does not change the fact that this is what they are. So I'm not clear what your real point is here. regards, Neil Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Sep 2007 15:40:02 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Closing the GELS Mailing List Date: Fri, 7 Sep 2007 17:35:41 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E380013213D5@FRVELSMBS22.ad2.ad.alcatel.com> Thread-Topic: Closing the GELS Mailing List thread-index: AcfxLW80ieuPuOItQ0mTVyeeZdSmJAANdDTw From: "PAPADIMITRIOU Dimitri" To: "Adrian Farrel" , "Zafar Ali \(zali\)" , "Attila Takacs \(IJ/ETH\)" , , "gels" Cc: "Ross Callon" =20 adrian > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Sent: Friday, September 07, 2007 10:59 AM > To: PAPADIMITRIOU Dimitri; Zafar Ali (zali); Attila Takacs=20 > (IJ/ETH); ccamp@ops.ietf.org; gels > Cc: Ross Callon > Subject: Re: Closing the GELS Mailing List >=20 > I think this thread is a representation in miniature of the issues=20 > involved... >=20 > - All the emails in this thread have been copied to both mailing lists > - All the participants in the thread are subscribed to both=20 > mailing lists >=20 > No, it doesn't cost to have both lists active. > No, it doesn't cost to have all of the threads on CCAMP. >=20 > Please note that we should not discuss the data plane. If you don't=20 > understand (or don't like, or don't want to use) the data=20 > plane you should=20 > have your discussions in private or at the IEEE. >=20 > Dimitri said... >=20 > >> - Label allocation and swapping rules > > is that not a forwarding component discussion ? >=20 > It is certainly informed by the forwarding component (i.e.=20 > the definition of=20 > the data plane), but the rules we need to define are the=20 > rules for the=20 > control plane. I.e. (and for example, only) if the forwarding=20 > plane defines=20 > that the label allocated on the upstream interface must be=20 > numerically one=20 > greater than the label allocated on the downstream interface,=20 > this rule must=20 > be referenced in the control plane specification. This is=20 > important since it=20 > is a constraint placed on the normal per-interface operation=20 > of GMPLS. That=20 > makes it CCAMP work. >=20 > > beside the fact that there is an assumption on what > > label means and how it is represented in data plane >=20 > This is also something we would expect to describe within=20 > CCAMP although=20 > "what is a label" would come to us from the data plane specification. do i interpreet correctly your statement that if the specification that CCAMP is going to receive from IEEE does not speak about "label" and its encoding there will be no place to discuss any "label processing" and "label distribution" protocol in IETF - being domain-wide or link-local - in that case, isn't the .1Q specification outside scope of this effort since not referring - as of today at least - to any "label" semantic as part of the Ethernet frame header information field ? thanks, -d. > Thanks, > Adrian=20 >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Sep 2007 15:16:29 +0000 Message-ID: <029b01c7f158$a43c9bc0$0601a8c0@pc6> Reply-To: "tom.petch" From: "tom.petch" To: "Adrian Farrel" , , "gels" Cc: "Ross Callon" Subject: Re: Closing the GELS Mailing List Date: Fri, 7 Sep 2007 12:25:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Adrian Just to break the pattern, I am not on the GELS list - never got round to it - and would be very happy to see them merged. A list should reflect a community of interest and I think that there is only one here. The work of CCAMP has a wider impact on other SDOs and liaisons form a significant part of CCAMP's work. Where GELS is different is the SDO to liaise with, but I do not see that as justification for a separate list. Tom Petch ----- Original Message ----- From: "Adrian Farrel" To: "PAPADIMITRIOU Dimitri" ; "Zafar Ali (zali)" ; "Attila Takacs (IJ/ETH)" ; ; "gels" Cc: "Ross Callon" Sent: Friday, September 07, 2007 10:59 AM Subject: Re: Closing the GELS Mailing List > I think this thread is a representation in miniature of the issues > involved... > > - All the emails in this thread have been copied to both mailing lists > - All the participants in the thread are subscribed to both mailing lists > > No, it doesn't cost to have both lists active. > No, it doesn't cost to have all of the threads on CCAMP. > > Please note that we should not discuss the data plane. If you don't > understand (or don't like, or don't want to use) the data plane you should > have your discussions in private or at the IEEE. > > Dimitri said... > > >> - Label allocation and swapping rules > > is that not a forwarding component discussion ? > > It is certainly informed by the forwarding component (i.e. the definition of > the data plane), but the rules we need to define are the rules for the > control plane. I.e. (and for example, only) if the forwarding plane defines > that the label allocated on the upstream interface must be numerically one > greater than the label allocated on the downstream interface, this rule must > be referenced in the control plane specification. This is important since it > is a constraint placed on the normal per-interface operation of GMPLS. That > makes it CCAMP work. > > > beside the fact that there is an assumption on what > > label means and how it is represented in data plane > > This is also something we would expect to describe within CCAMP although > "what is a label" would come to us from the data plane specification. > > Thanks, > Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Sep 2007 14:12:28 +0000 Message-ID: <047601c7f158$f5121ed0$0302a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Lam, Hing-Kam \(Kam\)" Subject: Re: Working Group Last Call on MLN Requirements and Evaluation Date: Fri, 7 Sep 2007 15:10:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit Remarkable! Don't trust your mailer if it comes from Microsoft! That URL showed as http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-reqs-05.txt right up until it arrive in my inbox! But you are also very welcome to book our village hall :-) Adrian ----- Original Message ----- From: "Adrian Farrel" To: Cc: "Lam, Hing-Kam (Kam)" Sent: Friday, September 07, 2007 2:55 PM Subject: Working Group Last Call on MLN Requirements and Evaluation > Hi, > > This email starts the working group last call on > > http://www.olddog.co.uk/pentredwr.htm > and > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-eval-03.txt > > This last call will include scope for review of the documents by ITU-T > SG15 Q14 during their interim meeting in Stuttgart. > > The last call will end at 12 noon GMT on 21st September 2007. > > Please send your comments by email to the CCAMP list or to the CCAMP > chairs (or by formal liaison ;-). > > Thanks, > Adrian > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Sep 2007 13:57:41 +0000 Message-ID: <046401c7f156$b7925310$0302a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Lam, Hing-Kam \(Kam\)" Subject: Working Group Last Call on MLN Requirements and Evaluation Date: Fri, 7 Sep 2007 14:55:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, This email starts the working group last call on http://www.olddog.co.uk/pentredwr.htm and http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-eval-03.txt This last call will include scope for review of the documents by ITU-T SG15 Q14 during their interim meeting in Stuttgart. The last call will end at 12 noon GMT on 21st September 2007. Please send your comments by email to the CCAMP list or to the CCAMP chairs (or by formal liaison ;-). Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Sep 2007 09:47:13 +0000 Date: Fri, 07 Sep 2007 17:46:00 +0800 From: Mach Chen Subject: Update for the "IGP extention in support of Inter-AS TE" drafts(resend for some nits in the previous email:-)) To: ccamp@ops.ietf.org Message-id: <00ea01c7f133$e6248e50$4f0c6f0a@china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_haGQROjryIU2to16pF2lnw)" Thread-index: AcfxM+WyX7x8pKOhT1SoKbic5h3v0g== This is a multi-part message in MIME format. --Boundary_(ID_haGQROjryIU2to16pF2lnw) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Hi forks, We have updated these two I-Ds since IETF 69th in Chicago, where we received a lot of useful comments and suggestion. You could reach them by the following links: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas-te-extensi on-01.txt http://www.ietf.org/internet-drafts/draft-chen-ccamp-isis-interas-te-extensi on-01.txt Compare to rev.00, the main changes in rev.01 are listed below: 1. Wording changes in several places; 2. According to Kireeti's comments, make a clear statement "There is no OSPF adjacency running on the inter-AS link"; 3. Enhance the PCE-based scenario to explain that the AS number property of an inter-AS TE link is needed, and clearly state that the AS number sub-TLV is mandatory; 4. Add the missing part about that the local ASBR SHOULD do a "proxy" advertisement for the backward of an inter-AS TE link; 5. Enhance the Security section. Any feedback and comments are welcome! Best regards, Mach --Boundary_(ID_haGQROjryIU2to16pF2lnw) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT

    Hi forks,

     

    We have updated these two I-Ds since IETF 69th in Chicago, where we received a lot of useful comments and suggestion. You could reach them by the following links:

    http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas-te-extension-01.txt

     

    http://www.ietf.org/internet-drafts/draft-chen-ccamp-isis-interas-te-extension-01.txt

     

    Compare to rev.00, the main changes in rev.01 are listed below:

     

    1. Wording changes in several places;

    2. According to Kireeti's comments, make a clear statement "There is no OSPF adjacency running on the inter-AS link";

    3. Enhance the PCE-based scenario to explain that the AS number property of an inter-AS TE link is needed, and clearly state that the AS number sub-TLV is mandatory;

    4. Add the missing part about that the local ASBR SHOULD do a "proxy" advertisement for the backward of an inter-AS TE link; 5. Enhance the Security section.

     

    Any feedback and comments are welcome!

    Best regards,

    Mach

     

    --Boundary_(ID_haGQROjryIU2to16pF2lnw)-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Sep 2007 09:23:45 +0000 Date: Fri, 07 Sep 2007 17:21:53 +0800 From: Mach Chen Subject: Update for the "IGP extention in support of Inter-AS TE" drafts To: ccamp@ops.ietf.org Message-id: <00de01c7f130$87e737f0$4f0c6f0a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcfwwuDZhXH7tKtURuC2IIrBrm8HUgAP/ARw Hi forks, We have updated these two I-Ds since IETF 69th in Chicago, where we received a lot of useful comments and suggestion. You could reach them by the following links: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas-te-extensi on-01.txt http://www.ietf.org/internet-drafts/draft-ietf-chen-isis-interas-te-extensio n-01.txt Compare to rev.00, the main changes in rev.01 are listed below: 1. Wording changes in several places; 2. According to Kireeti's comments, make a clear statement "There is no OSPF adjacency running on the inter-AS link"; 3. Enhance the PCE-based scenario to explain that the AS number property of an inter-AS TE link is needed, and clearly state that the AS number sub-TLV is mandatory; 4. Add the missing part about that the local ASBR SHOULD do a "proxy" advertisement for the backward of an inter-AS TE link; 5. Enhance the Security section. Any feedback and comments are welcome! Best regards, Mach Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Sep 2007 09:01:45 +0000 Message-ID: <039601c7f12d$69406a40$0302a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "PAPADIMITRIOU Dimitri" , "Zafar Ali \(zali\)" , "Attila Takacs \(IJ/ETH\)" , , "gels" Cc: "Ross Callon" Subject: Re: Closing the GELS Mailing List Date: Fri, 7 Sep 2007 09:59:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit I think this thread is a representation in miniature of the issues involved... - All the emails in this thread have been copied to both mailing lists - All the participants in the thread are subscribed to both mailing lists No, it doesn't cost to have both lists active. No, it doesn't cost to have all of the threads on CCAMP. Please note that we should not discuss the data plane. If you don't understand (or don't like, or don't want to use) the data plane you should have your discussions in private or at the IEEE. Dimitri said... >> - Label allocation and swapping rules > is that not a forwarding component discussion ? It is certainly informed by the forwarding component (i.e. the definition of the data plane), but the rules we need to define are the rules for the control plane. I.e. (and for example, only) if the forwarding plane defines that the label allocated on the upstream interface must be numerically one greater than the label allocated on the downstream interface, this rule must be referenced in the control plane specification. This is important since it is a constraint placed on the normal per-interface operation of GMPLS. That makes it CCAMP work. > beside the fact that there is an assumption on what > label means and how it is represented in data plane This is also something we would expect to describe within CCAMP although "what is a label" would come to us from the data plane specification. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Sep 2007 20:16:22 +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-ospf-interas-te-extension-01.txt Message-Id: Date: Thu, 06 Sep 2007 16:15:01 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : OSPF Traffic Engineering (OSPF-TE) Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Author(s) : M. Chen, R. Zhang Filename : draft-ietf-ccamp-ospf-interas-te-extension-01.txt Pages : 13 Date : 2007-9-6 This document describes extensions to the OSPF v2 and v3 Traffic Engineering (OSPF-TE) mechanisms to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering(TE) for multiple Autonomous Systems (ASes). It defines OSPF-TE extensions for the flooding of TE information about inter-AS links which can be used to perform inter-AS TE path computation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas-te-extension-01.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-ospf-interas-te-extension-01.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-ospf-interas-te-extension-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-9-6150019.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-ospf-interas-te-extension-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-ospf-interas-te-extension-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-9-6150019.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Sep 2007 18:59: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: Closing the GELS Mailing List Date: Thu, 6 Sep 2007 20:57:22 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E380012B24AF@FRVELSMBS22.ad2.ad.alcatel.com> Thread-Topic: Closing the GELS Mailing List thread-index: AcfwaKdFjH0nMrF2Tw6ZFzl7WVA5awAJ0mGgAAB7qvAAAvuP4AAFZYUw From: "PAPADIMITRIOU Dimitri" To: "Zafar Ali \(zali\)" , "Attila Takacs \(IJ/ETH\)" , "Adrian Farrel" , , "gels" Cc: "Ross Callon" zafar the main problem remains - to take a base example in its work plan Adrian mentions 2. "GMPLS control of P2P TE for PBB-TE (802.1Qay)" [...] - Label allocation and swapping rules=20 [...] is that not a forwarding component discussion ? beside the fact that there is an assumption on what label means and how it is represented in data plane thanks, -d. =20 > -----Original Message----- > From: Zafar Ali (zali) [mailto:zali@cisco.com]=20 > Sent: Thursday, September 06, 2007 5:54 PM > To: PAPADIMITRIOU Dimitri; Attila Takacs (IJ/ETH); Adrian=20 > Farrel; ccamp@ops.ietf.org; gels > Cc: Ross Callon > Subject: RE: Closing the GELS Mailing List >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org=20 > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of PAPADIMITRIOU Dimitri > > Sent: Thursday, September 06, 2007 10:27 AM > > To: Attila Takacs (IJ/ETH); Adrian Farrel; ccamp@ops.ietf.org; gels > > Cc: Ross Callon > > Subject: RE: Closing the GELS Mailing List > >=20 > > attila - yes. but CCAMP is only about "Control" - >=20 > And for interface with Standards Body owning forwarding. Not=20 > to mention > we are all "technical". What else is left?=20 >=20 > Thanks >=20 > Regards... Zafar=20 >=20 > > -d. > >=20 > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Attila=20 > > Takacs (IJ/ETH) > > > Sent: Thursday, September 06, 2007 4:25 PM > > > To: Adrian Farrel; ccamp@ops.ietf.org; gels > > > Cc: Ross Callon > > > Subject: RE: Closing the GELS Mailing List > > >=20 > > > Hi all, > > >=20 > > > I support closing the gels list.=20 > > >=20 > > > Since decoupling the discussions into "techno-specific" and GMPLS=20 > > > specific part is very difficult, if at all possible, I do=20 > > not see how=20 > > > to benefit from a separate forum for techno-specific=20 > > aspects. IMHO, it=20 > > > would be much clearer having a single forum for all related=20 > > > discussions anyway. > > >=20 > > > Best regards, > > > Attila > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: owner-ccamp@ops.ietf.org > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > > > > Sent: Thursday, September 06, 2007 11:27 AM > > > > To: ccamp@ops.ietf.org; gels > > > > Cc: Ross Callon > > > > Subject: Closing the GELS Mailing List > > > >=20 > > > > We propose to close the GELS mailing list. > > > >=20 > > > > Loa wrote... > > > >=20 > > > > > I tend to support this, but it begs two questions: > > > > > > > > > > - when will the charter update be ack'ed? > > > >=20 > > > > I don't know, and I can't promise that it will be=20 > ack'ed. but the=20 > > > > Routing ADs appear to support the change. > > > >=20 > > > > > - in the (unlikely) case where we don't get an ack for > > > > gels work the > > > > > gels-list won't be needed anyhow, so; isn't the effect of > > > > the of your > > > > > statement below that the gels-list is dead as of now?=20 > > Especially=20 > > > > > since the on thing we are discussing at the moment is > > > the charter > > > > > update and this is on the ccamp list?? > > > >=20 > > > > Absolutely. > > > >=20 > > > > I'll give you all a last chance to scream. > > > >=20 > > > > Thanks, > > > > Adrian > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > >=20 > > >=20 > >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Sep 2007 15:57:59 +0000 To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 4990 on Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org Message-Id: <20070906155527.C944BE0FBA@bosco.isi.edu> Date: Thu, 6 Sep 2007 08:55:27 -0700 (PDT) A new Request for Comments is now available in online RFC libraries. RFC 4990 Title: Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks Author: K. Shiomoto, R. Papneja, R. Rabbat Status: Informational Date: September 2007 Mailbox: shiomoto.kohei@lab.ntt.co.jp, rabbat@alum.mit.edu, rpapneja@isocore.com Pages: 23 Characters: 50908 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-gmpls-addressing-08.txt URL: http://www.rfc-editor.org/rfc/rfc4990.txt This document clarifies the use of addresses in Generalized Multiprotocol Label Switching (GMPLS) networks. The aim is to facilitate interworking of GMPLS-capable Label Switching Routers (LSRs). The document is based on experience gained in implementation, interoperability testing, and deployment. The document describes how to interpret address and identifier fields within GMPLS protocols, and how to choose which addresses to set in those fields for specific control plane usage models. It also discusses how to handle IPv6 sources and destinations in the MPLS and GMPLS Traffic Engineering (TE) Management Information Base (MIB) modules. This document does not define new procedures or processes. Whenever this document makes requirements statements or recommendations, these are taken from normative text in the referenced RFCs. This memo provides information for the Internet community. This document is a product of the Common Control and Measurement Plane Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Sep 2007 15:54:59 +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: Closing the GELS Mailing List Date: Thu, 6 Sep 2007 11:54:24 -0400 Message-ID: Thread-Topic: Closing the GELS Mailing List Thread-Index: AcfwaKdFjH0nMrF2Tw6ZFzl7WVA5awAJ0mGgAAB7qvAAAvuP4A== From: "Zafar Ali \(zali\)" To: "PAPADIMITRIOU Dimitri" , "Attila Takacs \(IJ/ETH\)" , "Adrian Farrel" , , "gels" Cc: "Ross Callon" DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2577; t=1189094061; x=1189958061; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zali@cisco.com; z=From:=20=22Zafar=20Ali=20\(zali\)=22=20 |Subject:=20RE=3A=20Closing=20the=20GELS=20Mailing=20List |Sender:=20 |To:=20=22PAPADIMITRIOU=20Dimitri=22=20,=0A=20=20=20=20=20=20=20=20=22Attila=20Takacs=20\(IJ/ETH\)=22=20,=0A=20=20=20=20=20=20=20=20=22Adrian=20Farrel=2 2=20,=20,=0A=20=20=20=20=20=20=20 =20=22gels=22=20; bh=aQvA3qMA5u0WsaYccM8NI0rmuEJCYrb4Zn18vu6rcyc=; b=Jp9LRtdsDEm+E6Cgu/5GXrN0mom6H06YsjkOHzfI4KRdY8Pc1PVHp3+Mp7i+5CuLXSybu3iv IITzmnkd2H2sasGaYqZVecKPsiDJUZVgBdHwfe/vaRfL1SYnCPmuDAQ+; Authentication-Results: rtp-dkim-1; header.From=zali@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of PAPADIMITRIOU Dimitri > Sent: Thursday, September 06, 2007 10:27 AM > To: Attila Takacs (IJ/ETH); Adrian Farrel; ccamp@ops.ietf.org; gels > Cc: Ross Callon > Subject: RE: Closing the GELS Mailing List >=20 > attila - yes. but CCAMP is only about "Control" - >=20 And for interface with Standards Body owning forwarding. Not to mention we are all "technical". What else is left?=20 Thanks Regards... Zafar=20 > -d. >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Attila=20 > Takacs (IJ/ETH) > > Sent: Thursday, September 06, 2007 4:25 PM > > To: Adrian Farrel; ccamp@ops.ietf.org; gels > > Cc: Ross Callon > > Subject: RE: Closing the GELS Mailing List > >=20 > > Hi all, > >=20 > > I support closing the gels list.=20 > >=20 > > Since decoupling the discussions into "techno-specific" and GMPLS=20 > > specific part is very difficult, if at all possible, I do=20 > not see how=20 > > to benefit from a separate forum for techno-specific=20 > aspects. IMHO, it=20 > > would be much clearer having a single forum for all related=20 > > discussions anyway. > >=20 > > Best regards, > > Attila > >=20 > >=20 > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > > > Sent: Thursday, September 06, 2007 11:27 AM > > > To: ccamp@ops.ietf.org; gels > > > Cc: Ross Callon > > > Subject: Closing the GELS Mailing List > > >=20 > > > We propose to close the GELS mailing list. > > >=20 > > > Loa wrote... > > >=20 > > > > I tend to support this, but it begs two questions: > > > > > > > > - when will the charter update be ack'ed? > > >=20 > > > I don't know, and I can't promise that it will be ack'ed. but the=20 > > > Routing ADs appear to support the change. > > >=20 > > > > - in the (unlikely) case where we don't get an ack for > > > gels work the > > > > gels-list won't be needed anyhow, so; isn't the effect of > > > the of your > > > > statement below that the gels-list is dead as of now?=20 > Especially=20 > > > > since the on thing we are discussing at the moment is > > the charter > > > > update and this is on the ccamp list?? > > >=20 > > > Absolutely. > > >=20 > > > I'll give you all a last chance to scream. > > >=20 > > > Thanks, > > > Adrian > > >=20 > > >=20 > > >=20 > > >=20 > >=20 > >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Sep 2007 15:54:53 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Closing the GELS Mailing List Date: Thu, 6 Sep 2007 11:53:14 -0400 Message-ID: Thread-Topic: Closing the GELS Mailing List Thread-Index: AcfwaJE8wbS3itLlS+ScmNci3tMldgAD569QAAZHkjAAAOoLAA== From: "Zafar Ali \(zali\)" To: "Don Fedyk" , "PAPADIMITRIOU Dimitri" , "Adrian Farrel" , , "gels" Cc: "Ross Callon" DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2723; t=1189093997; x=1189957997; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zali@cisco.com; z=From:=20=22Zafar=20Ali=20\(zali\)=22=20 |Subject:=20RE=3A=20Closing=20the=20GELS=20Mailing=20List |Sender:=20 |To:=20=22Don=20Fedyk=22=20,=0A=20=20=20=20=20=20=20= 20=22PAPADIMITRIOU=20Dimitri=22=20,=0A=20=20=20=20=20=20=20=20=22Adrian=20Farrel=22=20 ,=20,=0A=20=20=20=20=20=20=20=20=22gels=22=20; bh=LvLBrTv8gJ1vZiC45tC79sLy4VLmBeTSHTW/uGSGvj0=; b=plRMoj3k2q8e8IAPYjS/3Ws5hzCTaXofwY5q/Mo+xhrkE+ub0Sgo0xo+1O+KLvpcOi+Rvozv AAbhrmJkr73bqsx+mWqTvWWy5tWLMMM4KvGzApd/ZbE8sYOBtFQhuIvF; Authentication-Results: rtp-dkim-2; header.From=zali@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Don Fedyk > Sent: Thursday, September 06, 2007 10:41 AM > To: PAPADIMITRIOU Dimitri; Adrian Farrel; ccamp@ops.ietf.org; gels > Cc: Ross Callon > Subject: RE: Closing the GELS Mailing List >=20 > Hi Adrian >=20 > Dmitri does have a point that if there is a topic that heads=20 > into the "weeds" we could direct it to the GELS list explicitly. =20 >=20 > Is there a cost of keeping it open? Is there a cost for discussing them at CCAMP? I prefer a central place for all discussions. =20 Thanks Regards... Zafar=20 >=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: Thursday, September 06, 2007 10:00 AM > To: Adrian Farrel; ccamp@ops.ietf.org; gels > Cc: Ross Callon > Subject: RE: Closing the GELS Mailing List >=20 > adrian, >=20 > you could leave the gels list for the list for the=20 > techno-specific discussions and the ccamp list for the=20 > non-techno specific discussions >=20 > in any case, i believe the value of gels was so far to allow=20 > open discussion on a topic that was on charter=20 >=20 > -> question: does proposed incorporation in charter (with=20 > milestones to > be better shaped inline with progress of IEEE) elevate any=20 > other need ? > complete decoupling of discussion has been shown to be=20 > difficult to be realized in the past >=20 > thanks, > -dimitri. >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > > Sent: Thursday, September 06, 2007 11:27 AM > > To: ccamp@ops.ietf.org; gels > > Cc: Ross Callon > > Subject: Closing the GELS Mailing List > >=20 > > We propose to close the GELS mailing list. > >=20 > > Loa wrote... > >=20 > > > I tend to support this, but it begs two questions: > > > > > > - when will the charter update be ack'ed? > >=20 > > I don't know, and I can't promise that it will be ack'ed. but the=20 > > Routing ADs appear to support the change. > >=20 > > > - in the (unlikely) case where we don't get an ack for gels work=20 > > > the gels-list won't be needed anyhow, so; isn't the=20 > effect of the=20 > > > of your statement below that the gels-list is dead as of now?=20 > > > Especially since the on thing we are discussing at the moment is=20 > > > the charter update and this is on the ccamp list?? > >=20 > > Absolutely. > >=20 > > I'll give you all a last chance to scream. > >=20 > > Thanks, > > Adrian >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Sep 2007 15:02: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: Closing the GELS Mailing List Date: Thu, 6 Sep 2007 17:01:43 +0200 Message-ID: <53CCFDD6E346CB43994852666C210E9102067D9E@esealmw116.eemea.ericsson.se> Thread-Topic: Closing the GELS Mailing List Thread-Index: AcfwaJE8wbS3itLlS+ScmNci3tMldgAD569QAAZHkjAAANAA4A== From: "Attila Takacs (IJ/ETH)" To: "Don Fedyk" , "PAPADIMITRIOU Dimitri" , "Adrian Farrel" , , "gels" Cc: "Ross Callon" Hi Don, This sounds good, however I doubt that it can be smoothly enforced. How to determine when a discussion is to be moved to the gels list, and, maybe, when is it eligible to be moved back to ccamp? It will be difficult to follow up mixed threads. On the other hand, I suspect that most of the ccamp list members are also subscribed to the gels list so I do not really see the benefit of having two lists; expect setting different filtering rules in your mailer (well, this might be an argument enough in itself :-)) Best regards, Attila > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Don Fedyk > Sent: Thursday, September 06, 2007 4:41 PM > To: PAPADIMITRIOU Dimitri; Adrian Farrel; ccamp@ops.ietf.org; gels > Cc: Ross Callon > Subject: RE: Closing the GELS Mailing List >=20 > Hi Adrian >=20 > Dmitri does have a point that if there is a topic that heads=20 > into the "weeds" we could direct it to the GELS list explicitly. =20 >=20 > Is there a cost of keeping it open? >=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: Thursday, September 06, 2007 10:00 AM > To: Adrian Farrel; ccamp@ops.ietf.org; gels > Cc: Ross Callon > Subject: RE: Closing the GELS Mailing List >=20 > adrian, >=20 > you could leave the gels list for the list for the=20 > techno-specific discussions and the ccamp list for the=20 > non-techno specific discussions >=20 > in any case, i believe the value of gels was so far to allow=20 > open discussion on a topic that was on charter=20 >=20 > -> question: does proposed incorporation in charter (with=20 > milestones to > be better shaped inline with progress of IEEE) elevate any=20 > other need ? > complete decoupling of discussion has been shown to be=20 > difficult to be realized in the past >=20 > thanks, > -dimitri. >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > > Sent: Thursday, September 06, 2007 11:27 AM > > To: ccamp@ops.ietf.org; gels > > Cc: Ross Callon > > Subject: Closing the GELS Mailing List > >=20 > > We propose to close the GELS mailing list. > >=20 > > Loa wrote... > >=20 > > > I tend to support this, but it begs two questions: > > > > > > - when will the charter update be ack'ed? > >=20 > > I don't know, and I can't promise that it will be ack'ed. but the=20 > > Routing ADs appear to support the change. > >=20 > > > - in the (unlikely) case where we don't get an ack for gels work=20 > > > the gels-list won't be needed anyhow, so; isn't the=20 > effect of the=20 > > > of your statement below that the gels-list is dead as of now?=20 > > > Especially since the on thing we are discussing at the moment is=20 > > > the charter update and this is on the ccamp list?? > >=20 > > Absolutely. > >=20 > > I'll give you all a last chance to scream. > >=20 > > Thanks, > > Adrian >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Sep 2007 14:42:15 +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: Closing the GELS Mailing List Date: Thu, 6 Sep 2007 10:41:12 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA411396BAF@zrtphxm2.corp.nortel.com> Thread-Topic: Closing the GELS Mailing List thread-index: AcfwaJE8wbS3itLlS+ScmNci3tMldgAD569QAAZHkjA= From: "Don Fedyk" To: "PAPADIMITRIOU Dimitri" , "Adrian Farrel" , , "gels" Cc: "Ross Callon" Hi Adrian Dmitri does have a point that if there is a topic that heads into the "weeds" we could direct it to the GELS list explicitly. =20 Is there a cost of keeping it open? Regards, Don =20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of PAPADIMITRIOU Dimitri Sent: Thursday, September 06, 2007 10:00 AM To: Adrian Farrel; ccamp@ops.ietf.org; gels Cc: Ross Callon Subject: RE: Closing the GELS Mailing List adrian, you could leave the gels list for the list for the techno-specific discussions and the ccamp list for the non-techno specific discussions in any case, i believe the value of gels was so far to allow open discussion on a topic that was on charter=20 -> question: does proposed incorporation in charter (with milestones to be better shaped inline with progress of IEEE) elevate any other need ? complete decoupling of discussion has been shown to be difficult to be realized in the past thanks, -dimitri. =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Thursday, September 06, 2007 11:27 AM > To: ccamp@ops.ietf.org; gels > Cc: Ross Callon > Subject: Closing the GELS Mailing List >=20 > We propose to close the GELS mailing list. >=20 > Loa wrote... >=20 > > I tend to support this, but it begs two questions: > > > > - when will the charter update be ack'ed? >=20 > I don't know, and I can't promise that it will be ack'ed. but=20 > the Routing ADs appear to support the change. >=20 > > - in the (unlikely) case where we don't get an ack for > > gels work the gels-list won't be needed anyhow, so; > > isn't the effect of the of your statement below that > > the gels-list is dead as of now? Especially since the > > on thing we are discussing at the moment is the charter > > update and this is on the ccamp list?? >=20 > Absolutely. >=20 > I'll give you all a last chance to scream. >=20 > Thanks, > Adrian=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Sep 2007 14:27:04 +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: Closing the GELS Mailing List Date: Thu, 6 Sep 2007 16:26:42 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E380012B22ED@FRVELSMBS22.ad2.ad.alcatel.com> Thread-Topic: Closing the GELS Mailing List thread-index: AcfwaKdFjH0nMrF2Tw6ZFzl7WVA5awAJ0mGgAAB7qvA= From: "PAPADIMITRIOU Dimitri" To: "Attila Takacs \(IJ/ETH\)" , "Adrian Farrel" , , "gels" Cc: "Ross Callon" attila - yes. but CCAMP is only about "Control" - -d. > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Attila Takacs (IJ/ETH) > Sent: Thursday, September 06, 2007 4:25 PM > To: Adrian Farrel; ccamp@ops.ietf.org; gels > Cc: Ross Callon > Subject: RE: Closing the GELS Mailing List >=20 > Hi all, >=20 > I support closing the gels list.=20 >=20 > Since decoupling the discussions into "techno-specific" and GMPLS > specific part is very difficult, if at all possible, I do not=20 > see how to > benefit from a separate forum for techno-specific aspects. IMHO, it > would be much clearer having a single forum for all related=20 > discussions > anyway. >=20 > Best regards, > Attila >=20 >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org=20 > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > > Sent: Thursday, September 06, 2007 11:27 AM > > To: ccamp@ops.ietf.org; gels > > Cc: Ross Callon > > Subject: Closing the GELS Mailing List > >=20 > > We propose to close the GELS mailing list. > >=20 > > Loa wrote... > >=20 > > > I tend to support this, but it begs two questions: > > > > > > - when will the charter update be ack'ed? > >=20 > > I don't know, and I can't promise that it will be ack'ed. but=20 > > the Routing ADs appear to support the change. > >=20 > > > - in the (unlikely) case where we don't get an ack for =20 > > gels work the=20 > > > gels-list won't be needed anyhow, so; isn't the effect of=20 > > the of your=20 > > > statement below that the gels-list is dead as of now? Especially=20 > > > since the on thing we are discussing at the moment is=20 > the charter =20 > > > update and this is on the ccamp list?? > >=20 > > Absolutely. > >=20 > > I'll give you all a last chance to scream. > >=20 > > Thanks, > > Adrian=20 > >=20 > >=20 > >=20 > >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Sep 2007 14:25:20 +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: Closing the GELS Mailing List Date: Thu, 6 Sep 2007 16:24:45 +0200 Message-ID: <53CCFDD6E346CB43994852666C210E9102067D40@esealmw116.eemea.ericsson.se> Thread-Topic: Closing the GELS Mailing List Thread-Index: AcfwaKdFjH0nMrF2Tw6ZFzl7WVA5awAJ0mGg From: "Attila Takacs (IJ/ETH)" To: "Adrian Farrel" , , "gels" Cc: "Ross Callon" Hi all, I support closing the gels list.=20 Since decoupling the discussions into "techno-specific" and GMPLS specific part is very difficult, if at all possible, I do not see how to benefit from a separate forum for techno-specific aspects. IMHO, it would be much clearer having a single forum for all related discussions anyway. Best regards, Attila > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Thursday, September 06, 2007 11:27 AM > To: ccamp@ops.ietf.org; gels > Cc: Ross Callon > Subject: Closing the GELS Mailing List >=20 > We propose to close the GELS mailing list. >=20 > Loa wrote... >=20 > > I tend to support this, but it begs two questions: > > > > - when will the charter update be ack'ed? >=20 > I don't know, and I can't promise that it will be ack'ed. but=20 > the Routing ADs appear to support the change. >=20 > > - in the (unlikely) case where we don't get an ack for =20 > gels work the=20 > > gels-list won't be needed anyhow, so; isn't the effect of=20 > the of your=20 > > statement below that the gels-list is dead as of now? Especially=20 > > since the on thing we are discussing at the moment is the charter =20 > > update and this is on the ccamp list?? >=20 > Absolutely. >=20 > I'll give you all a last chance to scream. >=20 > Thanks, > Adrian=20 >=20 >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Sep 2007 14:03:03 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Closing the GELS Mailing List Date: Thu, 6 Sep 2007 15:59:47 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E380012B228B@FRVELSMBS22.ad2.ad.alcatel.com> Thread-Topic: Closing the GELS Mailing List thread-index: AcfwaJE8wbS3itLlS+ScmNci3tMldgAD569Q From: "PAPADIMITRIOU Dimitri" To: "Adrian Farrel" , , "gels" Cc: "Ross Callon" adrian, you could leave the gels list for the list for the techno-specific discussions and the ccamp list for the non-techno specific discussions in any case, i believe the value of gels was so far to allow open discussion on a topic that was on charter=20 -> question: does proposed incorporation in charter (with milestones to be better shaped inline with progress of IEEE) elevate any other need ? complete decoupling of discussion has been shown to be difficult to be realized in the past thanks, -dimitri. =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Thursday, September 06, 2007 11:27 AM > To: ccamp@ops.ietf.org; gels > Cc: Ross Callon > Subject: Closing the GELS Mailing List >=20 > We propose to close the GELS mailing list. >=20 > Loa wrote... >=20 > > I tend to support this, but it begs two questions: > > > > - when will the charter update be ack'ed? >=20 > I don't know, and I can't promise that it will be ack'ed. but=20 > the Routing ADs appear to support the change. >=20 > > - in the (unlikely) case where we don't get an ack for > > gels work the gels-list won't be needed anyhow, so; > > isn't the effect of the of your statement below that > > the gels-list is dead as of now? Especially since the > > on thing we are discussing at the moment is the charter > > update and this is on the ccamp list?? >=20 > Absolutely. >=20 > I'll give you all a last chance to scream. >=20 > Thanks, > Adrian=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Sep 2007 09:30:15 +0000 Message-ID: <020501c7f068$270d0c20$0302a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , "gels" Cc: "Ross Callon" Subject: Closing the GELS Mailing List Date: Thu, 6 Sep 2007 10:27:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit We propose to close the GELS mailing list. Loa wrote... > I tend to support this, but it begs two questions: > > - when will the charter update be ack'ed? I don't know, and I can't promise that it will be ack'ed. but the Routing ADs appear to support the change. > - in the (unlikely) case where we don't get an ack for > gels work the gels-list won't be needed anyhow, so; > isn't the effect of the of your statement below that > the gels-list is dead as of now? Especially since the > on thing we are discussing at the moment is the charter > update and this is on the ccamp list?? Absolutely. I'll give you all a last chance to scream. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Sep 2007 15:34:16 +0000 Message-ID: <46DECC02.4070502@kddilabs.jp> Date: Thu, 06 Sep 2007 00:32:18 +0900 From: Kenji Kumaki User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Adrian Farrel Cc: ccamp@ops.ietf.org Subject: Re: Working Group last calls completed : MPLS/GMPLS interworking and migration Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Adrian, These I-Ds are ready to move forward as RFCs. Of course,we welcome WG feedback and comments. Regards, Kenji Adrian Farrel wrote: > Hi, > > These last calls completed while I was travelling. I have scanned the > mail list and I didn't see any comments. I also received no comments > privately. > > Maybe the drafts are in perfect shape. Maybe no-one had time to read them. > > Please can I get a feeling from the working group: > > Are these I-Ds ready to move forward as RFCs? > > "Framework for MPLS-TE to GMPLS migration" > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-03.txt > > > "Interworking Requirements to Support operation of MPLS-TE over GMPLS > Networks" > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-reqts-01.txt > > > Thanks, > Adrian > > ----- Original Message ----- From: "Adrian Farrel" > To: > Sent: Thursday, August 09, 2007 7:41 PM > Subject: Working Group last call on MPLS/GMPLS interworking and migration > > >> Hi, >> . >> Two working group drafts have reached the position where the authors >> consider them ready for last call (actually, a whole bunch have >> arrived there at the same time, but we want to dribble them through >> the last call process). >> >> These two documents concern the operation of MPLS over GMPLS, and the >> migration from MPLS to GMPLS. >> >> The "Framework for MPLS-TE to GMPLS migration" is (the rather poorly >> named) >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-03.txt >> >> >> The "Interworking Requirements to Support operation of MPLS-TE over >> GMPLS Networks" are in >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-reqts-01.txt >> >> >> The documents are both Informational. >> >> Please send your comments (preferably to the list) by the end of WG >> last call which will be 12 noon GMT 24th August 2007. >> >> Thanks, >> Adrian >> >> >> > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Sep 2007 12:18:21 +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: Plans for GELS work in CCAMP Date: Wed, 5 Sep 2007 14:16:52 +0200 Message-ID: <0428AC48A879ED46A94F39D5665DF684A57990@esealmw110.eemea.ericsson.se> Thread-Topic: Plans for GELS work in CCAMP Thread-Index: AcfvpXVNtKK3xihBQqWj+KXVTZuTDAADztvQ From: "Diego Caviglia (GA/ERI)" To: "Adrian Farrel" , Cc: "Ross Callon" Hi Adrian hi Deborah, I think that this is a very good way to proceed I = also think the people in the DT are the right ones. I'd like to contribute this work so DT guys please fill free to contact = me. Best Regards Diego > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf > Of Adrian Farrel > Sent: mercoled=EC 5 settembre 2007 11.51 > To: ccamp@ops.ietf.org > Cc: Ross Callon > Subject: Plans for GELS work in CCAMP >=20 > Hi, >=20 > We owe you a plan for starting the GELS work in CCAMP. >=20 > As you may have seen, we have just sent a request to the ADs to push > through > our recharter as discussed on the mailing list. The ADs have already > indicated their support, so hopefully this will be fairly smooth. >=20 > We have also been talking with Don and Loa about starting work on the = GELS > drafts that we will accept into the working group as a starting point. > (Other drafts can be added as needed.) >=20 > 1. "GMPLS Extensions for PE to PE Ethernet Label Switched Paths(LSPs)" > This document is the generic work: > - Introduction > - Rationale for GMPLS Control of Ethernet > - Generic functional requirements (no data plane specifics!) > - Applicability of existing protocol elements > - New generic protocol elements (nothing specific to the data plane) >=20 > 2. "GMPLS control of P2P TE for PBB-TE (802.1Qay)" > Mainly references to the generic document. > Some protocol specifics: > - Code points (i.e. IANA section) > - Label allocation and swapping rules > Not a large document. >=20 > Other drafts that we might also see: >=20 > 3. "GMPLS control of P2P TE for IEEE802.1Q" > Another data plane-specific draft, like 2, but for a different data = plane >=20 > 4. Applicability Statement > A concise description of how and why to apply GMPLS to Ethernet. > Probably not written until after the protocol work is done. >=20 > We propose a relatively small design team to get this work started. > Loa Andersson > Lou Berger > Don Fedyk > George Swallow >=20 > We are NOT trying to exclude anyone from the work, and we make a = couple of > observations: >=20 > - A design team is just a group of people working on a > draft. > - Anyone and everyone is welcome to write a draft. > - We feel that an initial design should be small to make > rapid initial progress. > - We welcome (and expect!) full and detailed contribution > on the mailing list as this work progresses. > - Everyone who contributes to a draft should be appropriately > recognised in the draft. >=20 > Last point: > I propose to close the GELS mailing list now. >=20 > Hope this is all satisfactory to you. >=20 > Regards, > Adrian and Deborah >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Sep 2007 10:13:09 +0000 Message-ID: <010a01c7efa2$57cd20f0$0302a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Ross Callon" Subject: Plans for GELS work in CCAMP Date: Wed, 5 Sep 2007 10:51:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, We owe you a plan for starting the GELS work in CCAMP. As you may have seen, we have just sent a request to the ADs to push through our recharter as discussed on the mailing list. The ADs have already indicated their support, so hopefully this will be fairly smooth. We have also been talking with Don and Loa about starting work on the GELS drafts that we will accept into the working group as a starting point. (Other drafts can be added as needed.) 1. "GMPLS Extensions for PE to PE Ethernet Label Switched Paths(LSPs)" This document is the generic work: - Introduction - Rationale for GMPLS Control of Ethernet - Generic functional requirements (no data plane specifics!) - Applicability of existing protocol elements - New generic protocol elements (nothing specific to the data plane) 2. "GMPLS control of P2P TE for PBB-TE (802.1Qay)" Mainly references to the generic document. Some protocol specifics: - Code points (i.e. IANA section) - Label allocation and swapping rules Not a large document. Other drafts that we might also see: 3. "GMPLS control of P2P TE for IEEE802.1Q" Another data plane-specific draft, like 2, but for a different data plane 4. Applicability Statement A concise description of how and why to apply GMPLS to Ethernet. Probably not written until after the protocol work is done. We propose a relatively small design team to get this work started. Loa Andersson Lou Berger Don Fedyk George Swallow We are NOT trying to exclude anyone from the work, and we make a couple of observations: - A design team is just a group of people working on a draft. - Anyone and everyone is welcome to write a draft. - We feel that an initial design should be small to make rapid initial progress. - We welcome (and expect!) full and detailed contribution on the mailing list as this work progresses. - Everyone who contributes to a draft should be appropriately recognised in the draft. Last point: I propose to close the GELS mailing list now. Hope this is all satisfactory to you. Regards, Adrian and Deborah Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Sep 2007 10:13:02 +0000 Message-ID: <00e301c7ef9c$7b64f8e0$0302a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Ross Callon" , Cc: Subject: CCAMP Proposed Recharter Date: Wed, 5 Sep 2007 10:09:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi Ross and Dave, Please propose the attached recharter to the IESG for approval. Can you get it onto the agenda for this Thursday? Probably missed it :-( Thanks, Adrian and Deborah === First paragraph OLD The CCAMP working group coordinates the work within the IETF defining a common control plane and a separate common measurement plane for physical path and core tunneling technologies of Internet and telecom service providers (ISPs and SPs), e.g. O-O and O-E-O optical switches, ATM and Frame Relay switches, MPLS, GRE, in cooperation with the MPLS WG. NEW The CCAMP working group coordinates the work within the IETF defining a common control plane and a separate common measurement plane for physical path and core tunneling technologies of Internet and telecom service providers (ISPs and SPs), e.g. O-O and O-E-O optical switches, TDM switches, Ethernet switches, ATM and Frame Relay switches, IP encapsulation tunneling technologies, and MPLS in cooperation with the MPLS WG. === New paragraph in the list of Scope bullets. Suggest to place it after: "- Definition of MIB modules and other OAM techniques relevant to the protocols and extensions specified within the WG." and before: "CCAMP WG currently works on the following tasks:" - Work on traffic-engineering GMPLS mechanisms and protocol extensions to support source-controlled and explicitly-routed Ethernet data paths for Ethernet data planes that are already approved by an SDO with responsibility for the Ethernet data plane. It is expected that the primary SDO in this case is the IEEE. Note that the specification or modification of Ethernet data planes is out of scope. === Final paragraph OLD In doing this work, the WG will work closely with at least the following other WGs: MPLS, ISIS, OSPF, IDR, L1VPN and PCE. The WG will also cooperate with the ITU-T. NEW In doing this work, the WG will work closely with at least the following other WGs: MPLS, ISIS, OSPF, IDR, L1VPN, and PCE. The WG will also cooperate with the ITU-T and the IEEE 802.1. === Milestone revisions (see below for full revised milestone list) OLD Jan 2006 First version WG I-D for Protocol solutions for MLN/MRN NEW Sep 2007 First version WG I-D for Protocol solutions for MLN/MRN --- OLD Mar 2006 First version WG I-D GMPLS OAM Requirements NEW Sep 2007 First version WG I-D GMPLS OAM Requirements --- OLD Apr 2006 First version of WG I-D for additional MIB module to cover RSVP-TE signaling extensions NEW Nov 2007 First version of WG I-D for additional MIB module to cover RSVP-TE signaling extensions --- OLD Jun 2006 Submit Informational I-D for Analysis of inter-domain issues for disjoint and protected paths for IESG review NEW Oct 2007 Submit Informational I-D for Analysis of inter-domain issues for disjoint and protected paths for IESG review --- OLD Oct 2006 Submit MPLS to GMPLS migration strategies I-D for IESG review NEW Sep 2007 Submit MPLS-TE to GMPLS migration strategies I-D for IESG review --- OLD Nov 2006 Submit ASON Routing solutions I-D for IESG review NEW Jan 2008 Submit ASON Routing solutions I-D for IESG review --- OLD Dec 2006 Submit Requirements for Multi-Layer and Multi-Region Networks I-D for IESG review NEW Oct 2007 Submit Requirements for Multi-Layer and Multi-Region Networks I-D for IESG review --- OLD Jan 2007 Submit MPLS-GMPLS interworking requirements and solutions I-D for IESG review NEW Sep 2007 Submit MPLS-TE/GMPLS interworking requirements I-D for IESG review --- OLD Feb 2007 Submit Evaluation of existing protocols for MLN/MRN for IESG review NEW Oct 2007 Submit Evaluation of existing protocols for MLN/MRN for IESG review --- OLD Mar 2007 Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review NEW Dec 2007 Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review --- OLD Jun 2007 Submit GMPLS OAM Requirements I-D for IESG review NEW Feb 2008 Submit GMPLS OAM Requirements I-D for IESG review --- OLD Aug 2007 Submit Protocol solutions for MLN/MRN I-D for IESG review NEW Mar 2008 Submit Protocol solutions for MLN/MRN I-D for IESG review --- OLD Dec 2007 Submit MIB module for RSVP-TE signaling extensions for MIB doctor and IESG review NEW Apr 2008 Submit MIB module for RSVP-TE signaling extensions for MIB doctor and IESG review --- OLD Dec 2007 Recharter or close Working Group NEW Dec 2008 Recharter or close Working Group --- NEW Oct 2007 First version WG I-Ds for GMPLS source-controlled and explicitly-routed Ethernet networks --- NEW Sep 2008 Submit protocol extensions for GMPLS source-controlled and explicitly-routed Ethernet networks for IESG review ==== Goals and Milestones (full revised milestone list) Done Post strawman WG goals and charter Done Identify and document a limited set of candidate solutions for signalling and for measurement. Among candidate control solutions to be considered are the existing GMPLS drafts. Done Build appropriate design teams Done Submit WG document defining path setup portions of common control plane protocol Done Submit WG document defining common measurement plane protocol Done Submit LMP MIB to IESG Done Submit protection & restoration documents to IESG Done Submit ASON signaling requirements doc to IESG Done Submit GMPLS MIBs to IESG Done Produce CCAMP WG document for generic tunnel tracing protocol Done Produce CCAMP WG document for multi-area/AS signaling and routing Done Submit ASON routing requirements doc to IESG Done Submit revised charter and milestones to IESG for IESG consideration of more detailed deliverables and determination of usefulness of continuation of WG Done First version WG I-D for Advertising TE Node Capabilities in ISIS and OSPF Done First version WG I-D for Automatic discovery of MPLS-TE mesh membership Done Submit ASON Routing evaluation I-D for IESG review Done Cross-WG review of I-D for Advertising TE Node Capabilities in ISIS and OSPF Done First version WG I-D MPLS to GMPLS migration strategies Done First version WG I-D Requirements for Multi-Layer and Multi- Region Networks Done First version WG I-D for Evaluation of existing protocols for MLN/MRN Done First version of WG I-D for ASON Routing solutions Done Submit RSVP-TE extensions for inter-domain signaling I-D for IESG review Done Submit Per-domain path computation signaling I-D for IESG review Done First version of WG I-D for OSPF-TE/GMPLS MIB module Done Submit GMPLS signaling in support of Call Management I-D for IESG review Done First version WG Informational I-D for Analysis of inter- domain issues for disjoint and protected paths Done Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF for IESG review Done Submit GMPLS/ASON lexicography I-D for IESG review Done First version WG I-D MPLS-GMPLS interworking requirements and solutions Done Submit LSP Stitching I-D for IESG review Done Submit I-D for Automatic discovery of MPLS-TE mesh membership for IESG review Done Submit GMPLS routing and signaling interoperability advice I-D for IESG review Sep 2007 First version WG I-D for Protocol solutions for MLN/MRN Sep 2007 First version WG I-D GMPLS OAM Requirements Sep 2007 Submit MPLS-TE to GMPLS migration strategies I-D for IESG review Sep 2007 Submit MPLS-TE/GMPLS interworking requirements I-D for IESG review Oct 2007 First version WG I-Ds for GMPLS source-controlled and explicitly-routed Ethernet networks Oct 2007 Submit Informational I-D for Analysis of inter-domain issues for disjoint and protected paths for IESG review Oct 2007 Submit Requirements for Multi-Layer and Multi-Region Networks I-D for IESG review Oct 2007 Submit Evaluation of existing protocols for MLN/MRN for IESG review Nov 2007 First version of WG I-D for additional MIB module to cover RSVP-TE signaling extensions Dec 2007 Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review Jan 2008 Submit ASON Routing solutions I-D for IESG review Feb 2008 Submit GMPLS OAM Requirements I-D for IESG review Mar 2008 Submit Protocol solutions for MLN/MRN I-D for IESG review Apr 2008 Submit MIB module for RSVP-TE signaling extensions for MIB doctor and IESG review Sep 2008 Submit protocol extensions for GMPLS source-controlled and explicitly-routed Ethernet networks for IESG review Dec 2008 Recharter or close Working Group ==== Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Sep 2007 16:49:46 +0000 Date: Tue, 04 Sep 2007 11:47:00 -0500 From: Young Lee Subject: RE: Working Group last calls completed : MPLS/GMPLS interworking and migration To: 'Adrian Farrel' , ccamp@ops.ietf.org Message-id: <000c01c7ef13$3702dca0$6f0c7c0a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcfrNydkCls/SZk6RZmO5y0w5nzorAD0ZdAA I support both I-Ds to move forward as RFCs. Both I-D clearly state the scope of the document and comprehensively address respective architectural framework and requirement. Young -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Thursday, August 30, 2007 1:51 PM To: ccamp@ops.ietf.org Subject: Working Group last calls completed : MPLS/GMPLS interworking and migration Hi, These last calls completed while I was travelling. I have scanned the mail list and I didn't see any comments. I also received no comments privately. Maybe the drafts are in perfect shape. Maybe no-one had time to read them. Please can I get a feeling from the working group: Are these I-Ds ready to move forward as RFCs? "Framework for MPLS-TE to GMPLS migration" http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fm wk-03.txt "Interworking Requirements to Support operation of MPLS-TE over GMPLS Networks" http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-re qts-01.txt Thanks, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Thursday, August 09, 2007 7:41 PM Subject: Working Group last call on MPLS/GMPLS interworking and migration > Hi, > . > Two working group drafts have reached the position where the authors > consider them ready for last call (actually, a whole bunch have arrived > there at the same time, but we want to dribble them through the last call > process). > > These two documents concern the operation of MPLS over GMPLS, and the > migration from MPLS to GMPLS. > > The "Framework for MPLS-TE to GMPLS migration" is (the rather poorly > named) > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fm wk-03.txt > > The "Interworking Requirements to Support operation of MPLS-TE over GMPLS > Networks" are in > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-re qts-01.txt > > The documents are both Informational. > > Please send your comments (preferably to the list) by the end of WG last > call which will be 12 noon GMT 24th August 2007. > > Thanks, > Adrian > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Sep 2007 13:08:06 +0000 Message-ID: <46DD56D2.2030506@lab.ntt.co.jp> Date: Tue, 04 Sep 2007 22:00:02 +0900 From: Kohei Shiomoto User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Working Group last calls completed : MPLS/GMPLS interworking and migration Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Adrian I think that these drafts are ready to move forward. I am happy to hear any feedback from the ccamp community. Best regards, Kohei > Hi, > > These last calls completed while I was travelling. I have scanned the > mail list and I didn't see any comments. I also received no comments > privately. > > Maybe the drafts are in perfect shape. Maybe no-one had time to read them. > > Please can I get a feeling from the working group: > > Are these I-Ds ready to move forward as RFCs? > > "Framework for MPLS-TE to GMPLS migration" > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-03.txt > > > "Interworking Requirements to Support operation of MPLS-TE over GMPLS > Networks" > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-reqts-01.txt > > > Thanks, > Adrian > > ----- Original Message ----- From: "Adrian Farrel" > To: > Sent: Thursday, August 09, 2007 7:41 PM > Subject: Working Group last call on MPLS/GMPLS interworking and migration > > >> Hi, >> . >> Two working group drafts have reached the position where the authors >> consider them ready for last call (actually, a whole bunch have >> arrived there at the same time, but we want to dribble them through >> the last call process). >> >> These two documents concern the operation of MPLS over GMPLS, and the >> migration from MPLS to GMPLS. >> >> The "Framework for MPLS-TE to GMPLS migration" is (the rather poorly >> named) >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-03.txt >> >> >> The "Interworking Requirements to Support operation of MPLS-TE over >> GMPLS Networks" are in >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-reqts-01.txt >> >> >> The documents are both Informational. >> >> Please send your comments (preferably to the list) by the end of WG >> last call which will be 12 noon GMT 24th August 2007. >> >> Thanks, >> Adrian >> >> >> > > > > > -- Kohei Shiomoto NTT Network Service Systems Laboratories 3-9-11 Midori, Musashino, Tokyo 180-8585, Japan Phone +81 422 59 4402 Fax +81 422 59 3787 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Sep 2007 09:19:01 +0000 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: Greg Jones Cc: Kam Lam , Stephen Trowbridge , Ross Callon , David Ward , Scott Bradner , CCAMP Mailing List , Adrian Farrel , Deborah Brungard , Adrian Farrel , Deborah Brungard From: Adrian Farrel (IETF CCAMP WG) Subject: New Liaison Statement, "GMPLS Signaling for VCAT/LCAS" Reply-To: Adrian Farrel Message-Id: Date: Tue, 04 Sep 2007 05:16:04 -0400 Title: GMPLS Signaling for VCAT/LCAS Submission Date: 2007-09-04 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=365 Please reply by 2007-11-15 From: Adrian Farrel(IETF CCAMP WG) To: ITU-T Q14/15(Greg Jones ) Cc: Kam Lam Stephen Trowbridge Ross Callon David Ward Scott Bradner CCAMP Mailing List Reponse Contact: Adrian Farrel Deborah Brungard Technical Contact: Adrian Farrel Deborah Brungard Purpose: For action Body: The CCAMP Working Group thanks you for your liaison of April this year (COM15-LS3-E) and for your interest in our work to develop GMPLS signaling extensions for the control of VCAT within TDM networks. The latest version of this work can be found at http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-02.txt We expect a revision relatively soon, so if the referenced link fails, please also check at http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-03.txt Here are our responses to the questions in your liaison. 1. Would CCAMP consider generalizing the draft so that it could be applied to any Inverse Multiplexing scheme? For example, if generalized, the method could be used to establish H.244, ML-PPP, ATM inverse mux, or BONDING connections. It is certainly our intention that any protocol extensions that we develop should be easily extensible to other technologies. But at the same time we have seen no immediate interest from the community in applying GMPLS as a control plane for any of the technologies that you list. It would, of course, be a prerequisite of using GMPLS for such an inverse multiplexing scheme, that GMPLS was also used to build network connections (i.e. LSPs) for the specific technology. If you have a requirement to use GMPLS to control these technologies, we would be interested to hear from you. In the mean time, we note that the inverse multiplexing schemes that you list are packet/cell forms rather than circuit forms of inverse multiplexing and hence may have different configuration parameters than VCAT. 2. Does the I-D describe VCAT call signalling? The I-D uses GMPLS Calls (RFC 4974) to achieve VCAT group signaling. The GMPLS Call is used to coordinate the setup of multiple server connections (LSPs) used to form a VCAT group (a connection in the VCAT layer). 3. Does the I-D allow LSPs in a server layer to be set up without any prior knowledge of a possible VCAT layer, and then at a later point in time allow those LSPs to become available to a VCAT layer? When a network connection is established at the request of an operator or a management system, we have assumed that there is some motivation, and that the motivation is expressed in the call that coordinates the connection. In RFC 4974, the nature of the call can be changed (as a matter of call parameter exchange that is within the scope of the call controller function, but the details of which, except for the message exchange rules, are outside the scope of the signaling protocol), but the connections cannot be moved from one call to another. Thus, LSPs that are set up in association with a specific call can only be used as directed by the call controller with responsibility for that call. If a call controller decides to use the connections (LSPs) for VCAT one day and for something else another day, that is entirely within its remit. However, this assumes that the call controller can suitably instruct and coordinate the necessary adaptation functions at each end of the network connections. An implementation might find it more convenient to release the call (and the associated connections), before setting up a new call and a new set of connections. Note that we are considering mechanisms to allow LSPs to be moved between VCAT Groups according to the requirements of the network. Such schemes necessarily mean that there is not always a 1:1 relationship between calls and VCAT groups since it remains the case that connections cannot be moved between calls. However, our understanding of G.707 and the ability to move component trails (VCAT group members) between VCAT groups while the trail is in service is unclear, and we would welcome clarification of the requirements before progressing this function further. 4. Does the I-D allow the association of a VCAT call to multiple server layer calls? This is not specifically addressed. There is no hierarchy of calls described in the draft. Instead, the draft provides for a single call that is used to coordinate all of the server layer connections that support the single VCAT service. In practice, this may not represent architectural purity, but we believe it is a protocol implementation simplification consistent with the way that VCAT is operated. We note that VCAT groups can only consist of a single server connection type and cannot be mixed, e.g., VC-3 and VC-4 components cannot both be in the same VCG. 5. Does release of a VCAT call automatically imply release of the server layer call(s)? This is not required by G.8080 as layers are assumed to be independent. As noted for point 4, the VCAT layer call is not specifically called out in the draft. You may consider that the draft provides a mechanism for handling the (single hop) VCAT call and the server layer call as a single item. We would be interested to hear from you the operational circumstances under which a single VCAT layer call might give rise to multiple server layer calls. The signaling of the release of a GMPLS Call is rejected if connections are still in place (per RFC 4974 section 6.6.4) which is consistent with the connections having been set up under the instructions of the call controller and in support of the call. Thus, operationally, the release of a call will require the release of the associated connections. At this point it may be worth clarifying that a VCAT layer connection is created under the control of a VCAT layer call. The VCAT connection may require server layer connections (indeed, this is always the case with VCAT) and those connections need to be associated and controlled by a call. it is this second type of call that we are we are describing in this draft. Thus, the release of a VCAT call would lead to the release of the VCAT connection. The network policy may determine whether to release the server layer call or not. If the server layer call is released, the server layer connections will also be released. 6. Is VCAT layer addressing assumed to be the same as that of the server layer? GMPLS only supports IP addressing. The link connections in the VCAT layer created by/from network connections in the server layer may be given different addresses from the addresses used to represent the endpoints in the server layer, or may use the same addresses. 7. Are the two VCAT layer Call Controllers assumed to have direct signalling connectivity? Yes, adjacent call controllers in any layer are assumed to be able to exchange call control messages without the intervention of any proxy, agent, or extra-layer entity. 8. If multiple client layers are using the same VCAT layer as their server layer, how can the VCAT layer call be identified for use in the client layer signalling? How is this problem any different from any other n:1 client/server relationship? Please supply details of why the fact that the server layer is a VCAT layer should make this scenario any different. Please also note that, as for point 5 above, the VCAT layer call is not what is being addressed in this draft. We are addressing the server layer call that coordinates the server layer network connections that are used as VCAT group members to construct a VCAT group that can be presented as a link connection in the VCAT layer. 9. Have you considered using the ASON call id [RFC3474] at all layers to achieve separate call control of the VCAT and server layers? The format of the call ID is deliberately out of scope for this work as we would not wish to control or enforce the applicability of this work in any one environment. However, RFC 4974 (as noted in a recent separate liaison from us on GMPLS Calls) allows any format call ID to be encoded in GMPLS calls. Thus, the ASON call id format described informationally in RFC 3474 can be supported and used in an ASON environment at the choice of the operator and/or the implementer of the call controller. Can you please confirm that the normative definition of the ASON call ID is in G.7713.2? Other Recommendations (such as G.7713.3) also appear to have call IDs defined, and we want to make sure that we can reference a single, protocol- independent definition of a call ID 10. In the ASON architecture [G.8080], it is not assumed that a single signalling protocol is used in all domains. Even in the case the same protocol is used in all domains, the RSVP session changes between domains. Could you explain how the Notify mechanism used for call control would work across multiple domains where the RSVP session changes? This question clearly has wider relevance than this VCAT draft and should be seen in the context of RFC 4974, and not in reference to this draft. We note that G.8080 makes no assumptions about connection signaling protocols in adjacent domains, but we believe that the architecture does assume an E-NNI reference point in association with one or more call controllers at such domain interfaces. The E-NNI call controllers are responsible for requesting the necessary network connections in each domain and, where the E-NNI is externalised, for requesting any inter-domain connections. Call messages are exchanged between adjacent call controllers and relate to the network connections established at the request of those call controllers. When two adjacent GMPLS domains support the same end-to-end network connection, we do not recommend that the session object be changed. Please clarify where in G.8080 there is any reference to RSVP sessions. There should be no such discussion of protocol implementations in an architecture document. We would welcome your opinions on these responses and the direction of our work. In your liaison you stated that you had the intention to review the draft further at your June meeting. But in the liaison from your June meeting (COM15-LS170-E) you say that you deferred this review pending further revisions of the I-D. This is quite reasonable, but we would nevertheless welcome any further high-level comments that you may have. We will notify you as this draft is updated. Best regards, Adrian Farrel and Deborah Brungard IETF CCAMP Working Group Co-Chairs Attachment(s): No document has been attached Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Sep 2007 13:14: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: Working Group last calls completed : MPLS/GMPLS interworking and migration Date: Mon, 3 Sep 2007 15:11:48 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E38001243721@FRVELSMBS22.ad2.ad.alcatel.com> Thread-Topic: Working Group last calls completed : MPLS/GMPLS interworking and migration thread-index: AcfrNwbW+RuJdgfvSvySymX9WcRCTQC8s07g From: "PAPADIMITRIOU Dimitri" To: "Adrian Farrel" , hi adrian it would be surprising these documents have reached perfection (or a close to), i would suggest to ask for a review by e.g. gen-art like you did for the inter-domain documents now, it is clear that by addressing a topic that involves operational aspects (not only protocol engineering specific) we would welcome any feedback along these lines thanks, -d. =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Thursday, August 30, 2007 8:51 PM > To: ccamp@ops.ietf.org > Subject: Working Group last calls completed : MPLS/GMPLS=20 > interworking and migration >=20 > Hi, >=20 > These last calls completed while I was travelling. I have=20 > scanned the mail=20 > list and I didn't see any comments. I also received no=20 > comments privately. >=20 > Maybe the drafts are in perfect shape. Maybe no-one had time=20 > to read them. >=20 > Please can I get a feeling from the working group: >=20 > Are these I-Ds ready to move forward as RFCs? >=20 > "Framework for MPLS-TE to GMPLS migration" > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpl s-interwork-fmwk-03.txt >=20 > "Interworking Requirements to Support operation of MPLS-TE over GMPLS=20 > Networks" > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpl s-interwork-reqts-01.txt >=20 > Thanks, > Adrian >=20 > ----- Original Message -----=20 > From: "Adrian Farrel" > To: > Sent: Thursday, August 09, 2007 7:41 PM > Subject: Working Group last call on MPLS/GMPLS interworking=20 > and migration >=20 >=20 > > Hi, > > . > > Two working group drafts have reached the position where=20 > the authors=20 > > consider them ready for last call (actually, a whole bunch=20 > have arrived=20 > > there at the same time, but we want to dribble them through=20 > the last call=20 > > process). > > > > These two documents concern the operation of MPLS over=20 > GMPLS, and the=20 > > migration from MPLS to GMPLS. > > > > The "Framework for MPLS-TE to GMPLS migration" is (the=20 > rather poorly=20 > > named) > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpl s-interwork-fmwk-03.txt > > > > The "Interworking Requirements to Support operation of=20 > MPLS-TE over GMPLS=20 > > Networks" are in > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpl s-interwork-reqts-01.txt > > > > The documents are both Informational. > > > > Please send your comments (preferably to the list) by the=20 > end of WG last=20 > > call which will be 12 noon GMT 24th August 2007. > > > > Thanks, > > Adrian > > > > > >=20 >=20 >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Sep 2007 08:36:01 +0000 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: Greg Jones Cc: Kam Lam , Stephen Trowbridge , Ross Callon , David Ward , Scott Bradner , CCAMP Mailing List , Adrian Farrel , Deborah Brungard , Adrian Farrel , Deborah Brungard From: Adrian Farrel (IETF CCAMP WG) Subject: New Liaison Statement, "ASON Routing Loop Prevention Mechanism" Reply-To: Adrian Farrel Message-Id: Date: Mon, 03 Sep 2007 04:32:32 -0400 Title: ASON Routing Loop Prevention Mechanism Submission Date: 2007-09-03 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=364 From: Adrian Farrel(IETF CCAMP WG) To: ITU-T Q14/15(Greg Jones ) Cc: Kam Lam Stephen Trowbridge Ross Callon David Ward Scott Bradner CCAMP Mailing List Reponse Contact: Adrian Farrel Deborah Brungard Technical Contact: Adrian Farrel Deborah Brungard Purpose: In response Body: The IETF CCAMP working group thanks you for your continued interest in the loop-prevention mechanism contained in our OSPF-based solution to the routing requirements as described in RFC 4258. This liaison is in response to your liaison COM15-169-E issued from your June plenary. A separate liaison will report on the status and progress of our OSPF ASON solution. We disagree with your statement that the rationale we explained "does not utilize the hierarchical nature defined by ASON." Quite to the contrary, the solution addresses the issues introduced by the hierarchical routing nature of ASON while utilizing the benefits. At the same time, since the protocol mechanisms are extensions to OSPF, it is only natural that "the rationale provided takes into account the considerations of how OSPF traditionally operates." You are right to observe that other mechanisms could have been selected, and would also have been functional. This is often the case in protocol design. However, a choice has to be made, and unless there are technical reasons to suggest that the choice is wrong, there seems to be no particular motivation to make a change. You say: While we recognise it is possible to identify the propagation direction based on the Area ID of the source, it does require that all redistribution mechanisms in the network understand the relative location of source areas given the area hierarchy (i.e. are they up or down the hierarchy from the evaluation point). We cannot identify in the existing proposal any mechanism (i.e. new LSA format) defined to provide this information. We note that the requirement is not to know the direction of propagation of information, but to detect routing advertisement loops. According to the strict hierarchical nature of ASON (as you describe in your liaison) the use of Area IDs is sufficient to detect advertisement loops. There is no definition of any new mechanism or LSA in this Internet-Draft: the use of a new LSA or changes to the processing rules for existing LSAs would inhibit the integration of ASON routing developments within the IETF routing family and, while this may not be an objective of the ASON architecture, it is an objective of the IETF. You suggest that the use of Area ID in the LSAs will inhibit re-configuration of AREA IDs. We do not believe that this is the case, and we will add text to the draft to describe the necessary processing for this important, but uncommon case. Please note that the scope of this work (including the loop-prevention mechanisms) is limited by the requirements expressed in RFC 4258. A separate liaison to you has requested a further review of RFC 4258. In the event that substantive modifications to the requirements are made as a result of your review, it will be necessary to consider updating the solutions work. Such a process of publication and revision is similar to the procedure applied within the ITU. Note also that the scope of this work (that is, of this current Internet-Draft) is extensions to the OSPFv2 protocol. The CCAMP working group would welcome contributions in the form of Internet-Drafts from anyone who is interested in addressing the same problem space through the IS-IS protocol. Thank you for your continued support of this work. Regards, Deborah Brungard and Adrian Farrel IETF CCAMP Working Group Co-Chairs Attachment(s): No document has been attached Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 01 Sep 2007 21:34:23 +0000 Message-ID: <05d001c7ecdf$cd82ec00$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Communication from OIF on MEF UNI Date: Sat, 1 Sep 2007 22:32:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, We have received a very constructive communication from the OIF wrt our work on the MEF UNI. You can see it at www.olddog.co.uk/ccamp.htm Can I encourage the authors of the various MEF-related I-Ds to follow up on the actions agreed in Chicago. Cheers, Adrian === Mr. Adrian Farrel, IETF CCAMP Co-Chair, adrian.farrel@aria-networks.com Ms. Deborah Brungard, IETF CCAMP Co-Chair, dbrungard@att.com Cc: Mr. Ross Callon, IETF Routing Area Director, rcallon@juniper.net Mr. David Ward, IETF Routing Area Director, dward@cisco.com Mr. Lyndon Ong, Ciena Corporation, lyong@ciena.com From: Mr. Jim Jones, OIF TC Chair Subject: Liaison to IETF CCAMP WG on MEF services support Dear Adrian and Deborah, The OIF has been engaged in discussion with the MEF since April 2005 regarding MEF UNI service definitions and how these might be supported over a UNI control plane interface. During this discussion a number of mutual conclusions have been reached on the requirements for signaling MEF UNI parameters using the control plane, and the relationship of control plane and management plane interfaces at the MEF UNI. Some of the control plane protocol issues that were identified have been socialized with IETF CCAMP WG through liaisons and informal communications between participants in OIF and CCAMP, and have resulted in work discussed in CCAMP. OIF plans to make use of this work in its future documents; in particular, the MEF Ethernet Traffic Parameters and EVPL label formats and switching type (provided in draft-ietf-ccamp-ethernet-traffic-parameters- 02.txt and draft-berger-ccamp-gmpls-mef-uni-00.txt, respectively). While we recognize that the second draft identified has not yet been formally adopted as a Working Group draft, definition of the EVPL label formats and switching type defined in the draft meet needs that we have identified for support of MEF services in the control plane. We appreciate CCAMP's efforts in this area and hope to continue productive interaction in the future. Thank you. Sincerely yours, Jim Jones OIF Technical Committee Chair Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 01 Sep 2007 21:34:05 +0000 Message-ID: <05cf01c7ecdf$5cb5a9e0$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: liaison response to to IETF ccamp WG on MFA Forum MPLS CNI Date: Sat, 1 Sep 2007 22:22:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, We have received the attached liaison from the MFA. I expect it will be posted on the IETF web site in due course. In the mean time, you can find it at www.olddog.co.uk/ccamp.htm The liaison does not ask for any action from us, but we may want to review the new specification and comment on it. Thanks, Adrian ----- Original Message ----- From: "J. Rao Cherukuri" To: ; ; ; Cc: "David Sinicrope (RL/TNT)" ; ; "BOCCI Matthew" ; "Ross Callon" ; ; Sent: Friday, August 31, 2007 8:34 PM Subject: liaison response to to IETF ccamp WG on MFA Forum MPLS CNI Hi Adrian, Deborah, Thank you and the CCAMP WG for providing such thorough and valuable comments. We have reviewed and incorporated many of them into the CNI document. There are a few that we have not incorporated for various reasons. We have provided the rationale for these decisions inline below. Please let us know if you have any questions or concerns. Best Regards, David Sinicrope AD Working Group Chair Rao Cherukuri TC Chair *************************************** We note that you have opted to define a new RSVP object to support a multi-class LSP following the rules for vendor private assignment as described in section 2.2 of RFC3936. We believe that you may have misinterpreted the purpose of vendor private extensions since such extensions are specifically not intended to interoperate, but you are attempting to define a specification directly for the purpose of interworking devices from different vendors. In your case it would seem to make more sense to define a standardized extension to the protocol. MFAF> At the time of development of our specification draft-andersson was not adopted by IETF. Also, the Multi Class specification wasn't in a state where we could refer to it. Consequently, we chose to use the vendor private TLV to expedite completion of our document. In subsequent revisions of the CNI we will consider following draft-andersson and obtaining a standard Multi Class TLV. Should you decide that a standardized extension is better able to deliver the functionality that you require, we should like to draw your attention to draft-andersson-rtg-gmpls-change-06.txt that defines how other SDOs may influence the development of MPLS and GMPLS protocols within the IETF, and which is currently in IETF last call. The (G)MPLS suites of protocols have become popular among multiple SDOs resulting in a need for IETF to clarify its role as the responsible SDO for (G)MPLS protocol extensions so as to prevent unnecessary replication of functionality and the resulting interoperability problems. 1. The document is marked as Straw Ballot Text. Can you tell us what that means the status of the work is? MFAF> Review is completed and document is in "last call". 2. We think that your use of terminology may be a little loose. In many cases, where you say "MPLS" you are probably referring to the data plane, and specifically a packet-switching data plane with an MPLS encapsulation. But in other cases, "MPLS" and "MPLS-TE" are synonymous and refer to a signaling/routing control plane using the MPLS-TE extensions to RSVP and to the two IGPs OSPF and IS-IS. In many cases you say "GMPLS-TE" which is not something we specifically recognise although we can assume that you mean simply "GMPLS". Sometimes, where you are trying to distinguish a TE LSP established using MPLS-TE from one set up using GMPLS you may intend to say "GMPLS TE-LSP" rather than "GMPLS-TE LSP". We feel that close attention to the terminology may help clarify the document. MFAF> We have gone through the document and reflected your suggestions in the text. 3. Section 1.1 states: The purpose of this specification is to define an MPLS-based Client to Network Interconnect (CNI) for establishing GMPLS Traffic Engineered (TE) Label Switched Paths (LSPs). Can we assume that this means that the client-to-client LSPs are established using GMPLS protocols, but that the signaling within the core network is out of scope? Especially since section 1.2 states: At the CNI, it is not desirable to have the client equipment participate in the internal control protocols of the MPLS network. MFAF> We have reflected this suggestion in the text of section 1.2. 4. Can you clarify why you have selected GMPLS protocols and not MPLS-TE protocols on which to build your CNI. We are not opposed to this, but are seeking to understand the choice. Perhaps the main reason is the requirement for bidirectional LSPs. MFAF> To facilitate use of bi-direction LSPs and to leverage existing implementations of the standard. We have reflected this rationale in the text of section 1.2. 5. Can you clarify whether the core network is assumed to be PSC only? That is, for example, if the CNI encoding is POS, would it be acceptable for the PE and the rest of the core network to switch the LSP as TDM until the remote PE or even CE, or do you require that the PE must perform packet switching? If the PE must perform packet switching, is it still acceptable for the core LSP (PE-PE) to be switched at some other technology? MFAF>We assume that the core is PSC only. The CNI is implemented at the edge of the network. Details of the core network beyond what is stated in section 1.3 are beyond the scope of the CNI. 6. Section 1.3 states: Where the network uses MPLS-TE signaling, the PE routers are expected to perform the translation. It is our opinion that this translation is non-trivial and may be impossible for some of the GMPLS services that are available at the CNI. For example, supporting a bidirectional service over an MPLS-TE signaling network requires additional coordination between the end-points that is currently not available in the MPLS-TE extensions to RSVP-TE. From the following text in section 7.1, we assume that the PE may refuse a CNI request if it is unable to provide the required level of function. The transport network in the provider network is a GMPLS or MPLS-TE based packet switched network that must support request for uni-directional LSPs and may support requests for bi-directional LSPs MFAF> In section 1.3 we state that the core has support for a minimum set of GMPLS capabilities. e.g., bidirectional LSP support, traffic engineering QoS capabilities. 7. Section 2.1 The correct expansion of "GMPLS" is "Generalized Multiprotocol Label Switching". In view of you chosen expansion of "MPLS", you may prefer to show this as "Generalized Multi Protocol Label Switching". The correct expansion of "FEC" is "Forwarding Equivalence Class". MFAF> We have reflected this suggestion in the text. See the Acronyms section. 8. Section 7.2 states: The CE and PE nodes are inter-connected by point-to-point interfaces. The signaling channel is "in-band", i.e., the labeled packets share the same access connection as the RSVP-TE signaling. This is an acceptable, but not required, method of deploying GMPLS-based signaling. It is our suspicion reading this very short section that it is your intention to forbid the use of the IF_ID RSVP_HOP Object at the CNI. Can you confirm or deny this? MFAF> At our last meeting in Chicago we decided to allow the use of the IF_ID_RSVP_HOP as an option. See section 7.2. 9. Section 7.3 states: A client need only know its own address, a reachable address of the adjacent PE-node, and know the address of any other client to which it wishes to connect. The addresses listed above must be configured on each client. A PE need only know (and track) the addresses on interfaces attached to clients, as well as the Node IDs of these attached clients. In addition, the IP/MPLS network needs to know reachability to the interface addresses and Node IDs of other PEs to which an attached client is permitted to connect. This appears to miss the fact that the client will address a CNI connection request to a remote client address. The local PE must, therefore, know how to route to these client addresses that are outside the core routing domain. Perhaps the final sentence should say CE not PE? But in 9.1.2 you have: When a PE receives a Path message from a client that contains no ERO indicating transit network selection, then the PE is responsible for progressing the Path message toward the destination. The progression of the Path message is beyond the scope of this specification. While the details are clearly out of scope, it *is* relevant to the definition of the CNI how the core acquires and distributes the client-side addressing information that is necessary for routing across the core. You will observe that the problem you are solving (including the fact that the client addresses may come from an address space that overlaps with the core address space) is similar to the L3VPN problem. MFAF> We corrected the text to address this issue in section 7.3. Also see the changes in section 9.1.2. 10. What is the expected behavior from the core network when an E-LSP is requested at the CNI? Can we assume that the expectation is that an appropriate E-LSP will also be established across the core so that Diffserv behavior will be performed along the whole length of the client-client connection, or is this not a requirement? If core Diffserv behavior is required, how will the core handle the presence of multiple classes? MFAF>This is assumed and although how it is done is beyond the scope of the specification, section 7.4.1 now states what is expected of the network. 11. You are correct to observe that the ERO is optional in GMPLS implementations (sections 9.1.1 and 9.1.2), however, since you are specifying a profile for use at the CNI, and since both the CE and the PE must be CNI-aware (i.e., you cannot simply use legacy implementations) you may find it convenient to mandate support of the ERO at the CNI. We believe that in practice all implementations support ERO. MFAF> We still do not mandate ERO because there was no agreement within the MFAF TC to mandate it. See changes made in 9.1.2. 12. In section 9.1.1 you have: The client populates the ERO object with only one sub-object containing an Autonomous System Number (ASN) representing a transit network beyond the originating service provider. The client equipment must set the ASN sub-object 'L' bit to 1, indicating a loose route. It is not completely clear what is meant by 'the originating service provider', but we assume that this refers to the network that the ingress PE belongs to. In this case, this ERO is malformed and will be rejected. The first sub-object of a received ERO must always define an abstract node that the receiver is a member of. See RFC 3209, section 4.3.4.1, point 1). MFAF> We reflected this in section 9.1.1. 13. In section 9.4: PE next to a client receives a PathErr with Path_State_Removed from the network, it may in turn generate either a ResvTear or PathTear, whichever is applicable, to be sent to the client. There are no circumstances in which a PE receiving a PathErr with Path_State_Removed from the network would send PathTear to the client. It is unclear to us why you would specify that the CNI built on GMPLS might not use this standard GMPLS procedure. MFAF>We reflected this in section 9.4. 14. In section 9.5.3: The Extended Classtype object is signaled in the Path message, and saved in the Path State Block (PSB) at every hop. We recommend that you simply state that the state is stored as every hop. The existence of a PSB is implementation- specific. Can you please clarify "at every hop". Are you expecting nodes in the core network to store this information. If so, you should note that the core nodes will not recognize the object class and will reject any messages carrying it. We also suggest that before progressing your own extensions for multi-class DSTE LSPs you should look at the existing work within the IETF: http://www.ietf.org/internet-drafts/draft-minei-diffserv-te-multi-class- 02.txt . If this work is not adequate for your requirements, we would encourage you to work with its authors to produce a single standardized solution within the IETF. MFAF>We removed all references to PSB, and all reference to "at every hop". This better aligns with our scope of not specifying the network internals. See section 9.5.3. 15. In 9.5.4: An LSR that recognizes the Extended Classtype object and that receives a Path message which contains the Extended Classtype object but which does not contain a Label Request object or which does not have a session type of LSP_Tunnel_IPv4, must send a PathErr message towards the sender with the error code 'extended-classtype Error' and an error value of 'Unexpected Extended Classtype object'. These are defined below: Why do you define new parsing behavior for the absence of a Label Request object (by the way, you should say Generalized Label Request object, since this is GMPLS)? The absence of mandatory objects is already covered in RFC2205. MFAF> We removed the reference to "the absence of (Generalized) Label Request object". This implies that if the Generalized Label Request object is missing, the relevant procedures of RFC 2205 will be performed. 16. The error code defined in 9.5.4 is conformant with RFC 3936. You may wish to look at draft-swallow-rsvp-user-error-spec in case this gives you the ability to handle more detailed private error codes. MFAF> In our specifications we are limited to referring only to documents that have been progressed to the RFC editor queue and beyond. We will certainly consider reference to draft-swallow-rsvp-user-error-spec in future revisions of the CNI. Finally, we would like to refer you to draft-kumaki-ccamp-mpls-gmpls-interwork-reqts-01.txt and draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-01.txt for the latest state of discussions in CCAMP with respect to interworking MPLS and GMPLS networks. MFAF> Thanks for pointing out these documents. We will consider these should our work scope be expanded to include details of the core network and MPLS and GMPLS interworking. Attachment(s):