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" <FannyEdwards@mail.ru>
X-Mailer: The Bat! (v3.01 RC8) UNREG / CD5BF9353B3B7091
Reply-To: "Fanny Edwards" <FannyEdwards@mail.ru>
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" <crosspointbarb@diplomats.com>
To: <mpls-archive@lists.ietf.org>
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

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>

<body bgcolor="#FFFFFF" text="#000000">
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! <br></br>
<br><b>TRADER AND INVESTOR ALERT!  </br>
<br>FRIDAY AUGUST 4, 2006  </b></br>
<br>GLOBEX INC.  </br>
<br>Symbol: GLXI. PK</br>
<br>BIOETHANOL PLAY!!  </br>
<br>Price: $0.65</br> 


This stock is fertile ground for investors who want to be the first harvesters. There’s clear evidence of that.<br></br>
<br><b>RECENT HEADLINES:</b>  </br>
 
<br>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  </br>
 
<br><b>DECIDE FOR YOURSELF!!</b> </br>

<br><b>IS THIS THE "HOTSHOTSTOCKALERT" YOU'VE BEEN WAITING FOR?!!</b></br>
Without any doubt this stock opens great possibilities for a trader. 
<p>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!</p>

</body>
</html>






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: <FDDE83108C11054B813316D1C31516BF28B281@E03MVY1-UKDY.domain1.systemhost.net>
References: <FDDE83108C11054B813316D1C31516BF28B281@E03MVY1-UKDY.domain1.systemhost.net>
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" <tnadeau@cisco.com>
Subject: Re: [mpls] Comments on draft-swallow-mpls-mcast-cv-00
Date: Fri, 4 Aug 2006 13:24:55 -0400
To: "<benjamin.niven-jenkins@bt.com>" <benjamin.niven-jenkins@bt.com>
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<tnadeau@cisco.com>
	|Subject:Re=3A=20[mpls]=20Comments=20on=20draft-swallow-mpls-mcast-cv-00
	|To:=22<benjamin.niven-jenkins@bt.com>=22=20<benjamin.niven-jenkins@bt.com>;
	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 <mpls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mpls>
List-Post: <mailto:mpls@lists.ietf.org>
List-Help: <mailto:mpls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=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: <E1G95gH-0003sH-P3@stiedprstage1.ietf.org>
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 <mpls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mpls>
List-Post: <mailto:mpls@lists.ietf.org>
List-Help: <mailto:mpls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=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" <adrian@olddog.co.uk>
To: "Tom Petch" <nwnetworks@dial.pipex.com>, <benjamin.niven-jenkins@bt.com>,
	<mpls@lists.ietf.org>
References: <F5AAFD21F2034349BF638211B5F27B0F087AB49A@i2km86-ukdy.domain1.systemhost.net>
	<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 <adrian@olddog.co.uk>
List-Id: Multi-Protocol Label Switching WG <mpls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mpls>
List-Post: <mailto:mpls@lists.ietf.org>
List-Help: <mailto:mpls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=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" <adrian@olddog.co.uk>
To: <mpls@lists.ietf.org>
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 <adrian@olddog.co.uk>
List-Id: Multi-Protocol Label Switching WG <mpls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mpls>
List-Post: <mailto:mpls@lists.ietf.org>
List-Help: <mailto:mpls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=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 <iesg-secretary@ietf.org>
> To: IETF-Announce <ietf-announce@ietf.org>
> Cc: <ccamp@ops.ietf.org>
> 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 '
>>    <draft-ietf-ccamp-gmpls-te-mib-15.txt> as a Proposed Standard
>> - 'Definitions of Textual Conventions for Generalized Multiprotocol Label
>>    Switching (GMPLS) Management '
>>    <draft-ietf-ccamp-gmpls-tc-mib-10.txt> as a Proposed Standard
>> - 'Generalized Multiprotocol Label Switching (GMPLS) Label Switching
> Router
>>    (LSR) Management Information Base '
>>    <draft-ietf-ccamp-gmpls-lsr-mib-14.txt> 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" <coonanchorite@doglover.com>
To: <mpls-archive@lists.ietf.org>
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 <mpls@lists.ietf.org>; 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: <cae03ac50608100209o197b49b1uc8ee408e6ba89cef@mail.gmail.com>
Date: Thu, 10 Aug 2006 14:39:21 +0530
From: "sasi sekhar" <sasi426@gmail.com>
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 <mpls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mpls>
List-Post: <mailto:mpls@lists.ietf.org>
List-Help: <mailto:mpls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=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

<div>Hi ,</div>
<div>&nbsp;</div>
<div>I am working on project MPLS.I am looking for MPLS source&nbsp;code.Can anyone send the links.</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>Thanks,</div>
<div>sasi&nbsp;&nbsp;</div>

------=_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: <FDDE83108C11054B813316D1C31516BF40D66A@E03MVY1-UKDY.domain1.systemhost.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [mpls] Comments on draft-swallow-mpls-mcast-cv-00
Thread-Index: Aca36upT1wGnbbnSR2OK2eBIAXhxJQEmY/lg
From: <benjamin.niven-jenkins@bt.com>
To: <tnadeau@cisco.com>
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 <mpls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mpls>
List-Post: <mailto:mpls@lists.ietf.org>
List-Help: <mailto:mpls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=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 <mailto:tnadeau@cisco.com> 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: <FDDE83108C11054B813316D1C31516BF40D66A@E03MVY1-UKDY.domain1.systemhost.net>
References: <FDDE83108C11054B813316D1C31516BF40D66A@E03MVY1-UKDY.domain1.systemhost.net>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <CA3DDE90-0C9B-4778-B7BB-FA0F511B52D6@cisco.com>
Content-Transfer-Encoding: 7bit
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: [mpls] Comments on draft-swallow-mpls-mcast-cv-00
Date: Thu, 10 Aug 2006 10:41:05 -0400
To: <benjamin.niven-jenkins@bt.com>
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<tnadeau@cisco.com>
	|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 <mpls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mpls>
List-Post: <mailto:mpls@lists.ietf.org>
List-Help: <mailto:mpls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=subscribe>
Errors-To: mpls-bounces@lists.ietf.org


On Aug 10, 2006, at 9:57 AM, <benjamin.niven-jenkins@bt.com> 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 <mailto:tnadeau@cisco.com> 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 <mpmwaqargybjoo@triumph-adler.de>; Sat, 12 Aug 2006 08:38:13 +0100
Message-Id: <E3A4nm6-9494Yt-00@mail.nitros4.org>
X-Sender: mpmwaqargybjoo@triumph-adler.de 
Date: Sat, 12 Aug 2006 01:34:13 -0600
From: "Frederic Neff" <mpmwaqargybjoo@triumph-adler.de>
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" <arborealantedate@samerica.com>
To: <mpls-archive@lists.ietf.org>
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 <swallow@cisco.com>
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<swallow@cisco.com>
	|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 <mpls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mpls>
List-Post: <mailto:mpls@lists.ietf.org>
List-Help: <mailto:mpls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=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" <baldwinanxiety@berlin.com>
To: <mpls-archive@lists.ietf.org>
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" <conceiveblackwell@alumnidirector.com>
To: <mpls-archive@lists.ietf.org>
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" <bogusbreach@rqhp.havebzn3.vg>
To: <mpls@lists.ietf.org>
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" <carobagribusiness@rrdesign.com>
To: <mpls-bounces@lists.ietf.org>
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" <comprehendayers@rototrade.com>
To: <mpls-archive@lists.ietf.org>
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" <bladdernutaward@roundtabledg.com>
To: <mpls-bounces@lists.ietf.org>
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" <capstanbianco@rovel.com>
To: <mpls-bounces@lists.ietf.org>
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" <aldrinaware@earthlink.net>
To: <mpls-archive@lists.ietf.org>
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" <adrian@olddog.co.uk>
To: <mpls@lists.ietf.org>
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 <adrian@olddog.co.uk>
List-Id: Multi-Protocol Label Switching WG <mpls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mpls>
List-Post: <mailto:mpls@lists.ietf.org>
List-Help: <mailto:mpls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=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: <Internet-Drafts@ietf.org>
To: <i-d-announce@ietf.org>
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 <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <E1GFDMy-0006wm-5k@stiedprstage1.ietf.org>
Date: Mon, 21 Aug 2006 13:15:24 -0400
X-Spam-Score: -5.8 (-----)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Cc: mpls mailing list <mpls@lists.ietf.org>,
	Internet Architecture Board <iab@iab.org>,
	RFC Editor <rfc-editor@rfc-editor.org>
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 <mpls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mpls>
List-Post: <mailto:mpls@lists.ietf.org>
List-Help: <mailto:mpls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=subscribe>
Errors-To: mpls-bounces@lists.ietf.org

The IESG has approved the following document:

- 'OAM Requirements for Point-to-Multipoint MPLS Networks '
   <draft-ietf-mpls-p2mp-oam-reqs-01.txt> 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
<Black_David@emc.com>):

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" <adrian@olddog.co.uk>
To: <routing-discussion@ietf.org>, <ccamp@ops.ietf.org>, <mpls@lists.ietf.org>
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 <adrian@olddog.co.uk>
List-Id: Multi-Protocol Label Switching WG <mpls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mpls>
List-Post: <mailto:mpls@lists.ietf.org>
List-Help: <mailto:mpls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=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: <Internet-Drafts@ietf.org>
To: <i-d-announce@ietf.org>
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" <yaakov_s@rad.com>
From: "Andrew G. Malis" <amalis@gmail.com>
In-Reply-To: <457D36D9D89B5B47BC06DA869B1C815D017DA7EE@exrad3.ad.rad.co.
 il>
References: <C86A857D-B1DF-46F1-9397-59893492C791@tcb.net>
	<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\)\)\)\)\)\)\)\)" <pwe3@ietf.org>
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 <mpls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mpls>
List-Post: <mailto:mpls@lists.ietf.org>
List-Help: <mailto:mpls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=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" <yaakov_s@rad.com>
To: <gilles.joncour@ties.itu.int>
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 <pwe3@ietf.org>
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 <mpls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mpls>
List-Post: <mailto:mpls@lists.ietf.org>
List-Help: <mailto:mpls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=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" <defectalumni@earthlink.net>
To: <mpls-bounces@lists.ietf.org>
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" <yaakov_s@rad.com>
To: "Andrew G. Malis" <amalis@gmail.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Cc: mpls@ietf.org,
	"pwe3 WG \(\(\(\(\(\(\(\(E-mail\)\)\)\)\)\)\)\)" <pwe3@ietf.org>
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 <mpls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mpls>
List-Post: <mailto:mpls@lists.ietf.org>
List-Help: <mailto:mpls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=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" <euromillionswinningnotice@yahoo.co.uk>
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" <acrimoniousdecolonize@earthlink.net>
To: <mpls-bounces@lists.ietf.org>
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" <blindfolddeception@earthlink.net>
To: <mpls-archive@lists.ietf.org>
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 <mmorrow@cisco.com>
To: Yaakov Stein <yaakov_s@rad.com>, <gilles.joncour@ties.itu.ch>
Message-ID: <C11267AC.2D722%mmorrow@cisco.com>
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<mmorrow@cisco.com>
	|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<yaakov_s@rad.com>,=20<gilles.joncour@ties.itu.ch>;
	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 <pwe3@ietf.org>
X-BeenThere: mpls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mpls>
List-Post: <mailto:mpls@lists.ietf.org>
List-Help: <mailto:mpls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=subscribe>
Errors-To: mpls-bounces@lists.ietf.org

Agree with Yaakov here.

/m


On 22/8/06 9:14 am, "Yaakov Stein" <yaakov_s@rad.com> 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 <ietf-announce@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
Message-Id: <E1GGdDg-00019k-Jj@stiedprstage1.ietf.org>
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 <mpls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mpls>
List-Post: <mailto:mpls@lists.ietf.org>
List-Help: <mailto:mpls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=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 '
   <draft-ietf-mpls-lsr-self-test-06.txt> 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" <coronatebudget@earthlink.net>
To: <mpls-archive@lists.ietf.org>
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" <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" <boobybrucellosis@earthlink.net>
To: <mpls-bounces@lists.ietf.org>
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" <berlinargo@earthlink.net>
To: <mpls-bounces@lists.ietf.org>
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 <hhelvoort@chello.nl>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Yaakov Stein <yaakov_s@rad.com>
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 <pwe3@ietf.org>, 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 <mpls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mpls>
List-Post: <mailto:mpls@lists.ietf.org>
List-Help: <mailto:mpls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=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" <bluntdaze@earthlink.net>
To: <mpls-bounces@lists.ietf.org>
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 <mpls-archive@lists.ietf.org>
Subject: =?ISO-2022-JP?B?GyRCOD02YiMzS3wxXyVXJWwbKEI=?=
 =?ISO-2022-JP?B?GyRCJTwlcyVIISobKEIh?=
From: Sasaki Kiyoshi <orion@dm.mailpia.net>
Reply-to: delivery_rt <orion@dm.mailpia.net>
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 <richard@us.fujitsu.com>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: ccamp <ccamp@ops.ietf.org>, 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 <mpls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mpls>
List-Post: <mailto:mpls@lists.ietf.org>
List-Help: <mailto:mpls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request@lists.ietf.org?subject=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 <mpls-archive@lists.ietf.org>; 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==?= <yumitan17@so-net.ne.jp>
To: <mpls-archive@lists.ietf.org>
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$r<u$1$?$$J}$O$3$A$i$X(B $B"M!!(Bhttp://sruq.com/?a12


$B"(1o=uL5$7$G!"IU$-9g$($k%;%U%l$r5a$a$F$k=w;R9;@8$N$_$N$4>R2p$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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-2022-jp">
<META content=3D"MSHTML 6.00.2900.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"MS UI Gothic"=20
size=3D2>=1B$B"c%m%j!<%?$N$_$G$9!"6=3DL#$"$kJ}$N$_F~>l=3DPMh$^$9=1B(B<BR>=
=1B$B!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&=
!A!&!A!&=1B(B<BR>=1B$BIaCJ$J$+$J$+CgNI$/$J$l$J$$=3Dw;R9;@8$r5.J}$K$4>R2p$=
7$^$9!#=1B(B<BR>=1B$B$4>R2p$r<u$1$?$$J}$O$3$A$i$X=1B(B=20
=1B$B"M!!=1B(B<A =
href=3D"http://sruq.com/?a12">http://sruq.com/?a12</A><BR></FONT></DIV>
<DIV><FONT face=3D"MS UI Gothic" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"MS UI Gothic"=20
size=3D2>=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</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"MS UI Gothic" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"MS UI Gothic" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"MS UI Gothic" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"MS UI Gothic" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"MS UI Gothic" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"MS UI Gothic" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"MS UI Gothic" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"MS UI Gothic" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"MS UI Gothic" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"MS UI Gothic" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"MS UI Gothic" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"MS UI Gothic" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"MS UI Gothic" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"MS UI Gothic" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"MS UI Gothic" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"MS UI Gothic" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"MS UI Gothic" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"MS UI Gothic" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"MS UI Gothic" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"MS UI Gothic" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"MS UI Gothic" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"MS UI Gothic" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"MS UI Gothic" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"MS UI Gothic" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"MS UI Gothic" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"MS UI Gothic" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"MS UI Gothic" =
size=3D2>/_/_/_/_/_/_/_/_/_/_/_/_/_/<BR>=1B$B%a!<%kITMW=1B(B<BR><A=20
href=3D"mailto:star_dast1000@yahoo.fr">star_dast1000@yahoo.fr</A><BR><A=20
href=3D"mailto:s_for_sweetbaby@yahoo.co.uk"></A><A=20
href=3D"mailto:pa_for_partyparty@yahoo.co.uk"></A><A=20
href=3D"mailto:sasa_info001@yahoo.ca"></A><BR><A=20
href=3D"mailto:ss_info_0002@yahoo.ca"></A></FONT></DIV>
<DIV><FONT face=3D"MS UI Gothic" =
size=3D2>/_/_/_/_/_/_/_/_/_/_/_/_/_/</FONT></DIV>
<DIV><FONT face=3D"MS UI Gothic" =
size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

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