From 2p5b2tDD73@mail.ru Fri Aug 04 04:04:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8ufE-0006dy-NA; Fri, 04 Aug 2006 04:04:12 -0400 Received: from [212.98.242.10] (helo=ng.celebi.com.tr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8ufC-0003J4-9f; Fri, 04 Aug 2006 04:04:12 -0400 Date: Fri, 4 Aug 2006 08:04:11 -0120 From: "Fanny Edwards" X-Mailer: The Bat! (v3.01 RC8) UNREG / CD5BF9353B3B7091 Reply-To: "Fanny Edwards" X-Priority: 3 (Normal) Message-ID: <8133185144.20060804080411@mail.ru> To: mpls-archive@lists.ietf.org Subject: Order status, namma hole MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 4.2 (++++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Even if you have no erectin problems SOFT CIA3LIS would help you to make BETTER SEFX MORE OFTEN! and to bring unimagnable plesure to her. Just disolve half a pil under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medic ation were able to have PERFECT ERTECTION during 36 hours! VISIT US, AND GET OUR SPECIAL 70% DISCWOUNT OFER! http://dqqetv.pulsemix.net/?76864451 ========== at the horizon itself, flew a few others. New sights, new thoughts, new told me something about the shadows, that they were weird but harmless. the peak of the Great Mountain Wind. Beyond a few hundred feet, I can lift it that time. Then we wouldn't be having any of these problems now. But it grateful for what he had learned about work-saving low-altitude flying. it?--and slithered into the field, behind the hushes and the rotten fences, stay here and learn on this level - which is quite a bit higher than the "Good luck, you complicated soul." From crosspointbarb@diplomats.com Fri Aug 04 11:30:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G91cr-0002ec-3f; Fri, 04 Aug 2006 11:30:13 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G91cr-00061z-28; Fri, 04 Aug 2006 11:30:13 -0400 Received: from pool-72-83-217-17.washdc.east.verizon.net ([72.83.217.17] helo=FLORENCE) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G91cq-0002iI-2G; Fri, 04 Aug 2006 11:30:12 -0400 Message-ID: <68053010402740.3A46BC655E@HFAFWGV> From: "cherish" To: Subject: huge clergymen Date: Fri, 4 Aug 2006 08:33:49 -0700 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: BytKw59l0JNxQdNrGt8s3OF85Wi02mOloQNn Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: -0.2 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 As a trader myself, I often wished there was someone by my side to pick out the most promising new stocks for me. You’re more lucky here, with all this information given away – just check out what’s here below!

TRADER AND INVESTOR ALERT!

FRIDAY AUGUST 4, 2006

GLOBEX INC.

Symbol: GLXI. PK

BIOETHANOL PLAY!!

Price: $0.65
This stock is fertile ground for investors who want to be the first harvesters. There’s clear evidence of that.

RECENT HEADLINES:

1)Globex, Inc. Advances to Full Scale Testing Stage of Its New SCF Technology- Company Ready to Test Technology in Complete Pilot Ethanol Production Facility 2)Globex, Inc. Announces Positive Trial Results for Its New SCF Technology- Technology Exhibits High Lignin Removal Using Wood Chips

DECIDE FOR YOURSELF!!

IS THIS THE "HOTSHOTSTOCKALERT" YOU'VE BEEN WAITING FOR?!!
Without any doubt this stock opens great possibilities for a trader.

Benefit from this rising stock as it gains popularity. The harder you work, the more luck you get. You surely work hard enough – so may luck be with you!

From mpls-bounces@lists.ietf.org Fri Aug 04 13:27:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G93Q0-0005Vw-4p; Fri, 04 Aug 2006 13:25:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G93Pz-0005Vp-1Z for mpls@ietf.org; Fri, 04 Aug 2006 13:25:03 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G93Pv-0005VB-DB for mpls@ietf.org; Fri, 04 Aug 2006 13:25:03 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 04 Aug 2006 10:24:58 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,212,1151910000"; d="scan'208"; a="34626371:sNHT34582080" 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.20060308/8.12.11) with ESMTP id k74HOvZX005859; Fri, 4 Aug 2006 13:24:57 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k74HOve2022780; Fri, 4 Aug 2006 13:24:57 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Aug 2006 13:24:57 -0400 Received: from [10.83.15.50] ([10.83.15.50]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Aug 2006 13:24:57 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3FBDDED3-F92B-4C3D-BA39-6EB195BB56FD@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: [mpls] Comments on draft-swallow-mpls-mcast-cv-00 Date: Fri, 4 Aug 2006 13:24:55 -0400 To: "" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 04 Aug 2006 17:24:57.0313 (UTC) FILETIME=[E83C3D10:01C6B7EA] DKIM-Signature: a=rsa-sha1; q=dns; l=7027; t=1154712297; x=1155576297; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=22Thomas=20D.=20Nadeau=22=20 |Subject:Re=3A=20[mpls]=20Comments=20on=20draft-swallow-mpls-mcast-cv-00 |To:=22=22=20; X=v=3Dcisco.com=3B=20h=3D7gm+gYf6432f+UCXTJKKTr2B5xE=3D; b=sFe/C2xHptyLn7ACw97NzlVa2AsBlBYGYwcWHARrwYyoa6TZ1ldaew7gfdoUnz8Fty/glX7k iNbpz0AgYtZZVfeZZbpDRLBcZHZTpHyQKJEEI65IcCaTCoV2whKiE1Xu; Authentication-Results: rtp-dkim-1.cisco.com; header.From=tnadeau@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi, Thanks for reviewing. Replies inline start with TDN: > Colleagues, > > draft-swallow-mpls-mcast-cv is a good start towards addressing P2MP > OAM > in a scalable manner. > > Following on from my comments at IETF 66, I have discussed the draft > with a few colleagues and below are some general comments on > draft-swallow-mpls-mcast-cv-00 and some editorial comments. > > Ben > > -- > Ben Niven-Jenkins > Network Architect, BT Exact > > > General comments > ---------------- > 1) Section 3 states: > > "3. Connectivity Verification Bootstrapping > > Bootstrapping is accomplished by sending an MPLS Echo Request > message > containing a Connectivity Verification Session object and a FEC stack > which specifies the LSP for which connectivity verification is > desired. > The next section describes the Connectivity Verification Session > object. > Subsequent sections describe the procedures for the root and leaves." > > Which essentially means that Connectivity Verification is boot > strapped > by LSP-Ping. I would like to see an option whereby CV is bootstrapped > by the signalling protocol. Architecturally, the > activation/deactivation of any proactive defect detection/handling > (i.e. > CV) should be synchronised to whatever process is responsible for the > setup/tear down of that connection. So CV activation/deactivation > should be synchronised to either NMS/OSS provisioning or the > signalling > protocol used. This also ensures that OAM activation/deactivation is > tied-in to connection setup/tear down wrt time, so as soon as the > connection is created the OAM is also initiated and the OAM is stopped > before the connection is torn down therefore avoids raising false > alarms. > > The draft describes how to use LSP-Ping to bootstrap CV OAM once an > LSP > is activated, but doesn't describe how to deactivate CV OAM prior > to an > LSP being deactivated. This needs clarification IMO. TDN: Agreed. > A more subtle observation on the current approach is if we setup a > P2MP > LSP and then use LSP-Ping which operates in-band wrt the data plane of > that P2MP LSP to bootstrap CV for that LSP, how do we know the LSP has > been correctly setup in the first place as the LSP-Ping bootstrap > message is being carried in the same data plane entity (i.e. LSP) that > the CV will monitor? TDN: If the LSP was setup correctly, then the setup message will arrive at the end points correctly and then be replied to, otherwise it will not (if the LSP is not working). > Can mpls-mcast-cv be initiated by an out of band process wrt the data > plane entity (i.e. LSP) that it will monitor? TDN: I suppose that it could, although the point of having the online process do this is to generate the traffic on the egress line cards (for distributed implementations). > 2) Section 3.1 states: > > "Discriminator > > A unique, nonzero discriminator value generated by the transmitting > system, used to demultiplex multiple BFD sessions between the same > pair > of systems." > > I would like to see a recommendation that this discriminator field > contain a network unique identifier (e.g. source address) of the > LSP to > help with better identification under fault conditions than a possibly > arbitrarily generated number. TDN: The discriminator is meant to be chosen from the same pool as BFD session discriminators are chosen. These have only local significance. What provides the network-wide uniqueness is the binding between the source/destination IP addresses plus the discriminator. > Also, is the reference to BFD a copy & paste error? If not, then > further discussion of how this field is used and how it relates to BFD > is required. TDN: Yes, although the next version of the draft will have more things borrowed from BFD. > 3) Section 3.2 states > > "The Refresh Interval is set to a relatively long value. The root > MUST refresh the session within this interval. The root MAY jitter > refresh messages but the Refresh Interval serves as a hard upper > bound on the jittering. MPLS Echo Requests which refresh the CV > Session SHOULD be sent on average at approximately one third of the > Refresh Interval." > > However Section 3.1 defines the Refresh Interval as "the minimum > period > before a refresh message is sent in milliseconds." > > There seems to a conflict in the two defintions, where Section 3.1 > states it is a mininum period and Section 3.2 states that it is a > upper > bound. Which is it? TDN: The refresh interval for the bootstrapping messages is supposed to be relatively long -- on the order of multiple seconds or minutes. > 4) Section 3.3.1 states > "If the Forward Defect Flag is set, an up call to any registered > applications is made." > > Is this up call supposed to cause any action by the application or > imply > any consequences? It would be good to clarify this here. Also, the > term 'up call' is not familiar to me and is not defined. I assume > by up > call you mean that FDI is propagated upwards to the application > (assuming the application support some form of FDI). TDN: Yes, in essence, an indication that the path is not functioning is given. > 5) Section 4 states: > > "Forward Defect (F) > > This flag indicates a defect upstream of the LSP. It MAY be set in > order to suppress alarms downstream of the LSP." > > This sounds like it is an FDI/AIS type function and IMO the > description/use of this field should be further clarified in the next > revision of the draft. TDN: OK. > > 6) Section 4.3 > It may be worthwhile to include an expiration mechanism. When the > root > node stops transmitting traffic and before the multicast states > expires, > either the root node would need notify the leaves with a "A" flag > or the > leaf would need to expire its probe state as well upon expiration > of its > own multicast state. TDN: Point taken, but I think we need to think about this some more. > Editorial comments > ------------------ > 1) Section 3: > > Replace > "Bootstrapping is accomplished by sending an MPLS Echo Request > Message containing a Connectivity Verification Session object and a > FEC > stack which specifies the LSP for which connectivity verification is > desired." > > With > > "Bootstrapping is accomplished by sending an MPLS Echo Request > Message containing a Connectivity Verification Session object, defined > in this section, and a FEC stack, defined in section 5, which > specifies > the LSP for which connectivity verification is desired." > > 2) Section 3.2, paragraph 5: > > Replace "It this is not possible" with "If this is not possible". TDN: OK. --Tom > > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Aug 04 15:52:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G95gJ-0003Qb-Id; Fri, 04 Aug 2006 15:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G95gI-0003QC-7Z for mpls@lists.ietf.org; Fri, 04 Aug 2006 15:50:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G95gH-0003rz-Ts for mpls@lists.ietf.org; Fri, 04 Aug 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id D8E8D26E22; Fri, 4 Aug 2006 19:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G95gH-0003sH-P3; Fri, 04 Aug 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 04 Aug 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: mpls@lists.ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-rsvp-te-p2mp-06.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Extensions to RSVP-TE for Point-to-Multipoint TE LSPs Author(s) : R. Aggarwal, et al. Filename : draft-ietf-mpls-rsvp-te-p2mp-06.txt Pages : 55 Date : 2006-8-4 This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described. There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-te-p2mp-06.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-mpls-rsvp-te-p2mp-06.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-mpls-rsvp-te-p2mp-06.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: <2006-8-4133431.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-rsvp-te-p2mp-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-rsvp-te-p2mp-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-4133431.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@lists.ietf.org Sat Aug 05 08:48:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9LX9-0004i4-BU; Sat, 05 Aug 2006 08:45:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9LX8-0004hz-0M for mpls@lists.ietf.org; Sat, 05 Aug 2006 08:45:38 -0400 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9LX5-0000si-Gr for mpls@lists.ietf.org; Sat, 05 Aug 2006 08:45:37 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1G9LXH-0000Vg-00 for mpls@lists.ietf.org; Sat, 05 Aug 2006 13:45:47 +0100 Received: from your029b8cecfe ([217.158.132.143] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 5 Aug 2006 13:45:29 +0100 Message-ID: <0d3d01c6b88d$052a0fe0$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: "Tom Petch" , , References: <02c801c68ae7$6a970b40$0601a8c0@pc6> Subject: Re: [mpls] Fw: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt Date: Sat, 5 Aug 2006 11:51:33 +0100 Organization: Old Dog Consulting 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 Aug 2006 12:45:30.0957 (UTC) FILETIME=[091F17D0:01C6B88D] X-Spam-Score: 1.1 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Ben, Tom, Sorry for a belated reply... > Section 4.1, bullet 1 states "P2MP Tunnel table (mplsP2mpTunnelTable) > that sparse augments the MPLS-TE Tunnel table". I'm not exactly sure > what "sparse augments" means. I think Tom has covered this in his answer. > Section 4.2, second paragraph - "When an MPLS-TE tunnel is a P2MP > tunnel, certain objects in the mplsTunnelTable are have new meanings", > remove the extraneous "are". Yup. > Section 6, states "The nature of P2MP tunnels is such that an LSR that > is crossed by a tunnel may either be the ingress of that tunnel or have > precisely one upstream LSP segment (also known as in-segment [RFC3812]) > for that LSP." and "A single P2MP cross-connect has zero or one > in-segment." > > draft-ietf-mpls-rsvp-te section 18.1.1 states "There are two approaches > to dealing with re-merge case. In the first, the node detecting the > re-merge case, i.e., the re-merge node, allows the re-merge case to > persist but data from all but one incoming interface is dropped at the > re-merge node." and "When configured to allow a re-merge case to > persist, the re-merge node receives data associated with the P2MP LSP on > multiple incoming interfaces, but it may only send the data from one of > these interfaces to its outgoing interfaces, i.e., the node MUST drop > data from all but one incoming interface." > > So, if I understand correctly there is no way to detect a re-merge in a > P2MP LSP using the MIB specified in draft-farrel-mpls-p2mp-te-mib? This is a *really* good point, and we do need to fix it. The best way, I think, will be to have a special new type of in-segment in the LSR MIB. We do not want to show this cross-connected (because it isn't) but we do want it to be visible. Actually, this gives us more of a problem in the TE MIB where we need to allow the same LSP to be present on two incoming interfaces. Cheers, Adrian _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Aug 09 08:20:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAn0Y-0002sl-Lj; Wed, 09 Aug 2006 08:17:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAn0X-0002sa-Pi for mpls@lists.ietf.org; Wed, 09 Aug 2006 08:17:57 -0400 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAn0W-0007Ax-7S for mpls@lists.ietf.org; Wed, 09 Aug 2006 08:17:57 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1GAn0T-0002ks-00 for mpls@lists.ietf.org; Wed, 09 Aug 2006 13:17:53 +0100 Received: from your029b8cecfe ([217.158.132.94] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 13:17:54 +0100 Message-ID: <008401c6bbad$d1a0a3e0$9b849ed9@your029b8cecfe> From: "Adrian Farrel" To: Date: Wed, 9 Aug 2006 13:08:13 +0100 Organization: Old Dog Consulting 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: 09 Aug 2006 12:17:54.0734 (UTC) FILETIME=[D79684E0:01C6BBAD] X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [mpls] Fw: Last Call: 'Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base' to Proposed Standard (draft-ietf-ccamp-gmpls-lsr-mib) X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org FYI since some of objects might also be used in an MPLS-TE implementation. Regards, Adrian > ----- Original Message ----- > From: The IESG > To: IETF-Announce > Cc: > Sent: Monday, August 07, 2006 4:12 PM > Subject: Last Call: 'Generalized Multiprotocol Label Switching (GMPLS) > Label > Switching Router (LSR) Management Information Base' to Proposed Standard > (draft-ietf-ccamp-gmpls-lsr-mib) > > >> The IESG has received a request from the Common Control and Measurement > Plane >> WG to consider the following documents: >> >> - 'Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering >> Management Information Base ' >> as a Proposed Standard >> - 'Definitions of Textual Conventions for Generalized Multiprotocol Label >> Switching (GMPLS) Management ' >> as a Proposed Standard >> - 'Generalized Multiprotocol Label Switching (GMPLS) Label Switching > Router >> (LSR) Management Information Base ' >> as a Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send any comments to the >> iesg@ietf.org or ietf@ietf.org mailing lists by 2006-08-21. >> >> The file can be obtained via >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-15.txt >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-10.txt >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-14.txt >> >> > > > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From coonanchorite@doglover.com Wed Aug 09 22:51:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB0eD-0002RU-LY; Wed, 09 Aug 2006 22:51:49 -0400 Received: from [218.94.8.91] (helo=i8awjwt.arhghjd5.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB0eC-00017j-5Y; Wed, 09 Aug 2006 22:51:49 -0400 Message-ID: <83498807404604.B13F49B57A@ZNNT> From: "distinguish" To: Subject: vast connector Date: Thu, 10 Aug 2006 10:51:54 +0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: crZBQDTaBFGJoqjxb498WzEA7iIIJcVBEnSZ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.3 (++++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Thursday August 10, 2006 ASI Entertainment Cell phones on airplanes! (News: 7/27/06) Symbol: A-S-I- Q Price: $0.27 Insider information shows this stock is a real huge earning opportunity alert. Check it out right now! Look at the chart ! Read all the news: Contracts with Saudi airlines and Airone in Place! R E C E N T N E W S: (7/27/06) 1)A- S-I-Q Invention Makes Cell Phones Safe for Use In-Flight and No Annoying Voice Calls- Applied for a patent for a new concept that allows cell phones to be operated in-flight, without interfering with the aircraft's avionics and the ground networks and eliminates the problem of annoying voice calls. Is this the one you have been waiting for ? Could you be printing profits off A.S.I.Q this week? Decide for yourself! Never play leapfrog with a unicorn Idle people lack no excuses A stitch in time saves nine. A man that breaks his word bids other be false to him. ______________ Information within this report contains forward looking statements within the meaning of Section 27A of the Securities Act of 1933 and Section 21B of the SEC Act of 1934. Statements that involve discussions with respect to projections of future events are not statements of historical fact and may be forward looking statements. Don't rely on them to make a decision. Past performance is never indicative of future results. We have received two hundred fifty thousand free t r a d i n g shares from a third party, not an officer, director or affiliate shareholder. We intend to sell all two hundred fifty thousand shares now, which could cause the s t o c k to go down. This company has: negative cash flow from operations, no revenues in its most recent quarter, an accumulated defecit, nominal cash, a going concern opinion from its auditor, nominal net worth, and a reliance on cash advances from related parties (related party transactions). A failure to finance could cause this company to go out of business. This report shall not be construed as any kind of investment advice or solicitation. This is a penny s t o c k and is a high risk security. URGENT: Please, Please Read the Company's SEC filings before you invest . From clogs to clogs in only three generations Age has no friend but the wrinkles of the mind. Lil finger point to de big thumb and sey nah guh. Lightning never strikes twice in the same place. A journey of a thousand miles begins with a single step. . From mpls-bounces@lists.ietf.org Thu Aug 10 05:11:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB6Xe-0004Rn-4r; Thu, 10 Aug 2006 05:09:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB6Xc-0004Rf-E1 for mpls@lists.ietf.org; Thu, 10 Aug 2006 05:09:24 -0400 Received: from qb-out-0506.google.com ([72.14.204.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB6Xb-0007qn-8O for mpls@lists.ietf.org; Thu, 10 Aug 2006 05:09:24 -0400 Received: by qb-out-0506.google.com with SMTP id p36so92179qba for ; Thu, 10 Aug 2006 02:09:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=PrfXaJo6Xq4IFEA+37+y99/MrO9lwTuBXsOSkCTWNAfwwipsBBxpxe+Ue/8P4fCpcR0aTTTwXVXaHVgE+CfOWlfQg0UxBKN9sFcV8t24YdBCTXbyFwbI5LpUVXcd5XhEG2KFBy/7wnkV6wVg++e1RcJbH8DgVZbO6LAYpIBw/G0= Received: by 10.82.123.16 with SMTP id v16mr266483buc; Thu, 10 Aug 2006 02:09:22 -0700 (PDT) Received: by 10.82.112.6 with HTTP; Thu, 10 Aug 2006 02:09:21 -0700 (PDT) Message-ID: Date: Thu, 10 Aug 2006 14:39:21 +0530 From: "sasi sekhar" To: mpls@lists.ietf.org Subject: [mpls] MPLS source code MIME-Version: 1.0 X-Spam-Score: 2.5 (++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1748211118==" Errors-To: mpls-bounces@lists.ietf.org --===============1748211118== Content-Type: multipart/alternative; boundary="----=_Part_1030_27067611.1155200961976" ------=_Part_1030_27067611.1155200961976 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi , I am working on project MPLS.I am looking for MPLS source code.Can anyone send the links. Thanks, sasi ------=_Part_1030_27067611.1155200961976 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Hi ,

I am working on project MPLS.I am looking for MPLS source code.Can anyone send the links.

Thanks,

sasi

------=_Part_1030_27067611.1155200961976-- --===============1748211118== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1748211118==-- From mpls-bounces@lists.ietf.org Thu Aug 10 09:59:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBB2Z-0007rB-HZ; Thu, 10 Aug 2006 09:57:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBB2X-0007r4-DU for mpls@ietf.org; Thu, 10 Aug 2006 09:57:37 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBB2V-0005m9-Cn for mpls@ietf.org; Thu, 10 Aug 2006 09:57:37 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 14:57:34 +0100 Received: from E03MVY1-UKDY.domain1.systemhost.net ([193.113.30.60]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Aug 2006 14:57:18 +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: [mpls] Comments on draft-swallow-mpls-mcast-cv-00 Date: Thu, 10 Aug 2006 14:57:16 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-swallow-mpls-mcast-cv-00 Thread-Index: Aca36upT1wGnbbnSR2OK2eBIAXhxJQEmY/lg From: To: X-OriginalArrivalTime: 10 Aug 2006 13:57:18.0324 (UTC) FILETIME=[E493E340:01C6BC84] X-Spam-Score: 0.2 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Tom, Thanks. I notice that draft-swallow-mpls-mcast-cv-00 is not available from the internet-drafts repository. One response inline (I've snipped the rest). Thanks Ben Thomas D. Nadeau wrote: >> 3) Section 3.2 states >>=20 >> "The Refresh Interval is set to a relatively long value. The root >> MUST refresh the session within this interval. The root MAY jitter >> refresh messages but the Refresh Interval serves as a hard upper >> bound on the jittering. MPLS Echo Requests which refresh the CV >> Session SHOULD be sent on average at approximately one third of the >> Refresh Interval."=20 >>=20 >> However Section 3.1 defines the Refresh Interval as "the minimum >> period before a refresh message is sent in milliseconds." >>=20 >> There seems to a conflict in the two defintions, where Section 3.1 >> states it is a mininum period and Section 3.2 states that it is a >> upper bound. Which is it? >=20 > TDN: The refresh interval for the bootstrapping messages is > supposed to be relatively long -- on the order of > multiple seconds or minutes. So the definition in section 3.2 is the correct one and the definition in section 3.1 needs changing? _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Aug 10 10:43:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBBiq-0006bH-7z; Thu, 10 Aug 2006 10:41:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBBip-0006bB-1F for mpls@ietf.org; Thu, 10 Aug 2006 10:41:19 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBBim-0008Ap-MJ for mpls@ietf.org; Thu, 10 Aug 2006 10:41:19 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 10 Aug 2006 07:41:16 -0700 X-IronPort-AV: i="4.08,111,1154934000"; d="scan'208"; a="310940793:sNHT29346422" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7AEfFAq015579; Thu, 10 Aug 2006 07:41:15 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7AEfDIj006298; Thu, 10 Aug 2006 07:41:15 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 10:41:04 -0400 Received: from [161.44.71.206] ([161.44.71.206]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 10:41:03 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: [mpls] Comments on draft-swallow-mpls-mcast-cv-00 Date: Thu, 10 Aug 2006 10:41:05 -0400 To: X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 10 Aug 2006 14:41:03.0938 (UTC) FILETIME=[0190CA20:01C6BC8B] DKIM-Signature: a=rsa-sha1; q=dns; l=1563; t=1155220875; x=1156084875; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=22Thomas=20D.=20Nadeau=22=20 |Subject:Re=3A=20[mpls]=20Comments=20on=20draft-swallow-mpls-mcast-cv-00; X=v=3Dcisco.com=3B=20h=3DjV4kd8cdRscTMxZNaySS1DzbfC0=3D; b=GaG8ynwnPo5uVTBjwphPWdVm7dgRtRvudkaHxwh413hALwRj+o6XlRWmi0WS4hKXqrEW0Vjk ZQWWscd/Q/BG5WIga/Pb5cQl1ZZ/WIShpHAeW1YuvN+teJDPf6VACLU/; Authentication-Results: sj-dkim-8.cisco.com; header.From=tnadeau@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org On Aug 10, 2006, at 9:57 AM, wrote: > Tom, > > Thanks. > > I notice that draft-swallow-mpls-mcast-cv-00 is not available from the > internet-drafts repository. Yes. George mentioned during his presentation that he misspelled the email address for internet-drafts@ietf.org, but that he was going to push it out post the meeting. Let me check with him today. > One response inline (I've snipped the rest). > > Thanks > Ben > > Thomas D. Nadeau wrote: >>> 3) Section 3.2 states >>> >>> "The Refresh Interval is set to a relatively long value. The root >>> MUST refresh the session within this interval. The root MAY jitter >>> refresh messages but the Refresh Interval serves as a hard upper >>> bound on the jittering. MPLS Echo Requests which refresh the CV >>> Session SHOULD be sent on average at approximately one third of the >>> Refresh Interval." >>> >>> However Section 3.1 defines the Refresh Interval as "the minimum >>> period before a refresh message is sent in milliseconds." >>> >>> There seems to a conflict in the two defintions, where Section 3.1 >>> states it is a mininum period and Section 3.2 states that it is a >>> upper bound. Which is it? >> >> TDN: The refresh interval for the bootstrapping messages is >> supposed to be relatively long -- on the order of >> multiple seconds or minutes. > > So the definition in section 3.2 is the correct one and the definition > in section 3.1 needs changing? Yes, 3.2 is correct. --Tom _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpmwaqargybjoo@triumph-adler.de Fri Aug 11 13:18:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBaeV-0004WR-6S for mpls-archive@lists.ietf.org; Fri, 11 Aug 2006 13:18:31 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBYiu-0005ey-Rs for mpls-archive@lists.ietf.org; Fri, 11 Aug 2006 11:14:56 -0400 Received: from [218.246.213.211] (helo=156.154.24.150) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1GBYEj-0007sI-Jt for mpls-archive@lists.ietf.org; Fri, 11 Aug 2006 10:43:53 -0400 Received: from sauerkraut.striker.ottawa.on.ca ([112.222.202.46 ] helo=mail.nitros3.org) by broken.striker.ottawa.on.ca with esmtp (licorice 3.35 #1 (cartoon)) id 898nlc-0020MM-00 for ; Sat, 12 Aug 2006 08:38:13 +0100 Message-Id: X-Sender: mpmwaqargybjoo@triumph-adler.de Date: Sat, 12 Aug 2006 01:34:13 -0600 From: "Frederic Neff" To: mpls-archive@lists.ietf.org Subject: Mt Hood Hosting Recurring Update Confirmation X-Spam-Score: 3.4 (+++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c C-i-a-l-l-i-s Guarantes 36 hours lasting Safe to take, no side effectts at all Boost and increase cexsual perfoormance Haarder Etections and quick recharge Proven and certified by experts and doctors only $1.56 per t-a-b-s Special offer! These prices are valid until 31th of Avgust! Clisk here: http://hastogo.info antacid militiamen terrier vinyl tess tallyho dyad alcmena gladiolus burroughs doris hummel malleable hutchinson disc transient From arborealantedate@samerica.com Tue Aug 15 10:49:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD0EQ-0001c4-Mg; Tue, 15 Aug 2006 10:49:26 -0400 Received: from [81.215.64.119] (helo=XX-9E286A1DD92B) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD0EO-0000Eg-AS; Tue, 15 Aug 2006 10:49:26 -0400 Message-ID: <74422983397546.DEAC2E2CD4@AIMHQLC> From: "cosmetic" To: Subject: vast bindweed Date: Tue, 15 Aug 2006 17:48:11 +0300 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: ToUhBrVvoNg7BdZ66QEbA3Gkt7sFVvX81LKn Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Most reliable methods of sstock analysis increasing your bottom line Tip Top Equities August Issue: A GAO Make no mistake: Our mission at Tip Top Equities is to sift through the thousands of underperforming companies out there to find the golden needle in the haystack. The m i c r o - c a p diamond that can make you a fortune. More often than not, the s t o c k s we profile show a significant increase in s t o c k p r i c e, sometimes in days, not months or years. We have come across what we feel is one of those rare deals that the public has not heard about yet. MY WINNING PICK IS AGA O!!! Get on AG AO First Thing on TUESDAY, it's going to expload! C o m p a n y: AGA RESOURCES INC S y m b o l: AG AO C u r r e n t P r i c e: $2.15 T a r g e t P r i c e: $4.10 The p r i c e is the minimum for last week and it will b oom on Tuesday! Recommendation: "S T R O N G B U Y" starting on TUESDAY, AUGUST 15, 2006. There is a clear buy signal for this stock. Grab your chance to get fast earnings with this new promising stock! Breaking News: A G A Resources, Inc. (O T C Bulletin Board: A GAO - News), has signed a letter of intent to form a joint venture with Beijing New-Element Co. Ltd. ("New-Element"), a promotion and marketing company based in Beijing.Specializing in planning events, exhibitions and promotions for enterprises, New Element has headquarters in Beijing and branches in Shanghai and ShenZhen, and has been profitable for seven years. According to the letter of intent signed by the Company and New-Element, the two companies will invest a total of US$125,000 (1 million rmb) into a marketing promotion joint venture in China. The Company will invest US$62,500 (0.5 million rmb) and own 51% of the joint venture as well as control the Board of Directors. New-Element will invest the remaining $62,500 and own 49% of the joint venture.The joint venture agreement with New-Element represents the next step in the Company's involvement in the media and entertainment industry in China. Through the joint venture the Company will participate in the growing marketing promotions market in China. About the Company: A G A Resources, Inc. is an Exploration Stage Company. The Company has acquired a mineral property located in the Province of British Columbia, Canada and has not yet determined whether this property contains reserves that are economically recoverable. The Company has started exploration. The rock exposure samples have undergone analyses for the detection of precious metals in a certified aboratory and the Company will do further exploration to verify the results.Members should pick up AG AO as early as possible on Tuesday. This news is going to send AG AO off the charts! We all know that in the this business it's the big announcements that makes these s t o c k s explode!!! We see this as a huge p r o f i t taking a Deal ON AGA O. Success has many fathers, while failure is an orphan. Fortune favours the brave Visit your aunt, but not every day of the year All you need is love Cleanliness is next to Godliness. From mpls-bounces@lists.ietf.org Tue Aug 15 17:06:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD61g-0007QT-D7; Tue, 15 Aug 2006 17:00:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD61f-0007QD-Jb; Tue, 15 Aug 2006 17:00:39 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD61c-0001Ge-IJ; Tue, 15 Aug 2006 17:00:39 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 15 Aug 2006 17:00:36 -0400 X-IronPort-AV: i="4.08,128,1154923200"; d="scan'208"; a="96972994:sNHT38356992" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7FL0ZHe007969; Tue, 15 Aug 2006 17:00:35 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7FL0YKJ017312; Tue, 15 Aug 2006 17:00:35 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Aug 2006 17:00:34 -0400 Received: from swallow-mini-mac.cisco.com ([10.86.116.2]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Aug 2006 17:00:32 -0400 Received: from cisco.com (localhost [127.0.0.1]) by swallow-mini-mac.cisco.com (Postfix) with ESMTP id BAB352C2FA4; Tue, 15 Aug 2006 17:00:08 -0400 (EDT) To: proceedings@ietf.org From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1-RC3; GNU Emacs 21.2.1 Date: Tue, 15 Aug 2006 17:00:08 -0400 Message-Id: <20060815210008.BAB352C2FA4@swallow-mini-mac.cisco.com> X-OriginalArrivalTime: 15 Aug 2006 21:00:32.0853 (UTC) FILETIME=[D8F64050:01C6C0AD] DKIM-Signature: a=rsa-sha1; q=dns; l=31280; t=1155675635; x=1156539635; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=swallow@cisco.com; z=From:George=20Swallow=20 |Subject:MPLS=20WG=20minutes |To:proceedings@ietf.org; X=v=3Dcisco.com=3B=20h=3DhsObUJU5iKjL2ODYE6aAP8x4abY=3D; b=VyHc0xUtcDKjcxoYRj2LkoUr9bdLYtQHuMGmiL63aeSgd8c4mzsGelppThb/+sucVKypr6/s 37Tue4F2GRu+y1O2AHJsvSbHsdz8qOxiS2nJ9BIEQytayLAxR4hFd+tC; Authentication-Results: rtp-dkim-2.cisco.com; header.From=swallow@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b4f8b2857a7a1a95c927652b5e03785d Cc: mpls@ietf.org Subject: [mpls] MPLS WG minutes X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org July 12, 2006 Minutes of the MPLS WG Monreal, Canada ======================================================================= T-MPLS liaison - Loa ------------------- The work is occurring in Q9 and Q12 of SG15. IETF was invited to the Ottawa meeting last month (as was MFA - who pretty much supported IETF view). 3 IETF reps. IETF hijacked agenda (2 days discussion instead of planned afternoon). Good progress. A couple of liaison statements have been exchanged between IETF WGs and ITU-T SGs on T-MPLS. (Copies on the data tracker.) MPLS WG had four major comments: 1) Requirements. ITU-T responded that their requirements were implicit. Loa's view is that it's hard to agree reqs unless they're written. but at any rate that's the ITU-T's process, though they have promised to write them down and send them to us in this instance. 2) PHP. Long discussion: Move from "do not support" to "do not use" is a step in the right direction. MPLS issues with PHP don't occur as P2P Ethernet only in first phase. ITU-T accepted that PHP can be useful! (to avoid multiple popping). Acceptance that will be used in future versions (to do MPLS services over T-MPLS). 3) ITU-T agreed to use MPLS Ethertype - makes IETF the design authority. Agreed to use (G)MPLS change process for extensions. Adrian will do something ASAP so we can forward the doc to the IESG. 4) Agreed not to reserve labels in advance but to come to IETF if ITU-T need any (as they did to get label 14 for Y.1711.) PWE3 liaison - stated that Y.1711 will be used in first version. Motivation is probably that it's all they have. Will revisit in future (in cooperation with Q5/SG13). We need to respond to outstanding liaison on G.8110.1 by Aug 1 so please read/comment. WG chairs for MPLS and PWE3 will create a response jointly. P2MP-TE - Rahul --------------- Brief update on P2MP RSVP-TE draft. Draft has gone through last calls etc. Going through major comments, and showing how they're being addressed. 1) Clarifying scope of P2MP ID as root node scope. Need to drop one comment and replace by another. 2) Semantics of P2MP ID. Removing comment. 3) Tunnel ID semantics as in 05.txt. 4) Procedure for fixing re-merge has two options (data plane based and control plane based). Data plane one wasn't clear enough. So rewording to explain that PathErr has two sets of objects. 5) no change to wording on interop of two re-merge approaches. 6) some other clarification. So 06.txt will be posted to incorporate consensus. Will then ask for comments on delta between 05 and 06. P2MP-TE MIB - Adrian -------------------- Rule is that if you have a protocol then you need a MIB (useful rule!) Already have MPLS TE MIB. Protocols built on TE protocols. So trying to reuse as much as possible. Turns out that no changes are needed in LSR MIB as it allows arbitrary cross-connects. Need to explain how to use the LSR MIB (easy). Do have to be careful with bud nodes (drop and continue) to make sure the text makes it clear how those should be treated. TE MIB needs more work as it models the protocol rather than the switch. Need to redefine interpretation of a couple of objects. Key one is mplsTunnelEgressLSRId. Also extensions for extra info. Adrian presented a diagram showing changes to MIB. Change is that some info now needs to be per-destination rather than per tunnel - so need to go via an extension which has a table per leaf which can then point to EROs/RROs. Also can do performance per branch. Outstanding question on modeling sub-groups (done in protocol). If so then slot between tunnel table and tunnel dest table. Not modeling protocol perfectly (as has ERO and set of secondary EROs, but we're putting it all in the same level as destination - probably the right thing to do as at config time you don't know which will be the primary ERO). Next steps include getting operator input on whether this is correct plus review from MIB experts and those who did the protocol. Technically we need a MIB for any WG doc at the time that protocol goes to IESG for review. LDP Capabilities - Bob/Rahul ---------------------------- Rahul ----- 2 overlapping drafts - one from Bob Thomas, one from Shivani/Rahul/John. An agreement to merge drafts was made among the author prior to the meeting. Key issue is that LDP has been enhanced (e.g. GR, FT, upstream label assignment). Until upstream draft there was no mechanism in LDP for managing the use of LDP enhancements. May be future enhancements down the road. So capabilities are associated with enhancements. It isn't the case that all enhancements need to advertise a capability. Upstream label does. But need a mechanism for peers to negotiate the capability at session establishment time (or any time later). Allows a peer to activate an enhancement by activating the capability. Have leveraged the mechanisms used for BGP capabilities. Loa - what's the delta between the drafts, and how do you solve that? Rahul - 2 problems. Advertising capabilities at session establishment and doing so later without tearing down the session. Up to WG to provide feedback on that. One draft does both, one only does session establishment. but WG may say they only want to solve one problem. Bob --- Plan is to have a draft for each enhancement, and that if the enhancement needs a capability then that would be documented in the draft. IANA would assign a code point for that capability. Assumption is that each LDP speaker implements a set of capabilities (may be empty set). if a capability is enabled then speaker will perform associated actions. Enabled capabilities are advertised at session establishment time. One capability will advertise that speaker can do dynamic capabilities. If enabled then at any time later one or other speaker can enable a dynamic capability. There's an acknowledgment mechanism for dynamic capabilities to ensure that message is processed with the same capability state as it was generated (same mechanism used for dynamic BGP capabilities). Also new capability message defined (for dynamic capabilities). Optional overall, but needed if supporting dynamic capabilities - and only sent if both speakers advertised dynamic capabilities during initialization. So next step is to produce merged draft with detailed procedures. Will then enable a new version of the upstream draft to be written with a definition of upstream label assignment capability. George - my only comment is that I wish we'd started this a few years ago. Loa - do we have a routing area AD here? Don't seem to. But well within charter, especially as have taken on upstream work. IANA registry for flags field in RSVP session object - Adrian ------------------------------------------------------------- issue is only have 8 bits. Registry was originally in RFC4420 (LSP attributes). Out of scope for that so putting it in a new ID. But may be other registries that would be useful. But no point sitting on this work while we figure out what else we need to do. Now a WG idea - Loa gave permission last night and Adrian submitted last night. So Adrian's view is we should just last call it. George - I think I should have equal say in this ;-) But no objection in this case... Updating upstream labels - Eric ------------------------------- This is an open issue in upstream label draft so I want to brainstorm on a solution. We know that we want to use Upstream Assigned labels on multicast data packets. Easy to do on P2P or P2MP media as you know who put the top label on. Problem comes with MP2MP media such as Ethernet or MP2MP LSPs (work in L3VPN on the latter). In theory could use L2 header info (at least on Ethernet) but not such a great idea as changes the forwarding logic to lookup the MAC source. Also want to avoid operational impact. Solution is a context label - so push on UA label then a context label to tell receiver who put the packet on. So context label lets you identify table to lookup UA label. But problem is that context labels hit the same problem (as they would be upstream assigned as well) - though there would be fewer of them. Loa - can't you assign them downstream? Eric - no as this is MP2MP. options 1) Take low-order 20 bits of IP address. Probably unique in the required scope. Certainly in Ethernet is useful as routers are likely to be in one subnet. But in MP2MP LSP might not work as no presumption that will be in common subnet. 2) overflow into a second level stack entry. Transparent to forwarding path as downstream doesn't need to know where label ends (can still use first label to look up into a second table). If each node needed <= 256 UA labels then could work as we have a total of 40 bits (32 for host, 8 for label). Or we could use low order 24 bits (probably unique in SP network) and then get 64k UA labels per node. 3) use random number. Seems strange. Would need collision detection/resolution. But turns out that probability of collision is low given 20 bit space (would be even lower with 24 bit space). Also since all nodes don't have to choose simultaneously you could avoid any numbers that had already been picked. A very long discussion ensued without conclusion. To be continued on the list. Giles' raw notes on that discussion are attached at the end of the minutes. P2MP LDP requirements - Jean-Louis ---------------------------------- Since Dallas, the draft has become WG doc. We added req that leaf add/remove mustn't impact data transfer towards other leaves (important), detailed other reqs, removed controversial text on routing protocols (used to say shouldn't require deployment of new RP - now says solution should have key objective of minimizing additional state/processing in network), detailed reqs on MP2MP LSPs, incorporated comments from Ben Jenkins, other clarification edits. P2MP rerouting. Quite challenging when reroute isn't due to network failure - since we want to avoid packet loss/duplication during reroute. Hard to do. always tension between loss/duplication in connectionless schemes like LDP. So req is to minimize loss/dup and be able to avoid one or the other (but not both). Ideally let operator choose between loss and duplication. MP2MP LSPs are optional as there are other approaches at application level. At any rate reqs for P2MP also apply to MP2MP. Especially must support transit node failures including root node failures. Also must avoid routing loops that cause exponential growth of traffic. Challenge here is that LSR may receive traffic for an LSP over multiple interfaces. Also added some reqs - e.g. not receiving traffic back that send on MP2MP LSP. So draft is now pretty stable but need more feedback - esp on new changes. Plan to update draft to account for comments by end of Sept. So v02 should be ready for WG last call. Rahul - does draft talk about MP2MP case on LANs? Jean-Louis - only cover P2MP on LANs saying that should avoid ingress replication. Req applies equally to MP2MP. Yakov - on packet duplication/loss doc needs to be *very* clear that you can avoid either but can't avoid both. ?? - in which situation would you allow duplication? Jean-Louis - some apps may not be sensitive to duplication but may be to loss. ?? - examples? Jean-Louis - can't think of any mLDP draft - Bob Thomas ----------------------- Draft is by Ina/Ice. Update to status of the LDP P2MP draft. Ice was going to present and had prepared slides but thought meet was Monday and couldn't be here. Not much time so will go through topics quickly 1) root node redundancy. Problem in MP2MP LSPs as only one root address - suggests a SPOF. Draft has mechanism for providing redundancy if root node fails - by assigning multiple roots. Each node is configured for a set of roots, accepts traffic from all but only sends to one (local policy). so effectively you get multiple MP2MP LSPs (one per root). If a root node fails then that nodes stop sending to that LSP and use another one. George - how do we discover failure? Bob - IGP. So leaf can switch at IGP reconvergence speed. Also allows load-balancing over multiple roots. 2) MLDP Make-before-break. Intent is to minimize packet loss/duplication during switch-over from one tree to another. 2 situations to apply this - link failure (so need to re-signal), or new link etc. So single mechanism for both of these. Acknowledgment mechanism. Message is sent by upstream LSR to a downstream that has been sent a label mapping. Ack is sent when LSR is attached to the LSP (i.e. presence on LSP has been signaled to root and acknowledged by upstream). Rahul - have issue on make-before-break. You're adding complexity to mLDP to solve a problem which you don't really solve. If you want to solve it then use RSVP-TE (which has its own tradeoffs - granted). Bob - but in case of good news we do have make-before-break here. switch-over to new LSP doesn't occur until signaling has been completed and acknowledged. Rahul - in that case I'd be impressed if you can prevent both duplication and loss Bob - I believe you don't have either in the good news case. Rahul - don't believe that's possible. Jean-Louis - even with notification you may have transient duplication. Bob - needs atomic forwarding plane update. Rahul - I don't think that's enough. Summary - these procedures should be optional, don't require data-driven events to trigger switch-over from old LSP to new LSP. But need to convince WG. 3) Upstream LSR selection in LAN case. would like to avoid sending duplicates to downstream routers. Would like downstream routes to all pick the same upstream for an LSP. Mechanism is to number upstreams from lower to higher IP address and then to use a formula to pick one (sum opaque bytes in the FEC and modulo it with # of upstreams). 4) wildcard FEC. intention is to use this for label request, withdraw and release (to make peer re-advertise/withdraw/release all mappings of FEC type), 5) generic LSP identifier Yakov - why not use wildcard FEC in LDP at large. Bob - 3036 has wildcard FEC but two flaws: 1) not the notion of FEC types (so withdraws everything) 2) use is restricted (can't be used for label requests). Yakov - so you're saying that 3036 has defective wildcard FEC. So let's correct that! Bob - tried to fix it in 3036bis. But pointed out that to do that wouldn't be following IETF procedure. Yakov - so write a new doc that is applicable to LDP at large (not just mLDP) and can be used for any FEC type. Bob - good suggestion Load-Balancing between candidate upstream LSRs - Shuying -------------------------------------------------------- When there are multiple candidate upstream LSRs the load may be unequally balanced between them. Also may get traffic disruption in some cases (adding LSRs or better path emerging). The mechanism here does per-flow balancing. Downstream selects candidate based on ECMP algorithm using node address and opaque value in FEC as inputs. Aim of make before break to make traffic continuous. so send upstream label request to new upstream LSR. Don't install new label in LFIB when receive label mapping, but wait until an unknown multicast packet is received. MPLS Multicast Verification - George ------------------------------------ We talked to various customers. Showing loosely disguised slide from one of them. Issue is if economic impact of even a brief outage may be serious (either direct liability or because other competing technologies may steal customers). Example applications are stock tickers or TV feeds. Dino - quantify those outages. George - 50ms. When you drill down the requirement might not be that stringent but need to aim higher than you're gonna hit. Bullseye is zero :) The fast recovery time drives the need for heavy-duty OAM. May get to the point where if there's a problem they'll shut down feeds to everyone (rather than losing feed to one broker who will then sue them). Also issue of very high numbers of end points. So need some kind of auto configuration. Solution is a two-phase approach (config and then heartbeat both from head end). Heartbeat (phase 2) is very simple (and will be sent at high frequency). Not yet defined if will be a new packet type or not. LSP echo request. Carries FEC stack and discriminator. First thing you do if you receive it is to verify that you're actually the exit point. Define minimum interval for transmit. Also multipliers for down indication and a period to jitter replies. Refresh interval for control message (soft-state model). Also flags for admin down and FDI. Might change to a code-point rather than flags. Current thought is that tail ends should simply be configured to accept OAM for any combination of mLDP and P2MP RSVP-TE (so no need to explicitly configure sessions). Might be time to add security authorization to LSP ping, but that would be a separate draft. Receivers start listening for these messages immediately. Head end will start sending probes before sending a control message (to avoid race conditions). Thought of other solutions such as longer initial interval but these seemed a bit useless... This could apply to other applications, but has been optimized for the above. So root probes leaves (respecting interval configured). Leaves don't send replies - seems like a bad idea to have lots of messages saying "I'm still alive". Issues: Can we do tail repair or do we need message sent back to head end? RDI notification in message? Also discussion on timestamps/seq numbers to do jitter/packet loss measurements. If can be done without the hardware having to do to much work then can do. Or can have two packet types. Would like more input from people on whether this kind of stuff is "nice to have" or essential. In the RSVP case you know all the leaves in your tree. if you haven't heard from some then might be worth sending LSP ping with list of addresses saying "please only reply if you're on this list". May also be useful with mLDP. Will be posting draft right after the meeting and hopefully bringing something pretty mature to the next meeting. Have also agreed to work with Adrian to see which parts of this should be in his draft. Ben Niven-Jenkins - we (BT) have requirement for this. One comment though - why use LSP ping to bootstrap it, why not use the signaling protocol? George - tension is that we have two signaling protocols but would like one mechanism. In P2P case we did one mechanism (using LSP ping to bootstrap), so seemed sensible to do the same for P2MP. Don't want to create more mechanisms than needed. Ben - in draft as currently stands not much discussion of how to deactivate the OAM. Need procedures to deactive OAM before tearing LSP down. George - right now the RDI is only control. Support for ECN and PCN in MPLS networks - Bruce ------------------------------------------------ ECN has been a standard for a while (RFC3168). uses 2 bits to encode 3 states (so convey "can end system support ECN" and "did this packet experience congestion"). Prior to ECN TCP could only use drops to respond to congestion. Actually ECN can be used with protocols other than TCP. Presented draft on this 6-7 years back. Re-presenting as ECN has become more popular recently. Issue is that only the 3 EXP bits are suitable for this, and they are already widely used for DiffServ. Even stealing one bit could be tricky. 1999 proposal (Davie et al) suggested stealing one bit (was a WG draft but issues around lack of solutions to hard problems plus lack of interest in ECN.) Can overload to encode 3 states in one bit (only issue is that as you flip the bit you could end up flipping twice if hit congestion twice). 2000 proposal (Shaman??) only carries CE bit. ECN is in the IP header so no need to carry in MPLS header. RFC3270 defines usage of EXP field for DiffServ. So now with 6 years experience we have better understanding of both ECN and DiffServ. Proposal in current draft is to use a codepoint instead of a bit since may not need ECN on all traffic (e.g. use on data but not on voice). So potentially could deploy 6 classes and still have ECN on two of them. so most parsimonious use of EXP. Also using Shaman draft concept of handling ECT at egress. Also aim is to be permissive - i.e. allow other uses of EXP. Concrete example of adding ECN to AF11 class by adding an additional EXP codepoint for "AF11 and CE". one reason to be interested in this is PCN support. PCN like ECN but needs 3 code-points rather than 2. To summaries: There is much more interest in ECN/PCN now than 6 years ago. This is a very efficient in use of codepoints consistent with earlier work, with RFC3168 and with RFC3270. The TSV working group would prefer this to be done in the MPLS WG. The reason Bruce started in TSV is that you need ECN expertise to understand it. If MPLS WG is happy to take it then will do it here, and get review from ECN experts elsewhere. ?? - what about colors in AF11 case? Bruce - was assuming you weren't looking at drop precedence here. ?? - what about L-LSPs, you can have 2 bits there? Bruce - focused on E-LSPs as more widely deployed and also more difficult. Dino - were you thinking of using remarking logic that already exists at ingress? Bruce - processing on ingress is similar to DiffServ but egress is more complex. P2MP root discovery - Yang Yang ------------------------------- Both RSVP and LDP drafts assume that leaf knows where the root is. But how does leaf find the root? Could use routing protocols (drafts on this), or could use directory services. The assumption is that each node knows where the directory server is (configure or find with routing protocols). Examples with LDP and RSVP. Difference is that in RSVP case the server needs to tell the root about the leaf, whilst in the LDP case the leaf just does a join. The benefit is dynamic discovery without use of routing protocols in a manner that can be applied to LDP and RSVP-TE and which scales to large networks with lots of changes. We need to look at security issues (given use of DS). We also need to look at inter-domain issues (how to synchronize DSes). First version of draft doesn't really detail the procedures. do we need 2 drafts - one for reqs and then one with detailed procedures. Satoru?? (Japan Telecom) - requirements make sense. One question about requirements in routing protocol. Yang Yang - you may need to extend IGP if you want dynamic means to find root. In inter-domain case may need BGP. Satoru?? - first step is to focus on routing protocol extensions. Yakov - I have no doubt that you can use DS for this, but why? P2MP LSPs don't exist for their own sakes but are used for applications (e.g. VPLS and 2547). The applications do discovery as a byproduct of the application itself. The DS adds complexity to the system. Don't know of any applications where the directory would be a benefit. George - let's take this to the list. Explain the problem set and how this would enhance the system. I had basically the same question as Yakov - putting a meta-layer in to get the info doesn't seem to be a solution. Need to understand how you're going to use it. Routing extensions for discovery of P2MP leaves - Jean-Louis ------------------------------------------------------------ There are obvious issues with static configuration at ingress (configuration overhead plus inability to do dynamic add/removal of leaves). This draft allows discovery of leaf LSRs, but not of multicast group membership (this is not IP multicast). Relies on IGP extensions (ISIS and OSPF node capabilitities) - allowing LSR to advertise its desire to join/leave tunnel. Very useful in BGP free and IP multicast free core routers. so new TLV - which carries the set of groups the LSR belongs to. ISIS capability TLV or OSPF router information LSA. A node needs to add/delete an entry in the TLV to join/leave group. This is only useful for core router where join/leave frequency is low. Key is that joining/leaving a tunnel isn't synonymous with joining/leaving a group. Plan is to review encoding of group ID. Currently 32 bit integer. Might become variable length opaque group ID. This is a first cut so need more work (and more feedback) before requesting WG adoption. George - would like to see requirements at a higher level (same as previous speaker). So where does this fit into the system as a whole? Don't put stuff in the IGP just because it's convenient to do so. Need a real strong requirement for this. Adrian - at a high level it looks good. But we need work on policy/security. Current draft says "no security issues" but joining someone else's tree is a security issue! Toerless - something like tail-end join in mLDP or PIM. Problem is doing this by flooding. Why tell the whole world you want to join a tree when only the head-end cares about it? Also isn't one of the targets for this RSVP P2MP tunnels between P nodes, but not between PE nodes? So PE does mLDP and then P node does this procedure at that point? Unicast join might be better at that point. Jean-Louis - there isn't 1:1 mapping of P2MP tunnels and P2MP groups. George - are you thinking of automesh? Jean-Louis - this is built on automesh. Toerless - but still flooding when you have limited number of receivers. Lou?? - have you thought about applicability of Leaf Initiated Join to avoid flooding? Jean-Louis - if you do a join then which protocol will you use? We assume you're in the core. Lou?? - I think you should consider LIJ JP - just a question for George. You want to see more discussion of requirements. Requirement is well-scoped (i.e. automesh) so what do you want? George - want to see consensus on list that people want this... Extensions to RSVP-TE FRR - Feng Jun ------------------------------------ issue is that when tunnel breaks the refresh messages also switch to the backup path. aim is to know which protected tunnels use which backup tunnels. PLR knows already, but MP doesn't. So tell this info to the MP using new messages (MP_NOTIFY and MP_ACK). Then only need to send refreshes on the backup tunnel. JP - simple Q. What advantage does this scheme have? what problem are you trying to solve? George - no time for questions; ask on the list. LDP/IGP Sync - Luyann Fang -------------------------- This is an expired draft, Luyann wants to reissue. Targeted as an informational RFC as it proposes no protocol changes. Same class as RFC3137 (IGP/BGP sync). Would like to ask for show of hands if can be a WG doc. George - needs to ask on the list, but might be worth getting sense of the room now... Sense of room seemed favorable - will be decided on list. The meeting was adjourned. Detailed discussion on upstream labels ------------------------------------- Yakov - on P2P media you can't have upstream labels anyway so don't worry about that. Eric - good point. Yakov - in order for any collision detection to work wouldn't each edge node need to keep info about all other edge nodes? One advantage of LDP over RSVP is that leaf doesn't need to know about all the other nodes. So doesn't that defeat the whole purpose of using LDP? Eric - but any use of upstream assigned labels needs a lookup table that is specific to the upstream node. Toerless - I'm worried about performance requirements in routers. We may be simplifying the control plane at the cost of forwarding plane performance. Eric - well yes, this mechanism does add an additional label. Toerless - can't we look at a solution that has single label (though that complicates the control plane by dividing the label space). We did that in 2000 so can be done. Eric - we could have a protocol to dynamically divide the label space. But there are still problems identifying the space. Any such mechanism seems complex/fragile. Yakov - don't have to have the same mechanism for Ethernet and MP2MP. So could use 20 bits on Ethernet and on MP2MP take advantage of the fact you have a root node and then get the root node to assign labels to the leaf nodes. Eric - but that has a lot more control protocol (which would make this as bad as RSVP). Yakov - but the same is true of collision detection. Eric - if the root node talks continuously to the leaves using a new protocol for assigning labels then that's bad. Jean-Louis - static could be ok. Operator just takes 15 minutes to assign a label. Eric - if SPs have consensus that they're OK assigning 20 bit values then that's great. Jean-Louis - it's just like a loopback Eric - if SPs don't care then I don't care. Toerless - using locally configured loopback as the context is just like that. Eric - but 20 bit values are different from IP addresses. Toerless - what is the most simple protocol that Eric wouldn't consider fragile and which doesn't depend on the root node? Issue here is that the Root node may be a P node. Eric - yep as Toerless said makes it hard to have a redundant root node. Kireeti - if providers such as Jean-Louis say static is OK then that's OK. Thomas Morin - what about using a perfect hash? So each node calculates labels assigned to other nodes. Works as soon as each node knows that another node needs a label. Doesn't need a protocol but is complex. Eric - but perfect hashes are like static config but done dynamically. Problem is that when a new address comes along it breaks the whole thing. Larry - I'd advocate static solution as some implementations may want to compress the 20 bit space to something far smaller. Eric - thing is that static context labels won't reduce total number of labels. Thomas (different Thomas) - don't like idea of static labels as don't want to manage it. Jean-Louis - this is same problem as loopback addresses. Yakov - we need to think through implications of static assignment. If you have static assignment and you configure the same label for two upstream PEs then you can end up in a steady state where traffic gets misdelivered between two VPNs. Eric - Thomas, are you an SP? Thomas - yes. George - feel fairly confident that this discussion will continue on the list. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From baldwinanxiety@berlin.com Wed Aug 16 01:25:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDDu0-0001ee-Sf; Wed, 16 Aug 2006 01:25:16 -0400 Received: from [222.252.225.50] (helo=fpiuh.irfet.ameritech.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDDtz-0000BI-34; Wed, 16 Aug 2006 01:25:16 -0400 Message-ID: <30444768903771.80669581C5@ZXP5Q> From: "allan" To: Subject: big churchwomen Date: Wed, 16 Aug 2006 12:23:55 +0700 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: zyXwLhEdm6rytWolEU8fgSgG97wNM48yoS8x Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.2 (++++) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Tiip TTop Equitiess August Issue: A GAO Make no mistake: Our mission at TTip Toop Eqquities is to sift through the thousands of underperforming companies out there to find the golden needle in the haystack. The m i c r o - c a p diamond that can make you a fortune. More often than not, the s t o c k s we profile show a significant increase in s t o c k p r i c e, sometimes in days, not months or years. We have come across what we feel is one of those rare deals that the public has not heard about yet. MY W I N N I N G PICK IS AG AO!!! Get on AGA O First Thing on WEDNESDAY, it's going to expload! C o m p a n y: AG A RESOURC ES I NC About the Company: A G A Resources, Inc. is an Exploration Stage Company. The Company has acquired a mineral property located in the Province of British Columbia, Canada and has not yet determined whether this property contains reserves that are economically recoverable. The Company has started exploration. The rock exposure samples have undergone analyses for the detection of precious metals in a certified aboratory and the Company will do further exploration to verify the results. Members should pick up A GAO as early as possible on Wednesday. This news is going to send AG AO off the charts! We all know that in the this business it's the big announcements that makes these s t o c k s explode!!! Symbol: A GAO Current P r i c e: $1.90 Target P r i c e: $4.10 The p r i c e is the minimum for last week and it will bo om on Wednesday! Recommendation: "STTRONG BUYY" starting on WEDNESDAY, AUGUST 16, 2006. An old fox is not easily snared Absence makes the heart grow fonder. If trousers say massah teef, yuh can't doubt am. It is what is in the mind when sober, that comes out of the mouth when drunk Breaking News: A G A Resources, Inc. (O T C Bulletin Board: AG AO - News), has signed a letter of intent to form a joint venture with Beijing New-Element Co. Ltd. ("New-Element"), a promotion and marketing company based in Beijing.Specializing in planning events, exhibitions and promotions for enterprises, New Element has headquarters in Beijing and branches in Shanghai and ShenZhen, and has been profitable for seven years. According to the letter of intent signed by the Company and New-Element, the two companies will invest a total of US$125,000 (1 million rmb) into a marketing promotion joint venture in China. The Company will invest US$62,500 (0.5 million rmb) and own 51% of the joint venture as well as control the Board of Directors. New-Element will invest the remaining $62,500 and own 49% of the joint venture.The joint venture agreement with New-Element represents the next step in the Company's involvement in the media and entertainment industry in China. Through the joint venture the Company will participate in the growing marketing promotions market in China. Recommendation: "STRONGG BUYY" AG AO starting on 10:00 a.m. 16 June 2006. Watch AGA O p r i c e fast rising. Hold your AG AO s h a r e s until the s t o c k reaches its highest peak depending on your long-term or short-term interests/preferences. Do not panic in case of some fluctuations. We see this as a huge p r o f i t taking a Deal ON A GAO. Excess of ceremony shows want of breeding Every cloud has a silver lining. It takes two to tango When good cheer is lacking, our friends will be packing While there is life there is hope. From conceiveblackwell@alumnidirector.com Wed Aug 16 08:13:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDKHX-0005GZ-1A; Wed, 16 Aug 2006 08:13:59 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDKHW-0002TV-Vp; Wed, 16 Aug 2006 08:13:59 -0400 Received: from [222.109.30.101] (helo=vuie.igolk.aol.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GDKDu-0002jv-4k; Wed, 16 Aug 2006 08:10:14 -0400 Message-ID: <87917368322783.DD86EB8513@JYPMAIC> From: "bath" To: Subject: buckthorn Date: Wed, 16 Aug 2006 21:08:37 +0900 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: 9gz71I7QC4x017j1K4Kq3Lr1xrLzBBjN75dy Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.7 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Tiip Topp EEquities August Issue: A GAO Make no mistake: Our mission at Tipp TTop Equitties is to sift through the thousands of underperforming companies out there to find the golden needle in the haystack. The m i c r o - c a p diamond that can make you a fortune. More often than not, the s t o c k s we profile show a significant increase in s t o c k p r i c e, sometimes in days, not months or years. We have come across what we feel is one of those rare deals that the public has not heard about yet. MY W I N N I N G PICK IS AGA O!!! Get on AGA O First Thing on WEDNESDAY, it's going to expload! C o m p a n y: A GA R ESOURCES IN C About the Company: A G A Resources, Inc. is an Exploration Stage Company. The Company has acquired a mineral property located in the Province of British Columbia, Canada and has not yet determined whether this property contains reserves that are economically recoverable. The Company has started exploration. The rock exposure samples have undergone analyses for the detection of precious metals in a certified aboratory and the Company will do further exploration to verify the results. Members should pick up A GAO as early as possible on Wednesday. This news is going to send AGA O off the charts! We all know that in the this business it's the big announcements that makes these s t o c k s explode!!! Symbol: AGA O Current P r i c e: $1.90 Target P r i c e: $4.10 The p r i c e is the minimum for last week and it will boo m on Wednesday! Recommendation: "SS TT RR OO NN GG BB UU YY" starting on WEDNESDAY, AUGUST 16, 2006. A wise man will hear, and will increase learning; and a man of understanding shall attain unto wise counsels. Flies never visit an egg that has no crack It never rains but it pours Breaking News: A G A Resources, Inc. (O T C Bulletin Board: AG AO - News), has signed a letter of intent to form a joint venture with Beijing New-Element Co. Ltd. ("New-Element"), a promotion and marketing company based in Beijing.Specializing in planning events, exhibitions and promotions for enterprises, New Element has headquarters in Beijing and branches in Shanghai and ShenZhen, and has been profitable for seven years. According to the letter of intent signed by the Company and New-Element, the two companies will invest a total of US$125,000 (1 million rmb) into a marketing promotion joint venture in China. The Company will invest US$62,500 (0.5 million rmb) and own 51% of the joint venture as well as control the Board of Directors. New-Element will invest the remaining $62,500 and own 49% of the joint venture.The joint venture agreement with New-Element represents the next step in the Company's involvement in the media and entertainment industry in China. Through the joint venture the Company will participate in the growing marketing promotions market in China. Recommendation: "SS TT RR OO NN GG BB UU YY" AGA O starting on 10:00 a.m. 16 June 2006. Watch AGA O p r i c e fast rising. Hold your AGA O s h a r e s until the s t o c k reaches its highest peak depending on your long-term or short-term interests/preferences. Do not panic in case of some fluctuations. We see this as a huge p r o f i t taking a Deal ON A GAO. When the blind leadeth the blind.. get out of the way. Hungry nah know bam-by.. Hungry nah know bam-by. Yuh can't chew bone with gum.. From bogusbreach@rqhp.havebzn3.vg Wed Aug 16 15:58:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDRXL-00023N-GN; Wed, 16 Aug 2006 15:58:47 -0400 Received: from alille-252-1-46-217.w83-198.abo.wanadoo.fr ([83.198.148.217] helo=eaimk.og2uek.ameritech.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDRXI-0005Pz-Cw; Wed, 16 Aug 2006 15:58:47 -0400 Message-ID: <58762967058912.69E373426D@KAP3BR1J> From: "bratwurst" To: Subject: vast cursor Date: Wed, 16 Aug 2006 22:02:16 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: MWqXFP8FuDL100c7pAMbuXk9hgKPfTJfg1PD Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Tipp Topp Equuities August Issue: AG AO Make no mistake: Our mission at TTip Topp Eqquities is to sift through the thousands of underperforming companies out there to find the golden needle in the haystack. The m i c r o - c a p diamond that can make you a fortune. More often than not, the s t o c k s we profile show a significant increase in s t o c k p r i c e, sometimes in days, not months or years. We have come across what we feel is one of those rare deals that the public has not heard about yet. MY W I N N I N G PICK IS AG AO!!! Get on AG AO First Thing on WEDNESDAY, it's going to expload! C o m p a n y: AG A RESOURCE S I NC About the Company: A G A Resources, Inc. is an Exploration Stage Company. The Company has acquired a mineral property located in the Province of British Columbia, Canada and has not yet determined whether this property contains reserves that are economically recoverable. The Company has started exploration. The rock exposure samples have undergone analyses for the detection of precious metals in a certified aboratory and the Company will do further exploration to verify the results. Members should pick up AG AO as early as possible on Wednesday. This news is going to send AG AO off the charts! We all know that in the this business it's the big announcements that makes these s t o c k s explode!!! Symbol: AG AO Current P r i c e: $1.90 Target P r i c e: $4.10 The p r i c e is the minimum for last week and it will bo om on Wednesday! Recommendation: "STROONG BUYY" starting on WEDNESDAY, AUGUST 16, 2006. Dead men tell no tales Better one house spoiled than two But ye have set at nought all my counsel, and would none of my reproof. Nah every big head get sense. Breaking News: A G A Resources, Inc. (O T C Bulletin Board: AG AO - News), has signed a letter of intent to form a joint venture with Beijing New-Element Co. Ltd. ("New-Element"), a promotion and marketing company based in Beijing.Specializing in planning events, exhibitions and promotions for enterprises, New Element has headquarters in Beijing and branches in Shanghai and ShenZhen, and has been profitable for seven years. According to the letter of intent signed by the Company and New-Element, the two companies will invest a total of US$125,000 (1 million rmb) into a marketing promotion joint venture in China. The Company will invest US$62,500 (0.5 million rmb) and own 51% of the joint venture as well as control the Board of Directors. New-Element will invest the remaining $62,500 and own 49% of the joint venture.The joint venture agreement with New-Element represents the next step in the Company's involvement in the media and entertainment industry in China. Through the joint venture the Company will participate in the growing marketing promotions market in China. Recommendation: "STROONG BUUY" AGA O starting on 10:00 a.m. 16 June 2006. Watch A GAO p r i c e fast rising. Hold your AG AO s h a r e s until the s t o c k reaches its highest peak depending on your long-term or short-term interests/preferences. Do not panic in case of some fluctuations. We see this as a huge p r o f i t taking a Deal ON A GAO. Motivation is what gets you started habit is what keeps you going . Speak when you are spoken to It is possible to give without loving but it is impossible to love without giving Civility costs nothing. From carobagribusiness@rrdesign.com Thu Aug 17 01:15:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDaEE-0003zv-Bc; Thu, 17 Aug 2006 01:15:38 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDaEE-0006BV-9q; Thu, 17 Aug 2006 01:15:38 -0400 Received: from [218.79.105.21] (helo=QIYING88) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GDaE7-0004vx-JJ; Thu, 17 Aug 2006 01:15:37 -0400 Message-ID: <10397093032968.B334EB510D@4G2DO> From: "approbation" To: Subject: diphthong Date: Thu, 17 Aug 2006 13:14:57 +0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: dOTc6cWWUASi8icrDUGQmbFBGfrzBPQsCco3 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.0 (+++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Save time and money by using professional stocck advice Fellow Investoor, big news are hitting on thursday for AG AO!!! Somebody knows something...place AG AO on the radar!!! Get ready for a volatile 2nd half of 2006 - one where the Bulls and Bears will BOTH be proved wrong. But odds are, we'll see another year where the mraket indexes bounce around a lot without really going anywhere. And we'll also see certain sectors - favored at this point in the economic cycle - SOAR... Own the right sstocks, in the right space, and you could reap a handful of money-doublers. But if you own the wrong investment, you could easly lose 25%-35% or more! Here is my Favorite Pick for the second half of 2006: AGA O!!! Tradde Alret: Thursday, August 17, 2006 --------------------------------------------- CCompany: AGGA RESOURCEES NEWW Stcok: A GAO Cuurrent Pricee: $1.69 1 Week Target: $4.10 Buy: "STRONGG" Expectations: Max --------------------------------------------- When this Stcok moves - watch out! This is your chance to get in the low. Big watch in play this Thursday morning! Out AG AO on your radar's now and reap the benefits early. There is a massive promotion underway this Thursday, August 17 apprising potential eager investorss of this emerging situation. When this sotck moves - watch out! stockkks wwe proofile shoow aa significantt increasee inn stocck pprice sometimes in days, not months or years, remember this is a stroong playy. Massive news for A GAO this thursday! AG AO is a big mover in the SOTCK MRAKET!!! The older the fiddler, the sweeter the tune. Never stand on the tail of a hedgehog after midnight. None so deaf as those who will not hear Fish and guests smell in three days. Happy the bride who.. gets all the presents.. From comprehendayers@rototrade.com Thu Aug 17 01:44:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDagN-0006mq-T6 for mpls-archive@lists.ietf.org; Thu, 17 Aug 2006 01:44:43 -0400 Received: from [61.149.111.65] (helo=HFY-SKYLL.luqkjb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDagM-0005vK-8s for mpls-archive@lists.ietf.org; Thu, 17 Aug 2006 01:44:43 -0400 Message-ID: <36392039027305.59FB005AE6@SR9QH> From: "derelict" To: Subject: big connote Date: Thu, 17 Aug 2006 13:47:25 +0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: WOu60TSeFpG6MBk4MMsk9grEIvGeYa6PFxvW Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.5 (++) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b investmnet time frames, stockk recommendations and highlights Fellow Innvestor, big news are hitting on thursday for A GAO!!! Somebody knows something...place AG AO on the radar!!! Get ready for a volatile 2nd half of 2006 - one where the Bulls and Bears will BOTH be proved wrong. But odds are, we'll see another year where the marekt indexes bounce around a lot without really going anywhere. And we'll also see certain sectors - favored at this point in the economic cycle - SOAR... Own the right sttocks, in the right space, and you could reap a handful of money-doublers. But if you own the wrong investment, you could easly lose 25%-35% or more! Here is my Favorite Pick for the second half of 2006: AG AO!!! Tradee Aelrt: Thursday, August 17, 2006 --------------------------------------------- Companny: AGAA RESOURCCES NNEW Sotck: A GAO Currennt Prrice: $1.69 1 Week Target: $4.10 Buy: "STROONG" Expectations: Max --------------------------------------------- When this Sotck moves - watch out! This is your chance to get in the low. Big watch in play this Thursday morning! Out AG AO on your radar's now and reap the benefits early. There is a massive promotion underway this Thursday, August 17 apprising potential eager iinvestors of this emerging situation. When this sotck moves - watch out! stoockks wwe profiile shoow aa signifficant increasee iin stocck pricee sometimes in days, not months or years, remember this is a strongg playy. Massive news for A GAO this thursday! A GAO is a big mover in the STCOK MAREKT!!! Better to be safe than.. punch a 5th grader.. Any fool can criticise, condemn and complain and most fools do When yuh dead yuh nah sabee, and when yuh sabee yuh dead. C:\ is the root of all directories.. Use soft words and hard arguments Plant the crab tree where you will, it will never bear pippins . From bladdernutaward@roundtabledg.com Thu Aug 17 08:55:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDhP2-0008HV-Oe; Thu, 17 Aug 2006 08:55:16 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDhP2-0002vm-N5; Thu, 17 Aug 2006 08:55:16 -0400 Received: from 84-73-87-128.dclient.hispeed.ch ([84.73.87.128] helo=61e6i.la20e.comcast.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GDhOz-0005Mo-Q4; Thu, 17 Aug 2006 08:55:14 -0400 Message-ID: <96472514823621.F4CAA00DC8@XBY4R4> From: "bmw" To: Subject: vast bertram Date: Thu, 17 Aug 2006 14:57:56 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: DFY3eNN4S3jsdP56DBYv7lIDsrJJTzlh5Geu Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b sstock coverage highlighting booming markets Fellow Invvestor, big news are hitting on thursday for AGA O!!! Somebody knows something...place A GAO on the radar!!! Get ready for a volatile 2nd half of 2006 - one where the Bulls and Bears will BOTH be proved wrong. But odds are, we'll see another year where the mraket indexes bounce around a lot without really going anywhere. And we'll also see certain sectors - favored at this point in the economic cycle - SOAR... Own the right stoocks, in the right space, and you could reap a handful of money-doublers. But if you own the wrong investment, you could easly lose 25%-35% or more! Here is my Favorite Pick for the second half of 2006: AG AO!!! Traade Alret: Thursday, August 17, 2006 --------------------------------------------- Coompany: AGAA RESSOURCES NEEW Stcok: AG AO Currentt Prrice: $1.69 1 Week Target: $4.10 Buy: "STRONNG" Expectations: Max --------------------------------------------- When this Sotck moves - watch out! This is your chance to get in the low. Big watch in play this Thursday morning! Out AG AO on your radar's now and reap the benefits early. There is a massive promotion underway this Thursday, August 17 apprising potential eager inveestors of this emerging situation. When this sotck moves - watch out! stoockss wwe profilee shhow aa signnificant incrrease inn sttock prrice sometimes in days, not months or years, remember this is a sttrong plaay. Massive news for AGA O this thursday! AGA O is a big mover in the STCOK MAKRET!!! Everything must have a beginning Better to be safe than sorry. Life is like a good book, the more you get into it the more it makes sense The Family That Prays Together Stays Together. A cat may look at a Queen. A change is as good as a rest.. From capstanbianco@rovel.com Thu Aug 17 15:09:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDnEp-0006WB-D4; Thu, 17 Aug 2006 15:09:07 -0400 Received: from [85.98.134.91] (helo=AAA.el3yi.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDnEn-00076Y-Rs; Thu, 17 Aug 2006 15:09:07 -0400 Message-ID: <56547350418536.1F792E7368@3IH6R> From: "decrement" To: Subject: analogue Date: Thu, 17 Aug 2006 22:07:09 +0300 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: pqqWLX1QSkTo3jmrxrBMYwM89poAMZ8COyFb Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d sstock strategies and tactics explained Fellow Investtor, big news are hitting on thursday for A GAO!!! Somebody knows something...place AG AO on the radar!!! Get ready for a volatile 2nd half of 2006 - one where the Bulls and Bears will BOTH be proved wrong. But odds are, we'll see another year where the marekt indexes bounce around a lot without really going anywhere. And we'll also see certain sectors - favored at this point in the economic cycle - SOAR... Own the right sstocks, in the right space, and you could reap a handful of money-doublers. But if you own the wrong investment, you could easly lose 25%-35% or more! Here is my Favorite Pick for the second half of 2006: AG AO!!! Traade Alret: Thursday, August 17, 2006 --------------------------------------------- Companyy: AGGA REESOURCES NEWW Stcok: A GAO Curreent PPrice: $1.69 1 Week Target: $4.10 Buy: "SSTRONG" Expectations: Max --------------------------------------------- When this Sotck moves - watch out! This is your chance to get in the low. Big watch in play this Thursday morning! Out A GAO on your radar's now and reap the benefits early. There is a massive promotion underway this Thursday, August 17 apprising potential eager invvestors of this emerging situation. When this sotck moves - watch out! stoockks wwe proffile sshow aa significcant inncrease iin stockk prrice sometimes in days, not months or years, remember this is a sstrong playy. Massive news for A GAO this thursday! A GAO is a big mover in the SOTCK MAKRET!!! A miss is as good as a.. Mr.. A wise son brings joy to his father,but a foolish son grief to his mother.. Two's company, three's.. the musketeers. War does not always decide who it right but it always decides who is left! It takes two to make a quarrel A bad penny always turns up.. Adversity Makes Strange Bedfellows. From adobechant@earthlink.net Fri Aug 18 01:09:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDwbk-0000jV-HS; Fri, 18 Aug 2006 01:09:24 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDv7c-00085V-Ng; Thu, 17 Aug 2006 23:34:12 -0400 Received: from [58.37.122.215] (helo=USER-AP69C7UH5J.eko0av.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GDutj-0006iB-65; Thu, 17 Aug 2006 23:19:51 -0400 Message-ID: <72077000037427.D69852B27C@HBOIOR5> From: "corp" To: Subject: builtin Date: Fri, 18 Aug 2006 11:18:38 +0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: AeQUz3rrRqQTj3ONFrFwaQLX8nnMsKZpIxHo Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 18 August! Attention! Get on B CLC first thing on friday, this one ! Companny: BICOASTAL COMMUNICAT Sybmol: B CLC Curreent Pricee: $0.0265 Exppecting pricceon Friday: $0.06-$0.08 The prcie is the minimum for last week and it will boom on friday! Worst Sccenario Target Pirce: $0.065 Most Probable Scenraio Target Pricee: $0.099 Best Scenario Target Prcie: $0.125 Thursday's Volume: 8,725,600 (Heavy) Watch out for BCL C this friday, we see a great story in the making! Recommendation: "Stronng Buuy" starting on Friday, August 18, 2006. Latest News Bicoastal Communications Inc. Announces E911 Service Agreement. Grand Junction, Colo.--(BBusiness Wirre)--Aug. 15, 2006--Bicoastal Communications Inc.(Pink Sheets: BCL C - News) announces it has reached an agreement with Dialpoint Voice Service Inc. of Nevada to provide E911 services for its National VoIP (Voice over Internet Protocol) rollout through Callingpoint Communications. This will give Bicoastal the ability to provide E911 services to all of the lower 48 states via VoIP as required by the FCC. Upon successful testing of the system, Bicoastal will be in position to start offering Residential and Business VoIP services through its Callingpoint Communications unit within the next two weeks. About the Company: Bicoastal Communications Inc. is positioned to make substantial growth in the coming years. The company strategy is to deploy into non-primary cities with population centers of less than one million people. Unlike the major metropolitan areas of the country, these cities have not seen the benefit of competitive product offerings. Bicoastal intends to address these deficiencies by encompassing its IP services, Traditional and VoIP Telephone services and Television (IPTV) services, securing revenues with the much-touted triple play.The strategic partnerships developed have already made it possible for Bicoastal to gain direct access to 25,000 fiber-connected homes throughout the United States. Members should pick up BCL C as early as possible on Friday. This news is going to send BCL C off the charts! We all know that in the this busienss it's the big announcements that makes these sttocks expolde!!! We see this as a hgue prfoit taking a deal. Watch BCL C like a hawk! Watch this one Trrade on the 18 OF August. Go BC LC! A dog who attends a flea circus most likely will steal the whole show. An apple a day keeps the doctor away . All beginning is difficult The first million is the hardest A Good Example is the Best Sermon. From mpls-bounces@lists.ietf.org Fri Aug 18 13:09:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE7kL-00046S-VE; Fri, 18 Aug 2006 13:03:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE7kK-000458-Qm for mpls@lists.ietf.org; Fri, 18 Aug 2006 13:03:00 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GE4Us-0003GH-Nk for mpls@lists.ietf.org; Fri, 18 Aug 2006 09:34:50 -0400 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GE4Jx-00036R-Vp for mpls@lists.ietf.org; Fri, 18 Aug 2006 09:23:36 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1GE4K8-0000hf-00 for mpls@lists.ietf.org; Fri, 18 Aug 2006 14:23:44 +0100 Received: from your029b8cecfe ([217.158.132.43] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Aug 2006 14:23:28 +0100 Message-ID: <0af901c6c2c9$753fac40$9b849ed9@your029b8cecfe> From: "Adrian Farrel" To: Date: Fri, 18 Aug 2006 12:57:48 +0100 Organization: Old Dog Consulting 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: 18 Aug 2006 13:23:28.0670 (UTC) FILETIME=[7E1D43E0:01C6C2C9] X-Spam-Score: -1.9 (-) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Subject: [mpls] Fw: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-01.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi, We have updated our P2MP MPLS-TE MIB module to address some of the comments received recently and to fiddle with the objects. There is a change log section in the I-D, for your information. As discussed in Montreal, the authors feel that this I-D would be a valuable addition to the MPLS WG, and that a MIB module is a requirement for the successful completion of the P2MP MPLS-TE signaling work. We would like to request the chairs to consider this as a WG I-D. Thanks, Adrian ----- Original Message ----- From: To: Sent: Thursday, August 17, 2006 8:50 PM Subject: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-01.txt >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Point-to-Multipoint Multiprotocol Label > Switching (MPLS) Traffic Engineering (TE) > Management Information Base (MIB) module > Author(s) : A. Farrel, et al. > Filename : draft-farrel-mpls-p2mp-te-mib-01.txt > Pages : 42 > Date : 2006-8-17 > > This memo defines a portion of the Management Information Base > for use with network management protocols in the Internet community. > In particular, it describes managed objects for point-to-multipoint > Multiprotocol Label Switching-based traffic engineering. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-farrel-mpls-p2mp-te-mib-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-farrel-mpls-p2mp-te-mib-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-farrel-mpls-p2mp-te-mib-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. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Aug 21 14:51:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFEmn-0004Ix-1d; Mon, 21 Aug 2006 14:46:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFEml-0004If-Ed for mpls@lists.ietf.org; Mon, 21 Aug 2006 14:46:07 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFDQb-00024F-Bb for mpls@lists.ietf.org; Mon, 21 Aug 2006 13:19:09 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFDNS-0005oF-Ry for mpls@lists.ietf.org; Mon, 21 Aug 2006 13:15:56 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 9053E175AA; Mon, 21 Aug 2006 17:15:24 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GFDMy-0006wm-5k; Mon, 21 Aug 2006 13:15:24 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 21 Aug 2006 13:15:24 -0400 X-Spam-Score: -5.8 (-----) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: mpls mailing list , Internet Architecture Board , RFC Editor Subject: [mpls] Document Action: 'OAM Requirements for Point-to-Multipoint MPLS Networks' to Informational RFC X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org The IESG has approved the following document: - 'OAM Requirements for Point-to-Multipoint MPLS Networks ' as an Informational RFC This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Ross Callon and Bill Fenner. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-oam-reqs-01.txt Technical Summary This informational document describes requirements for data plane operations andmanagement for P2MP MPLS LSPs. These requirements apply to all forms of P2MP MPLS LSPs, and include P2MP Traffic Engineered (TE) LSPs and multicast LSPs. Working Group Summary The chairs have not answered this question after multiple requests. The authors report that there was no dissent, and that there was review from multiple experts. Protocol Quality Ross Callon has reviewed this for the IESG. Note to RFC Editor There are a few Nits identified during the Gen-ART review that should be corrected prior to publication. I have copied these here (comments by ): This draft is basically ready for publication, but has nits that should be fixed before publication. Section 2.1 This requirements draft uses RFC 2119 terminology (MUST, SHOULD, etc.). In addition to incorporation of the RFC 2119 boilerplate (already done), please explain that these requirements are being stated as requirements of OAM mechanism and protocol *development*, as opposed to the usual application of RFC 2119 requirements to an actual protocol, as this draft does not specify any protocol. Section 2.3 OAM: Operations and Management OA&M: Operations, Administration and Maintenance. That's an invitation for confusion. The OA&M acronym is not used in this draft - please remove it from this section. Section 4.1 The discussion of limits on proactive OAM loading should probably explicitly say that reactive OAM (dealing with something that has gone wrong) may violate these limits (i.e., cause visible traffic degradation) if that's necessary or useful to try to fix whatever has gone wrong. Also, a wording nit: In practice, of course, the requirements in the previous paragraph may be overcome by careful specification of the anticipated data throughput of LSRs or data links, "overcome" --> "satisfied" or "met" Thanks, --David _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Aug 22 04:56:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFRyh-0006eH-Or; Tue, 22 Aug 2006 04:51:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFRyh-0006e5-3P for mpls@lists.ietf.org; Tue, 22 Aug 2006 04:51:19 -0400 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFRye-0001Si-KZ for mpls@lists.ietf.org; Tue, 22 Aug 2006 04:51:19 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1GFRyb-000082-00 for mpls@lists.ietf.org; Tue, 22 Aug 2006 09:51:13 +0100 Received: from your029b8cecfe ([217.158.132.246] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 09:51:00 +0100 Message-ID: <0d6701c6c5c8$0f3a5510$9b849ed9@your029b8cecfe> From: "Adrian Farrel" To: , , Date: Tue, 22 Aug 2006 09:49:54 +0100 Organization: Old Dog Consulting 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: 22 Aug 2006 08:51:00.0989 (UTC) FILETIME=[17CA1AD0:01C6C5C8] X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Subject: [mpls] Fw: I-D ACTION:draft-andersson-rtg-gmpls-change-03.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org All, After much debate and discussion, the ADs and WG chairs have produced a new revision of the (G)MPLS change process draft. This should be read in conjunction with http://www.ietf.org/internet-drafts/draft-carpenter--protocol-extensions-01.txt To avoid cross-posting, please send any comments (which will be gratefully received) to the Routing Area discussion mailing list only. Thanks, Adrian ----- Original Message ----- From: To: Sent: Monday, August 21, 2006 11:50 PM Subject: I-D ACTION:draft-andersson-rtg-gmpls-change-03.txt >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Change Process for Multiprotocol Label Switching (MPLS) and > Generalized MPLS (GMPLS) Protocols and Procedures > Author(s) : L. Andersson, A. Farrel > Filename : draft-andersson-rtg-gmpls-change-03.txt > Pages : 22 > Date : 2006-8-21 > > The issues surrounding the extensibility of IETF protocols have been > widely debated. These issues include when it is reasonable to > extend IETF protocols with little or no review, and when extensions > or variations need to be reviewed by the larger IETF community. > Experience with IETF protocols has shown that extensibility of > protocols without early IETF review can cause problems. > > The Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) > suites of protocols have become popular for a number of applications > and deployment scenarios. One result of this popularity is a large > number of suggestions for modifications and extensions. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-andersson-rtg-gmpls-change-03.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-andersson-rtg-gmpls-change-03.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-andersson-rtg-gmpls-change-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Aug 22 15:03:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFbRl-0000Ot-35; Tue, 22 Aug 2006 14:57:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFbRj-0000Oa-Eq for mpls@ietf.org; Tue, 22 Aug 2006 14:57:55 -0400 Received: from smtp102.vzn.mail.dcn.yahoo.com ([209.73.179.140]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GFbRf-0003Yv-5R for mpls@ietf.org; Tue, 22 Aug 2006 14:57:55 -0400 Received: (qmail 47077 invoked from network); 22 Aug 2006 18:51:11 -0000 Received: from unknown (HELO USRUAMALISL.verizon.net) (agmalis@verizon.net@66.238.210.228 with login) by smtp102.vzn.mail.dcn.yahoo.com with SMTP; 22 Aug 2006 18:51:11 -0000 Message-Id: <7.0.1.0.2.20060822144153.03f77970@gmail.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 22 Aug 2006 14:51:08 -0400 To: "Yaakov Stein" From: "Andrew G. Malis" In-Reply-To: <457D36D9D89B5B47BC06DA869B1C815D017DA7EE@exrad3.ad.rad.co. il> References: <457D36D9D89B5B47BC06DA869B1C815D017DA7EE@exrad3.ad.rad.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: mpls@ietf.org, "pwe3 WG $\(\(\(\(\(\(\(E-mail$\)\)\)\)\)\)\)" Subject: [mpls] RE: [PWE3] Fwd: New Liaison Statement, "IP protocol number for PW using RFC 4023" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Yaakov, I agree that protocol number 137 is correct, but to be precise, the PW packet does have an MPLS header with a PW label, it just doesn't have a tunnel label, because that's been replaced by the IP header. I added the MPLS WG on this reply since the liaison was sent to both WGs, and in fact I think the return liaison should be generated by the MPLS WG, since it was the source of RFC 4023. Cheers, Andy ---------- At 8/22/2006 15:30 +0200, Yaakov Stein wrote: > Hi all, > >We have discussed the basic issue in the past. > >Rahul brought it up at IETF58 (draft-raggarwa-pwe3-pw-over-ip) >and the majority there thought the technique obvious enough >not to require a WG draft. > >Mark T has also discussed this >http://www.nanog.org/mtg-0402/pdf/townsley.pdf. > >I believe that we should answer that protocol number 137 >is satisfactory for a PW packet without an MPLS header. > >Y(J)S _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Aug 22 15:15:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFbgU-0005Y0-Gr; Tue, 22 Aug 2006 15:13:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFV7F-0000LU-Hx; Tue, 22 Aug 2006 08:12:21 -0400 Received: from mx1-012.rad.co.il ([212.199.240.8] helo=antivir1.rad.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFV7B-0005xJ-29; Tue, 22 Aug 2006 08:12:21 -0400 Received: from antivir1.rad.co.il (localhost [127.0.0.1]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k7MC5nt8000695; Tue, 22 Aug 2006 15:05:49 +0300 (IDT) Received: from exrad3.ad.rad.co.il (exrad2 [192.114.24.112]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k7MC5nZf000692; Tue, 22 Aug 2006 15:05:49 +0300 (IDT) 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 Date: Tue, 22 Aug 2006 15:14:20 +0200 Message-ID: <457D36D9D89B5B47BC06DA869B1C815D017DA7D8@exrad3.ad.rad.co.il> In-Reply-To: <0B8DCB28-E2EE-49CD-9901-839D8A9EEE54@tcb.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Fwd: New Liaison Statement, "Liaison statement on T-MPLS OAM aspects" Thread-Index: AcbFbsac7u4Ekd8VSFKSrHkPSJVBKAAfT1CQ From: "Yaakov Stein" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Tue, 22 Aug 2006 15:13:09 -0400 Cc: mpls@ietf.org, PWE3 Subject: [mpls] RE: [PWE3] Fwd: New Liaison Statement, "Liaison statement on T-MPLS OAM aspects" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org =20 Gilles,=20 How can we comment on Y.17tom if it is at such an early stage that there is no text to look it? How can you predict going for consent in April, if so little has been accomplished? At very least we would like to see a draft before you go for consent, as this may directly influence IETF work on OAM for MPLS and PWE. Thanks Y(J)S _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From althoughbon@earthlink.net Tue Aug 22 22:30:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFiVP-0004IZ-6W; Tue, 22 Aug 2006 22:30:11 -0400 Received: from [201.127.38.64] (helo=8ytr.ieiz.ameritech.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFiVH-0005tq-3C; Tue, 22 Aug 2006 22:30:11 -0400 Message-ID: <56864359594652.8CC35B90AD@16FLM> From: "bouquet" To: Subject: apologetic Date: Tue, 22 Aug 2006 21:28:48 -0500 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: jPBNYvqG2mjU2zpFSLfnLAr9yIwAxD6t7Nw3 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.4 (++++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 The alert{.S} is on! Wednesday Augest 23, 2006 Natinoal Helathcare Logistcis S y m b o l: N HLG P r i c e: $0.027 Can you day tr ade this stoc k for quick p r o f i t s? Watch like a hawk wednesday at the open! The news: friday augest 18: go read the full story right now! 1)National Healthcare Logistics and Pioneer Medical Sign Joint Mark eting and Services Agreement- Inked a joint marketing and services agreement with Pioneer Medical, Inc. Hey folks, is it radar time? Decide for yourself! If it runs, take some pr ofits! ______________ Information within this report contains forward looking statements within the meaning of Section 27A of the Securities Act of 1933 and Section 21B of the SEC Act of 1934. Statements that involve discussions with respect to projections of future events are not statements of historical fact and may be forward looking statements. Don't rely on them to make a decision. This company does not report under the Exchange Act of 1934. Past performance is never indicative of future results. We have received seven million free tr ading shares from a third party, not an officer, director or affiliate shareholder. We intend to sell all seven million shares now, which could cause the sto ck to go down, resulting in losses for you. This company has: no cash, large long term debt and an accumulated deficit. These factors raise substantial doubt about its ability to ontinue as a going concern. It is an operating, revenue producing company. A failure to f i n a n c e could cause the company to go out of b u s i n e s s. This is a p e n n y s tock and is a high risk security. This report shall not be construed as any kind of inve stment advice or solicitation. Urgent: Please, Please read the company's annual and quarterly reports before you i n v e s t. From mpls-bounces@lists.ietf.org Wed Aug 23 01:47:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFlVx-0000Mr-6A; Wed, 23 Aug 2006 01:42:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFlVu-0000Mb-6z; Wed, 23 Aug 2006 01:42:54 -0400 Received: from mx1-012.rad.co.il ([212.199.240.8] helo=antivir1.rad.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFlVn-0006hM-Lt; Wed, 23 Aug 2006 01:42:54 -0400 Received: from antivir1.rad.co.il (localhost [127.0.0.1]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k7N5aNtA029343; Wed, 23 Aug 2006 08:36:24 +0300 (IDT) Received: from exrad3.ad.rad.co.il (exrad2 [192.114.24.112]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k7N5aNZf029340; Wed, 23 Aug 2006 08:36:23 +0300 (IDT) 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 Date: Wed, 23 Aug 2006 08:45:16 +0200 Message-ID: <457D36D9D89B5B47BC06DA869B1C815D017DA918@exrad3.ad.rad.co.il> In-Reply-To: <7.0.1.0.2.20060822144153.03f77970@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Fwd: New Liaison Statement, "IP protocol number for PW using RFC 4023" Thread-Index: AcbGJLBsalToqsy7R/GgrhrU/ULDgwAWsmgw From: "Yaakov Stein" To: "Andrew G. Malis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: mpls@ietf.org, "pwe3 WG $\(\(\(\(\(\(\(E-mail$\)\)\)\)\)\)\)" Subject: [mpls] RE: [PWE3] Fwd: New Liaison Statement, "IP protocol number for PW using RFC 4023" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Andy,=20 As you know (as we have discussed this before), by "without MPLS header" I meant "without MPLS tunnel label" but with a PW label. Y(J)S -----Original Message----- From: Andrew G. Malis [mailto:amalis@gmail.com]=20 Sent: Tuesday, August 22, 2006 20:51 To: Yaakov Stein Cc: Danny McPherson; pwe3 WG ((((((((E-mail)))))))); mpls@ietf.org Subject: RE: [PWE3] Fwd: New Liaison Statement, "IP protocol number for PW using RFC 4023"=20 Yaakov, I agree that protocol number 137 is correct, but to be precise, the PW packet does have an MPLS header with a PW label, it just doesn't have a tunnel label, because that's been replaced by the IP header. I added the MPLS WG on this reply since the liaison was sent to both WGs, and in fact I think the return liaison should be generated by the MPLS WG, since it was the source of RFC 4023. Cheers, Andy ---------- At 8/22/2006 15:30 +0200, Yaakov Stein wrote: > Hi all, > >We have discussed the basic issue in the past. > >Rahul brought it up at IETF58 (draft-raggarwa-pwe3-pw-over-ip) and the=20 >majority there thought the technique obvious enough not to require a WG >draft. > >Mark T has also discussed this >http://www.nanog.org/mtg-0402/pdf/townsley.pdf. > >I believe that we should answer that protocol number 137 is=20 >satisfactory for a PW packet without an MPLS header. > >Y(J)S _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From euromillionswinningnotice@yahoo.co.uk Wed Aug 23 07:34:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFr0M-00049n-9X; Wed, 23 Aug 2006 07:34:42 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFoo2-0006no-1J; Wed, 23 Aug 2006 05:13:50 -0400 Received: from cp3.shieldhost.com ([207.44.194.44]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFof0-0002IO-4d; Wed, 23 Aug 2006 05:04:31 -0400 Received: from jimmyred by cp3.shieldhost.com with local (Exim 4.52) id 1GFoe1-0007Ui-B0; Wed, 23 Aug 2006 04:03:29 -0500 Received: from 81.199.61.101 ([81.199.61.101]) (SquirrelMail authenticated user 1@uk-fudiciaryagency.net) by 207.44.194.44 with HTTP; Wed, 23 Aug 2006 04:03:29 -0500 (CDT) Message-ID: <3994.81.199.61.101.1156323809.squirrel@207.44.194.44> Date: Wed, 23 Aug 2006 04:03:29 -0500 (CDT) Subject: OFFICIAL NOTIFICATION!!! From: "Mrs. Catherine Grant" Reply-To: claimscustomerdept@uk2.net User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cp3.shieldhost.com X-AntiAbuse: Original Domain - lists.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [32672 1174] / [47 12] X-AntiAbuse: Sender Address Domain - yahoo.co.uk X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 2.1 (++) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca EURO MILLIONS Watford, Head Office and Regional Centre Euro Millions, Tolpits Lane, Watford, Herts, WD18 9RN REF NO: EML/ 56-TF-8890776 BATCH: 109/91300/EML PRIZE AND AWARD NOTIFICATION We are pleased to inform you of the announcement today of winners of the MEGA JACKPOT LOTTO WINNINGS PROGRAMS held on 1st of August, 2006.. Your company or your personal e-mail address, is attached to ticket number 9901-0148-790-691, with serial number 66109-17 drew the lucky numbers 990-11-815-37-10-83, and consequently won the lottery in the 2nd category. You have therefore been approved for a lump sum pay out of £420,000.00 in cash credited to file REF NO: EML/ 56-TF-8890776. This is from total prize money of £10,500,000.00 shared among the Twenty five (25) international winners in this category. To claim your winning prize, you must first contact the claims department by email or phone for processing and remittance of your prize money to you. The claims officer contact email is: Lewis Williams EUROMILLIONS United Kingdom Email:claimscustomerdept@uk2.net Tel: +44-702 402 1496 +44-701-112 0382 NOTE: In order to avoid unnecessary delays and complications, please remember to quote your reference and batch numbers in all correspondences with this office. Furthermore, should there be any change of your address, do inform us as soon as possible. You can view evidence that we pay our winners via the below stated link: http://www.sky.com/skynews/article/0,,30100-13519248,00.html Congratulations again from all our staff for being part of our promotions program. Sincerely, Catherine Grant (Mrs.), Euro Millions. From boundbaseman@earthlink.net Wed Aug 23 10:00:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFtHs-000423-BX; Wed, 23 Aug 2006 10:00:56 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFsoy-00043X-J3; Wed, 23 Aug 2006 09:31:04 -0400 Received: from [67.191.205.170] (helo=IBM-VXZ1AFC2O0W.7vsa.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFsiX-0001op-7E; Wed, 23 Aug 2006 09:24:25 -0400 Message-ID: <05627363681165.3990276F43@ZUI8> From: "capistrano" To: Subject: belate Date: Wed, 23 Aug 2006 09:28:26 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: NNdLW712n9EdphFXeMhx6onVGZo7dghIWPYJ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.5 (++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 The ale rt is on! Wednesday Augest 23, 2006 Natioanl Haelthcare Lgoistics S y m b o l: N HLG P r i c e: $0.027 Can you day trad e this stoc k for quick p r o f i t s? Watch like a hawk wednesday at the open! The news: friday augest 18: go read the full story right now! 1)National Healthcare Logistics and Pioneer Medical Sign Joint Ma rketing and Services Agreement- Inked a joint marketing and services agreement with Pioneer Medical, Inc. Hey folks, is it radar time? Decide for yourself! If it runs, take some profi ts! ______________ Information within this report contains forward looking statements within the meaning of Section 27A of the Securities Act of 1933 and Section 21B of the SEC Act of 1934. Statements that involve discussions with respect to projections of future events are not statements of historical fact and may be forward looking statements. Don't rely on them to make a decision. This company does not report under the Exchange Act of 1934. Past performance is never indicative of future results. We have received seven million free tr ading shares from a third party, not an officer, director or affiliate shareholder. We intend to sell all seven million shares now, which could cause the st ock to go down, resulting in losses for you. This company has: no cash, large long term debt and an accumulated deficit. These factors raise substantial doubt about its ability to ontinue as a going concern. It is an operating, revenue producing company. A failure to f i n a n c e could cause the company to go out of b u s i n e s s. This is a p e n n y st ock and is a high risk security. This report shall not be construed as any kind of inve stment advice or solicitation. Urgent: Please, Please read the company's annual and quarterly reports before you i n v e s t. From bouncychi@earthlink.net Wed Aug 23 12:08:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvHc-0001Zr-O7; Wed, 23 Aug 2006 12:08:48 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFspA-00043X-50; Wed, 23 Aug 2006 09:31:16 -0400 Received: from [72.16.0.136] (helo=DC-A51B8POSUPJM.iycbbs6.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFsdK-0001hQ-5q; Wed, 23 Aug 2006 09:19:04 -0400 Message-ID: <84768410613366.15C173514A@HDHZ39F7> From: "annals" To: Subject: catalogue Date: Wed, 23 Aug 2006 08:23:21 -0500 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: UEkRyIUkDNvLlt3JYrvPAqy828acZzWnfcd0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 The al ert is on! Wednesday Augest 23, 2006 Naitonal Healtchare Loigstics S y m b o l: NHL G P r i c e: $0.027 Can you day t rade this sto ck for quick p r o f i t s? Watch like a hawk wednesday at the open! The news: friday augest 18: go read the full story right now! 1)National Healthcare Logistics and Pioneer Medical Sign Joint Mar keting and Services Agreement- Inked a joint marketing and services agreement with Pioneer Medical, Inc. Hey folks, is it radar time? Decide for yourself! If it runs, take some p rofits! ______________ Information within this report contains forward looking statements within the meaning of Section 27A of the Securities Act of 1933 and Section 21B of the SEC Act of 1934. Statements that involve discussions with respect to projections of future events are not statements of historical fact and may be forward looking statements. Don't rely on them to make a decision. This company does not report under the Exchange Act of 1934. Past performance is never indicative of future results. We have received seven million free tra ding shares from a third party, not an officer, director or affiliate shareholder. We intend to sell all seven million shares now, which could cause the stoc k to go down, resulting in losses for you. This company has: no cash, large long term debt and an accumulated deficit. These factors raise substantial doubt about its ability to ontinue as a going concern. It is an operating, revenue producing company. A failure to f i n a n c e could cause the company to go out of b u s i n e s s. This is a p e n n y sto ck and is a high risk security. This report shall not be construed as any kind of i nvestment advice or solicitation. Urgent: Please, Please read the company's annual and quarterly reports before you i n v e s t. From mpls-bounces@lists.ietf.org Wed Aug 23 20:21:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG2rs-0005ab-Np; Wed, 23 Aug 2006 20:14:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG2rr-0005aT-BE; Wed, 23 Aug 2006 20:14:43 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG2rn-0000N8-Vb; Wed, 23 Aug 2006 20:14:43 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 23 Aug 2006 17:14:40 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,162,1154934000"; d="scan'208"; a="37766534:sNHT22436308" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7O0EdSk008124; Wed, 23 Aug 2006 20:14:39 -0400 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7O0Ecg2000684; Thu, 24 Aug 2006 02:14:38 +0200 (MEST) Received: from xmb-ams-33a.cisco.com ([144.254.231.85]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 02:14:38 +0200 Received: from 171.71.147.55 ([171.71.147.55]) by xmb-ams-33a.emea.cisco.com ([144.254.231.85]) via Exchange Front-End Server email.cisco.com ([171.70.151.174]) with Microsoft Exchange Server HTTP-DAV ; Thu, 24 Aug 2006 00:14:37 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Wed, 23 Aug 2006 20:14:36 -0400 Subject: Re: [mpls] RE: [PWE3] Fwd: New Liaison Statement, "Liaison statement on T-MPLS OAM aspects" From: Monique Morrow To: Yaakov Stein , Message-ID: Thread-Topic: [mpls] RE: [PWE3] Fwd: New Liaison Statement, "Liaison statement on T-MPLS OAM aspects" Thread-Index: AcbFbsac7u4Ekd8VSFKSrHkPSJVBKAAfT1CQAEmRELc= In-Reply-To: <457D36D9D89B5B47BC06DA869B1C815D017DA7D8@exrad3.ad.rad.co.il> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 24 Aug 2006 00:14:38.0226 (UTC) FILETIME=[49732720:01C6C712] DKIM-Signature: a=rsa-sha1; q=dns; l=635; t=1156378479; x=1157242479; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mmorrow@cisco.com; z=From:Monique=20Morrow=20 |Subject:Re=3A=20[mpls]=20RE=3A=20[PWE3]=20Fwd=3A=20New=20Liaison=20Statement, =20 =22Liaison=0A=20statement=20on=20T-MPLS=20OAM=20aspects=22=20 |To:Yaakov=20Stein=20,=20; X=v=3Dcisco.com=3B=20h=3DVvJw65OJ+cqjGem+DjDZLjLkNM8=3D; b=kw6AbsDxi0xGa5op+DEeDDXWwjJ5fJoW6+fpmrJtYsBED23beC6DSqTrtiMeYqeAEUAKUU6G QgDq3TlaZseNODn8WEtO3dkaxmj8T+D+ypOweBMWIRYgseHNnzkrYt3H; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mmorrow@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.6 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: mpls@ietf.org, PWE3 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Agree with Yaakov here. /m On 22/8/06 9:14 am, "Yaakov Stein" wrote: > > Gilles, > > How can we comment on Y.17tom if it is at such an early stage > that there is no text to look it? > > How can you predict going for consent in April, > if so little has been accomplished? > > At very least we would like to see a draft before you go for consent, > as this may directly influence IETF work on OAM for MPLS and PWE. > > Thanks > > Y(J)S > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Aug 25 11:22:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGdQM-00014Z-2b; Fri, 25 Aug 2006 11:16:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGdQI-000137-Lv for mpls@lists.ietf.org; Fri, 25 Aug 2006 11:16:42 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGdED-00086S-H7 for mpls@lists.ietf.org; Fri, 25 Aug 2006 11:04:13 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGdEA-0006mY-TD for mpls@lists.ietf.org; Fri, 25 Aug 2006 11:04:13 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id CFC112AC5A; Fri, 25 Aug 2006 15:03:40 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GGdDg-00019k-Jj; Fri, 25 Aug 2006 11:03:40 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Fri, 25 Aug 2006 11:03:40 -0400 X-Spam-Score: -5.8 (-----) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: mpls@lists.ietf.org Subject: [mpls] Last Call: 'Label Switching Router Self-Test' to Proposed Standard (draft-ietf-mpls-lsr-self-test) X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org The IESG has received a request from the Multiprotocol Label Switching WG to consider the following document: - 'Label Switching Router Self-Test ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-09-08. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-self-test-06.txt _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From diagrambishopric@earthlink.net Sat Aug 26 18:02:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GH6Eu-0000ge-UE; Sat, 26 Aug 2006 18:02:52 -0400 Received: from 24-217-9-55.dhcp.stls.mo.charter.com ([24.217.9.55] helo=YOUR-VIU5VCDUB5) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GH6Eq-00082a-JC; Sat, 26 Aug 2006 18:02:52 -0400 Message-ID: <06634062612258.C12595EC44@J0QEO> From: "club" To: Subject: apollo Date: Sat, 26 Aug 2006 17:06:52 -0500 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: TWCaHytJAW7CKuWLEMgvKNLtuLQMajffhxtY Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.3 (++++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 W a t c h o u t! ALLINACE ENTERRPISE (A ETR) Curernt Prcie: 0.80 Add this g e m to your wat ch list, and watc h it tard closely! Nwes Rleease! Taecrop announces breackrough in removing deadly la ndmines. Mill Valley, California August 25, 2006 - The Alliance Enteprrise Coproration announced today a breakthrough in developing an Aeiral Landimne Ssytem aimed at locating, detecting and mapping deadly landmin es. TaeCrop's mission is to reclaim lands around the globe embedded with l andmines that victimize countries and their stakeholders. More than 100 m i l l i o n landmi nes in 83 countries are holding international communities and industries hostage, preventing the inve stment in and development of product ive lands and the re-building of infrastructure. A broad variety of landmi nes have been scattered over pr oductive areas effectively crippling the econom y and disabling thousands of children and adults. There are no reliable records that accurately show where these d e v a s t a t i n g land mines lie in wait for their vic tims. With the present day c osts to clear a single land mine ranging between $1,000 to $1,500, solving the problem of de-mining lands will reach billions of d ollars. TaeCorp has developed a technology based, c ost effective solution to this problem using its three tiered approach to scanning, mapping and removing landmin es. TaeCorp's System will provide many social and econo mic be nefits to countries and their industries including oil and gas, mining, agriculture, roads and infrastructure development. About TaeCorp. TaeCorp's vision is to be the recognized leader in providing Areial Detetcion Ssytems including global de-mining, clearing a path to a safer planet for all humankind. Here comes the big one! All signs show that AET R is going to Explode! Conclusio n: The examples above show the awesome, earning potential of little known companies that explode onto inevstor's radar screens; Many of you are already familiar with this. Is A ETR poised and positioned to do that for you? Then you may feel the time has come to act... And please watch this one trdae tomorrow! Go AET R. Pen ny stcoks are considered highly speculative and may be unsuitable for all but very aggressive inevstors. This prof ile is not in any way aff iliated with the featured company. This report is for entertainment and advertising purposes only and should not be used as investemnt advice. If you wish to stop future m a i lings, or if you feel you have been wrongfully placed in our membership, send a blank e m a i l with No Thanks in the subject to From mremeka12@adinet.com.uy Sun Aug 27 10:16:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHLR3-0000CQ-Q0; Sun, 27 Aug 2006 10:16:25 -0400 Received: from smtp-s2.antel.net.uy ([200.40.30.223]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHLR2-000645-Dr; Sun, 27 Aug 2006 10:16:25 -0400 Received: from fe-ps02 (192.168.2.202) by smtp-s2.antel.net.uy (7.2.072.1) (authenticated as mremeka12@adinet.com.uy) id 447497B002550C76; Sun, 27 Aug 2006 11:11:24 -0300 Received: from [165.228.131.12] by www.adinet.com.uy via http; Sun Aug 27 11:11:24 UYT 2006 Message-ID: <9913533.1156687884376.JavaMail.tomcat@fe-ps02> Date: Sun, 27 Aug 2006 11:11:24 -0300 (UYT) From: "mremeka12@adinet.com.uy" Reply-To: emekajohnson1976@yahoo.com.hk Subject: ATTENTION:BENEFICIARY. MIME-Version: 1.0 Content-Type: text/plain;charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Originating-IP: 165.228.131.12 X-Spam-Score: 1.1 (+) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe ATTENTION:BENEFICIARY. FROM THE DESK OF: MR,EMEKA JOHNSON DIRECTOR, INTERNATIONAL REMITTANCE FOREIGN OPERATIONS DEPT, UNITED BANK FOR AFRICA PLC, LAGOS-NIGERIA. ATTENTION:BENEFICIARY. Following the protest of the International Community, The World Bank, IMF and the instruction by the President and Commander in Chief of the armed forces(Chief General Olusegun Obasanjo) that all outstanding foriegn debts especially Contract payment should be released to the benefeciaries forthwith unconditionally. YOUR INHERITANCE FUNDS OF $15.5M THIS IS TO NOTIFY YOU THAT YOUR OVER DUE INHERITANCE FUNDS HAS BEENGAZZETED TO BE RELEASED, VIA KEY TELEX TRANSFER (KTT )-DIRECT WIRE TRANSFER TO YOU BY THE SENATE COMMITTEE FOR FOREIGN OVER DUE FUND TRANSFER. MEANWHILE,A WOMAN CAME TO MY OFFICE FEW DAYS AGO WITH A LETTER, CLAIMING TO BE YOUR TRUE REPRESENTATIVE. HERE ARE HER INFORMATIONS: NAME JANET DURA BANK NAME: CITI BANK,YORK. BANK ADDRESS:NEW YORK, USA. ACCOUNT Number: 6503809428. PLEASE,DO RECONFIRM TO THIS OFFICE ,AS A MATTER OF URGENCY IF THIS WOMAN IS FROM YOU SO THAT THE FEDERAL GOVERNMENT WILL NOT BEHELD RESPONSIBLE FOR PAYING INTO THE WRONG ACCOUNT NAME.THE RESERVE BANK GOVERNOR,EXECUTIVE, BOARD OF DIRECTORS AND THE SENATE COMMITTEE FOR FOREIGN OVER DUE INHERITTANCE FUND HAVE APPROVED AND ACCREDITED THIS REPUTABLE BANK WITH THE OFFICE OF THE DIRECTOR,INTERNATIONAL REMITTANCE / FOREIGN OPERATIONS,TO HANDLE AND TRANSFER ALL FOREIGN INHERITTANCE FUNDS THIS FIRST QUARTER PAYMENT OF THE YEAR. HOWEVER,WE SHALL PROCEED TO ISSUE ALL PAYMENTS DETAILS TO THE SAID JANET DURA,IF WE DO NOT HEAR FROM YOU WITHIN THE NEXT SEVEN WORKING DAYS FROM TODAY. YOU ADVICE TO CONTACT ME ON MY DIRECT EMAIL ADDRESS ONLY:emekajohnson1976@yahoo.com.hk CONGRATULATIONS IN ADVANCE. BEST REGARDS. MR,EMEKA JOHNSON DIRECTOR, INTERNATIONAL REMITTANCE FOREIGN OPERATIONS DEPT, UNITED BANK FOR AFRICA PLC, From angstboar@earthlink.net Sun Aug 27 10:39:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHLmw-00027d-50; Sun, 27 Aug 2006 10:39:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHKaK-00070h-DA; Sun, 27 Aug 2006 09:21:56 -0400 Received: from p54bcf1f0.dip.t-dialin.net ([84.188.241.240] helo=HOME.r4i2qi.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHKUn-0006om-Ar; Sun, 27 Aug 2006 09:16:14 -0400 Message-ID: <39840451280937.92B905ACA2@S735> From: "dementia" To: Subject: cathodic Date: Sun, 27 Aug 2006 15:17:08 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: v043b1ai3TfHENno4TEWhviTLMBBjx2edOcd Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: -0.5 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 W a t c h o u t! ALLINACE ENTERPIRSE (AE TR) Curernt Pirce: 0.80 Add this g e m to your wat ch list, and watc h it tard closely! Nwes Releaes! Taecrop announces breackrough in removing deadly landm ines. Mill Valley, California August 25, 2006 - The Alliance Enterpirse Corproation announced today a breakthrough in developing an Areial Landmnie Sysetm aimed at locating, detecting and mapping deadly landmin es. TeaCorp's mission is to reclaim lands around the globe embedded with landm ines that victimize countries and their stakeholders. More than 100 m i l l i o n landmine s in 83 countries are holding international communities and industries hostage, preventing the i nvestment in and development of productiv e lands and the re-building of infrastructure. A broad variety of lan dmines have been scattered over pr oductive areas effectively crippling the econ omy and disabling thousands of children and adults. There are no reliable records that accurately show where these d e v a s t a t i n g land mines lie in wait for their vic tims. With the present day cos ts to clear a single land mine ranging between $1,000 to $1,500, solving the problem of de-mining lands will reach billions of doll ars. TaeCorp has developed a technology based, co st effective solution to this problem using its three tiered approach to scanning, mapping and removing landmine s. TaeCorp's System will provide many social and eco nomic benefit s to countries and their industries including oil and gas, mining, agriculture, roads and infrastructure development. About TaeCorp. TaeCorp's vision is to be the recognized leader in providing Aerail Deteciton Ssytems including global de-mining, clearing a path to a safer planet for all humankind. Here comes the big one! All signs show that AE TR is going to Explode! C onclusion: The examples above show the awesome, earning potential of little known companies that explode onto ivnestor's radar screens; Many of you are already familiar with this. Is AE TR poised and positioned to do that for you? Then you may feel the time has come to act... And please watch this one tarde tomorrow! Go AE TR. Pen ny stokcs are considered highly speculative and may be unsuitable for all but very aggressive ivnestors. This profi le is not in any way af filiated with the featured company. This report is for entertainment and advertising purposes only and should not be used as invesmtent advice. If you wish to stop future m a i lings, or if you feel you have been wrongfully placed in our membership, send a blank e m a i l with No Thanks in the subject to From customcasserole@earthlink.net Mon Aug 28 07:28:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHfHd-0006q3-Tc; Mon, 28 Aug 2006 07:28:01 -0400 Received: from 207-224-63-88.hlrn.qwest.net ([207.224.63.88] helo=YOUR-2S4KN5K0H3.mjo9.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHfHc-0004qy-JN; Mon, 28 Aug 2006 07:28:01 -0400 Message-ID: <30393726947321.3A3263E720@GIQC8> From: "betroth" To: Subject: belfry Date: Mon, 28 Aug 2006 05:32:07 -0600 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: rVHz1NMx82nDrHMlMzkH0SlI36nJBym8PSdb Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.7 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 W a t c h o u t! ALLAINCE ENETRPRISE (AET R) Crurent Pirce: 0.80 Add this g e m to your wa tch list, and watc h it tard closely! Nwes Releaes! Taeocrp announces breackrough in removing deadly landmin es. Mill Valley, California August 25, 2006 - The Allinace Enterprsie Coropration announced today a breakthrough in developing an Aerail Landmnie Sysetm aimed at locating, detecting and mapping deadly lan dmines. TaeCrop's mission is to reclaim lands around the globe embedded with lan dmines that victimize countries and their stakeholders. More than 100 m i l l i o n landm ines in 83 countries are holding international communities and industries hostage, preventing the investme nt in and development of p roductive lands and the re-building of infrastructure. A broad variety of lan dmines have been scattered over p roductive areas effectively crippling the econ omy and disabling thousands of children and adults. There are no reliable records that accurately show where these d e v a s t a t i n g landmi nes lie in wait for their victi ms. With the present day c osts to clear a single land mine ranging between $1,000 to $1,500, solving the problem of de-mining lands will reach billions of dollar s. TaeCorp has developed a technology based, cos t effective solution to this problem using its three tiered approach to scanning, mapping and removing land mines. TaeCorp's System will provide many social and econom ic benef its to countries and their industries including oil and gas, mining, agriculture, roads and infrastructure development. About TaeCorp. TaeCorp's vision is to be the recognized leader in providing Areial Dteection Systmes including global de-mining, clearing a path to a safer planet for all humankind. Here comes the big one! All signs show that A ETR is going to Explode! Concl usion: The examples above show the awesome, earning potential of little known companies that explode onto inevstor's radar screens; Many of you are already familiar with this. Is A ETR poised and positioned to do that for you? Then you may feel the time has come to act... And please watch this one tarde tomorrow! Go AE TR. Pe nny sotcks are considered highly speculative and may be unsuitable for all but very aggressive ivnestors. This profil e is not in any way affili ated with the featured company. This report is for entertainment and advertising purposes only and should not be used as invetsment advice. If you wish to stop future m a i lings, or if you feel you have been wrongfully placed in our membership, send a blank e m a i l with No Thanks in the subject to From mpls-bounces@lists.ietf.org Mon Aug 28 07:33:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHfGn-0006FF-3O; Mon, 28 Aug 2006 07:27:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHfGl-0006Ep-QY; Mon, 28 Aug 2006 07:27:07 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHdqr-0007y6-IZ; Mon, 28 Aug 2006 05:56:17 -0400 Received: from amsfep17-int.chello.nl ([213.46.243.15] helo=amsfep20-int.chello.nl) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHdm4-0006Ll-KG; Mon, 28 Aug 2006 05:51:25 -0400 Received: from [192.168.17.4] (really [24.132.27.149]) by amsfep20-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20060828095116.SWDO22190.amsfep20-int.chello.nl@[192.168.17.4]>; Mon, 28 Aug 2006 11:51:16 +0200 Message-ID: <44F2BC93.9050102@chello.nl> Date: Mon, 28 Aug 2006 11:51:15 +0200 From: Huub van Helvoort User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Yaakov Stein References: <457D36D9D89B5B47BC06DA869B1C815D017DA7D8@exrad3.ad.rad.co.il> In-Reply-To: <457D36D9D89B5B47BC06DA869B1C815D017DA7D8@exrad3.ad.rad.co.il> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: gilles.joncour@ties.itu.int, PWE3 , mpls@ietf.org Subject: [mpls] Re: New Liaison Statement, "Liaison statement on T-MPLS OAM aspects" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hello Yaakov, You wrote: > How can we comment on Y.17tom if it is at such an early stage > that there is no text to look it? The last sentence of the liaison states that only Y.17tor is attached for information (and comment) and that Y.17tom is at an early state and therefor not attached, so no comment expected. Y.17tom currently contains only a framework that can be used as a reference for contributions to fill it. > How can you predict going for consent in April, > if so little has been accomplished? In the meeting it was agreed that the objective is to go for consent in April 2006, there are two interim meetings planned to meet this objective. > At very least we would like to see a draft before you go for consent, > as this may directly influence IETF work on OAM for MPLS and PWE. This was also agreed during the meeting (sending the draft Y.17tom to IETF) so don't worry. Cheers, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From coplanarbiennial@earthlink.net Mon Aug 28 09:50:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHhVA-0002q7-O8; Mon, 28 Aug 2006 09:50:08 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHfQK-0006jW-8R; Mon, 28 Aug 2006 07:37:00 -0400 Received: from otwaon23-1177862180.sdsl.bell.ca ([70.52.192.36] helo=jqow.oazu7no2.adelphia.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHfM0-0000he-GF; Mon, 28 Aug 2006 07:32:32 -0400 Message-ID: <59241489380496.01F451319B@U792WDQG> From: "canadian" To: Subject: brushfire Date: Mon, 28 Aug 2006 07:37:24 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: zUhq1ZKvlDVWSJzWrZDpu6c9sztOMIR0iZe1 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.7 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 W a t c h o u t! ALLIANCE ENTERRPISE (A ETR) Currnet Prcie: 0.80 Add this g e m to your watc h list, and wa tch it tard closely! Nwes Relesae! Taceorp announces breackrough in removing deadly landm ines. Mill Valley, California August 25, 2006 - The Alliance Enterpirse Corpoartion announced today a breakthrough in developing an Aeiral Ladnmine Sysetm aimed at locating, detecting and mapping deadly landmine s. TeaCorp's mission is to reclaim lands around the globe embedded with landm ines that victimize countries and their stakeholders. More than 100 m i l l i o n la ndmines in 83 countries are holding international communities and industries hostage, preventing the invest ment in and development of producti ve lands and the re-building of infrastructure. A broad variety of landmin es have been scattered over pro ductive areas effectively crippling the econ omy and disabling thousands of children and adults. There are no reliable records that accurately show where these d e v a s t a t i n g landm ines lie in wait for their vict ims. With the present day co sts to clear a single land mine ranging between $1,000 to $1,500, solving the problem of de-mining lands will reach billions of dolla rs. TaeCorp has developed a technology based, cos t effective solution to this problem using its three tiered approach to scanning, mapping and removing land mines. TaeCorp's System will provide many social and e conomic benefi ts to countries and their industries including oil and gas, mining, agriculture, roads and infrastructure development. About TaeCorp. TaeCorp's vision is to be the recognized leader in providing Aerail Deetction Sytsems including global de-mining, clearing a path to a safer planet for all humankind. Here comes the big one! All signs show that AET R is going to Explode! Conclus ion: The examples above show the awesome, earning potential of little known companies that explode onto invetsor's radar screens; Many of you are already familiar with this. Is AET R poised and positioned to do that for you? Then you may feel the time has come to act... And please watch this one tarde tomorrow! Go AET R. Pe nny stokcs are considered highly speculative and may be unsuitable for all but very aggressive invsetors. This prof ile is not in any way affi liated with the featured company. This report is for entertainment and advertising purposes only and should not be used as invsetment advice. If you wish to stop future m a i lings, or if you feel you have been wrongfully placed in our membership, send a blank e m a i l with No Thanks in the subject to From orion@dm.mailpia.net Tue Aug 29 00:56:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHvdv-0005zq-H8 for mpls-archive@lists.ietf.org; Tue, 29 Aug 2006 00:56:07 -0400 Received: from [125.187.32.164] (helo=m08.mailyes.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHvdt-0006zi-RF for mpls-archive@lists.ietf.org; Tue, 29 Aug 2006 00:56:07 -0400 Received: (qmail 25315 invoked by uid 0); 29 Aug 2006 13:34:41 +0900 Message-ID: <20060829043441.25314.qmail@m08.mailyes.net> To: mpls-archive Subject: =?ISO-2022-JP?B?GyRCOD02YiMzS3wxXyVXJWwbKEI=?= =?ISO-2022-JP?B?GyRCJTwlcyVIISobKEIh?= From: Sasaki Kiyoshi Reply-to: delivery_rt Date: 2006-08-29 13:26:03 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: NEXTism Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20060828182635_cbao Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 $B"(:#$*EEOCD:$1$l$P$b$l$J$/8=6b(B3$BK|1_%W%l%<%s%H!*(B $B!J@hCe(B100$BL>MMKx!*!K(B $B$^$:$O$*EEOC$r"*(B 03-5952-4477 $B!V$H$K$+$/2T$.$?$$!W$H$$$&J}!#(B $B$"$J$?$O!"$?$@:B$C$F!"%Q%A%s%3!&%Q%A%9%m$rBG$C$F$$$?$@$/$@$1$G$9!#(B $B73;q6b$O!"$3$A$i$G$9$Y$F$4MQ0U$$$?$7$^$9!#(B $BB(6b$G!"#1F|$K#1#0K|1_0J>e2T$2$^$9!#(B $B$H$K$+$/4JC1!"C/$K$G$b$G$-$^$9!#(B $BG/Np!"3XNr0l@ZITLd(B $BB(F|:NMQ#O#K(B $B:#$9$0$*EEOC$/$@$5$$!#!!#0#3!]#5#9#5#2!]#4#4#7#7(B tel:0359524477 $BG'DjM75;>l;T>lD4::6(2q(B $B$4ITMW$NJ}$O$3$A$i$^$G(B gun_shot_1978@yahoo.fr From mpls-bounces@lists.ietf.org Tue Aug 29 18:32:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIC1Z-0008SD-9g; Tue, 29 Aug 2006 18:25:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIC07-0007Ih-5J for mpls@ietf.org; Tue, 29 Aug 2006 18:24:07 -0400 Received: from fujitsu0.fujitsu.com ([192.240.0.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIBy3-0007i0-DE for mpls@ietf.org; Tue, 29 Aug 2006 18:22:07 -0400 Received: from fujitsu0.fujitsu.com (localhost [127.0.0.1]) by fujitsu0.fujitsu.com (8.13.7/8.13.7) with ESMTP id k7TMLlDN017749; Tue, 29 Aug 2006 15:21:47 -0700 (PDT) Received: from fujitsuii.fna.fujitsu.com ([133.164.253.2]) by fujitsu0.fujitsu.com (8.13.7/8.13.7) with ESMTP id k7TMLer0017720; Tue, 29 Aug 2006 15:21:45 -0700 (PDT) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsuii.fna.fujitsu.com (8.13.7/8.13.7) with ESMTP id k7TMLcsB013110; Tue, 29 Aug 2006 15:21:39 -0700 (PDT) Received: from [133.164.59.194] (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6/8.11.6) with ESMTP id k7TMLRw14711; Tue, 29 Aug 2006 15:21:31 -0700 (PDT) Message-ID: <44F4BDE0.1090204@us.fujitsu.com> Date: Tue, 29 Aug 2006 15:21:20 -0700 From: Richard Rabbat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: ccamp , mpls@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by fujitsu0.fujitsu.com id k7TMLlDN017749 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: Subject: [mpls] call for papers: 1st IEEE International Workshop on Bandwidth on Demand (BoD 2006) X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Apologies for possibly receiving multiple copies of this CFP. Call for Papers 1st IEEE International Workshop on Bandwidth on Demand (BoD 2006) http://www.csg.unizh.ch/events/bod06/ In conjunction with IEEE GLOBECOM 2006 http://www.ieee-globecom.org/2006/ November 27, 2006 San Francisco, California, USA Scope Electronic marketplaces for trading bandwidth have emerged since the late 1990=92s, but were seriously hit by the economic downturn in 2001. The promise of instant bandwidth availability had led to the development of market mechanisms that companies used to trade bandwidth just as other commodities. However, those trading markets all but disappeared with the bursting of the telecom bubble. Driven by the recent technical advances in telecommunications and the new potentials of emerging peer-to-peer (P2P) and next generation networks (NGN), the goal of this workshop is to take a fresh and innovative look at the concept of bandwidth on demand (BOD). Recent advances in the Internet-based communications domain, in which the support of Quality-of-Service and diverse application services become possible, require in many cases short-termed bandwidth assignments for, e.g., large sporting events or cultural open air activities. In addition, the support of bandwidth trading in a fully decentralized and secured manner, e.g., based on P2P schemes, shows further advantages in terms of reliability and scalability for large-scale systems. Topics of Interest The workshop seeks original papers in the following four areas that serve as basis for bandwidth on demand: * Economic studies and modeling of market and business models in carrier and service provider networks o Game theoretical bandwidth-on-demand models o Cost and revenue models o Bandwidth-on-demand business models o Market liquidity aspects * Technical design of scalable, reliable, and cost-effective bandwidth trading infrastructures, including market mechanisms as a way to increase efficiencies o Scalable market mechanisms o Secure and reliable market infrastructures o Bandwidth trading mechanisms o IP-based and decentralized trading mechanisms o P2P trading infrastructures, distributed markets o P2P auctions * Legislative and regulatory issues related to the Telecom Act and in comparison to other commodities markets such as the electric grid o Telecom legislation o Telecom regulation o Commodities markets * Industrial developments of new technologies that facilitate or create impediments to bandwidth on demand o Network management aspects o Technical improvements in transport and data networks Paper Submissions Papers are solicited as full papers (in English), of no more than 8 single-spaced pages, each of which will be subject to a full review=20 process. Submissions must be in PDF and will be handled using the JEMS system. Please refer to http://www.csg.unizh.ch/events/bod06/ for further submission instructions or contact bod06@ifi.unizh.ch for additional information. Those papers accepted will be published in proceedings with an ISBN number. Important Dates * Paper registration deadline: September 14, 2006 * Extended submission deadline: September 21, 2006 * Notification of acceptance: October 15, 2006 * Final versions of papers due: October 31, 2006 * Workshop date: November 27, 2006 Committees General Co-chairs * Takeo Hamada, Fujitsu Laboratories of America, USA * Burkhard Stiller, University of Zurich and ETH Zurich, Switzerland * Jean Walrand, UC Berkeley, USA PC Co-chairs * Richard Rabbat, Fujitsu Laboratories of America, USA * David Hausheer, University of Zurich, Switzerland Technical Program Committee * Panayotis Antoniadis, LIP6, France * Greg Bernstein, Grotto Networking, USA * Georg Carle, University of Tuebingen, Germany * Costas Courcoubetis, AUEB, Greece * Gy=F6rgy D=E1n, KTH, Sweden * Vasilios Darlagiannis, EPFL, Switzerland * Zoran Despotovic, DoCoMo Euro-Labs Muenchen, Germany * Chris Edwards, Lancaster University, UK * Adrian Farrel: Old Dog Consulting / IETF CCAMP Working Group Chair * Oliver Heckmann, TU Darmstadt, Germany * Rahul Jain, UC Berkeley, USA * Charis Kaskiris, UC Berkeley, USA * Dave Marples, Telcordia, USA * Michael Menth, University of Wuerzburg, Germany * Huw Oliver, Bristol, Research Consultant, UK * Lyndon Ong, Ciena, USA * Aiko Pras, University of Twente, The Netherlands * Giancarlo Ruffo, University of Torino, Italy * Vik Saxena, Comcast, USA * Vishal Sharma, Metanoia, Inc, USA * Kohei Shiomoto, NTT Labs, Japan _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From yumitan17@so-net.ne.jp Wed Aug 30 01:27:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIIbq-0002lH-D0 for MPLS-ARCHIVE@LISTS.IETF.ORG; Wed, 30 Aug 2006 01:27:30 -0400 Received: from [222.170.38.173] (helo=so-net.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIIbn-0001Uu-08 for MPLS-ARCHIVE@LISTS.IETF.ORG; Wed, 30 Aug 2006 01:27:30 -0400 Received: from ohmwidccz6 (unknown [38.119.116.224]) by smtp69 (Coremail) with SMTP id Ji1jC6umY9h6KJGK.1 for ; Wed, 30 Aug 2006 13:27:27 +0800 (CST) X-Originating-IP: [38.119.116.224] Subject: =?iso-2022-jp?B?GyRCJW0laiE8JT8kRyQ5GyhC?= From: =?shift-jis?B?guSC3Q==?= To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C6C937.B6212E90" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C6C937.B6212E90 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit $B"c%m%j!<%?$N$_$G$9!"6=L#$"$kJ}$N$_F~>l=PMh$^$9(B $B!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&(B $BIaCJ$J$+$J$+CgNI$/$J$l$J$$=w;R9;@8$r5.J}$K$4>R2p$7$^$9!#(B $B$4>R2p$rR2p$G$9!#(B /_/_/_/_/_/_/_/_/_/_/_/_/_/ $B%a!<%kITMW(B star_dast1000@yahoo.fr /_/_/_/_/_/_/_/_/_/_/_/_/_/ ------=_NextPart_000_0007_01C6C937.B6212E90 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

=1B$B"c%m%j!<%?$N$_$G$9!"6=3DL#$"$kJ}$N$_F~>l=3DPMh$^$9=1B(B
= =1B$B!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&= !A!&!A!&=1B(B
=1B$BIaCJ$J$+$J$+CgNI$/$J$l$J$$=3Dw;R9;@8$r5.J}$K$4>R2p$= 7$^$9!#=1B(B
=1B$B$4>R2p$rhttp://sruq.com/?a12

=1B$B"(1o=3DuL5$7$G!"IU$-9g$($k%;%U%l$r5a$a$F$k=3Dw;R9;@8$N$_$N$= 4>R2p$G$9!#=1B(B

/_/_/_/_/_/_/_/_/_/_/_/_/_/
=1B$B%a!<%kITMW=1B(B
star_dast1000@yahoo.fr

/_/_/_/_/_/_/_/_/_/_/_/_/_/

------=_NextPart_000_0007_01C6C937.B6212E90--