va4me | 1 Oct 02:46 2005
Picon
Picon

MPLS 2005 Conference

Is there any way you can get these guys to stop spamming the various PPVPN/MPLS mailing lists?

Unless they are giving free admission to list members, they should not be using IETF mailing lists to
advertise their conference. 

Thank you!!

---------

-----Original Message-----
From: mpls-bounces <at> lists.ietf.org [mailto:mpls-bounces <at> lists.ietf.org]On Behalf Of MPLS 2005
Sent: Friday, September 30, 2005 4:33 PM
To: mpls <at> ietf.org
Subject: [mpls] Register Now to Attend MPLS 2005 (Oct 16-19) Washington, DC

a{text-decoration:none;} a:hover{text-decoration:none;} Your browser does not support script 

  Home  Program     Tutorials
     Technical Sessions
     Exhibits
     Inter-Op Demo
  Sponsors     MPLS 2005 Sponsors
     Exhibiting  <at>  MPLS 2005
     Exhibitor Package
  Registration     Attendees
     Speakers
     Press/Media
     Exhibitor Staff
  Press & Media     Press Releases
     Registration
(Continue reading)

Fred Baker | 2 Oct 04:48 2005
Picon

Re: MPLS 2005 Conference

the chairs have the capability of blocking the sender's addresses.  
That might be taken unkindly, but it would get the point across.

On Oct 1, 2005, at 5:16 AM, va4me <at> comcast.net wrote:

> Is there any way you can get these guys to stop spamming the  
> various PPVPN/MPLS mailing lists?
>
> Unless they are giving free admission to list members, they should  
> not be using IETF mailing lists to advertise their conference.
>
> Thank you!!
>
>
> ---------
>
> -----Original Message-----
> From: mpls-bounces <at> lists.ietf.org [mailto:mpls- 
> bounces <at> lists.ietf.org]On Behalf Of MPLS 2005
> Sent: Friday, September 30, 2005 4:33 PM
> To: mpls <at> ietf.org
> Subject: [mpls] Register Now to Attend MPLS 2005 (Oct 16-19)  
> Washington, DC
>
>
> a{text-decoration:none;} a:hover{text-decoration:none;} Your  
> browser does not support script
>
>
>
(Continue reading)

George Swallow | 2 Oct 16:31 2005
Picon

Re: MPLS 2005 Conference

So I tried to stop a different conference (just wrote an threatened to
cut off their email address).  They stopped using that address, but kept
sending announcements using a variety of private addresses.  I think
you'd have to close the list entirely to be effective.  But we have lots
of exploders subsribed to our list, so that's a big policy change.

...George

========================================================================
George Swallow             Cisco Systems                  (978) 936-1398
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719

_______________________________________________
mpls mailing list
mpls <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls

Ingo Krueger | 3 Oct 01:01 2005

Ingo Krueger/MAIN/MC1 not in the Office this Week

Ich werde ab  01.10.2005 nicht im Büro sein. Ich kehre zurück am
08.10.2005.

Hello,
I'm not in the office.  I'll be back on 10.10.2005 Kind regards

Ingo Krüger

_______________________________________________
mpls mailing list
mpls <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls

Boon Sain Yeo | 3 Oct 10:33 2005
Picon

CFP - SensorWare 2006 (deadline extended)

(My apologies if you receive multiple copies of this message)
 
***********************************************************
1st International Workshop on Software for Sensor Networks (SensorWare) – CFP
***********************************************************
 
 
Welcome to the 1st International Workshop on Software for Sensor Networks (SensorWare) to be held on the 8 January 2006. The workshop is held in conjunction with COMSWARE 2006 in the beautiful and historical city of New Delhi.
 
 
Advances in technology have made deployment of miniature sensors a realistic proposition. These sensors are low-power, inexpensive, smart devices with multiple on-board sensors, and are connected through wireless links, so as to form a collaborative sensor network to perform a specific task. As a result, it opens up a new paradigm of ubiquitous computing and enables a range of applications that are previously unrealizable or too costly to be realized. However, given the limitation of on-board hardware, one of the key areas towards achieving superior performance is through the software implementation. The workshop is intended for the presentation and discussion of novel algorithms and software implementation for sensor networks. This workshop, intends to bring together engineering experts and academicians to discuss the current status, technical challenges, standards, fundamental issues, and future services and applications in the form of panels and technical presentation.
 
 
 
Topics of interest include but are not limited to the following:
 
 
 
Operating System
Efficient algorithms
Protocol design
Performance analysis
Performance related issues
Sensor applications
Deployment issues and scenarios
Middleware
Sensor security
Sensor network design and modeling 
 
 
Workshop co-chairs:
 
Nirmala Shenoy (ns <at> rit.edu), RIT, USA
Boon Sain Yeo (boonyeo <at> ieee.org), Institute for Infocomm Research, Singapore
 
 
 
TPC Members:
 
Holger Karl, University of Paderborn, Germany,
Ling-Jyh Chen, Academia Sinica, Taiwan
Kui Wu, University of Victoria, Canada,
Daeyoung Kim, ICU, Korea
Leonard Barolli, Fukuoka Institute of Technology, Japan,
Wei-Peng, Fujitsu Labs of America, USA
Jason Redi, BBN Technologies, USA     
Biao Chen, Syracuse University, USA
Hairong  Qi, University of Tennessee, USA
Xiaojun Cao, Rochester Institute of Technology, USA
Xin Wang, University of Buffalo, USA
James Minseok Kwon, RIT, USA
Wenye Wang, North Carolina State University, USA
Fei Hu, RIT, USA
Robin Chellappa, Deakin Univeristy, Australia 
 
Technical Papers has to be submitted to the co-chairs at boonyeo <at> ieee.org.
 
Papers should be written in English and should preferably follow the instructions in template.pdf. Preferred maximum paper length is 6 printed pages (10-point font) including figures.
 

Important Dates:
 
Paper Submission Deadline: 14 October 2005
Notification Acceptance/Rejection: 14 November 2005
Final Camera-Ready Paper Submission: 2 December 2005
 
Please visit the workshop website at http://www.sensorware.org for more info.
 
We look forward to seeing you at SensorWare.
 
Many thanks
Best regards,
 
Boon and Nirmala
Workshop co-chairs
_______________________________________________
mpls mailing list
mpls <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
Internet-Drafts | 3 Oct 21:50 2005
Picon

I-D ACTION:draft-ietf-mpls-lsp-ping-10.txt

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		: Detecting MPLS Data Plane Failures
	Author(s)	: K. Kompella, G. Swallow
	Filename	: draft-ietf-mpls-lsp-ping-10.txt
	Pages		: 43
	Date		: 2005-10-3
	
This document describes a simple and efficient mechanism that can be
   used to detect data plane failures in Multi-Protocol Label Switching
   (MPLS) Label Switched Paths (LSPs).  There are two parts to this
   document: information carried in an MPLS "echo request" and "echo
   reply" for the purposes of fault detection and isolation; and
   mechanisms for reliably sending the echo reply.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-10.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> 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-lsp-ping-10.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 <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-lsp-ping-10.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.
Attachment: message/external-body, 137 bytes
Attachment (draft-ietf-mpls-lsp-ping-10.txt): message/external-body, 69 bytes
_______________________________________________
mpls mailing list
mpls <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
Internet-Drafts | 4 Oct 21:50 2005
Picon

I-D ACTION:draft-ietf-mpls-ldp-survey2002-00.txt

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		: LDP Implementation Survey Results
	Author(s)	: B. Thomas, L. Andersson
	Filename	: draft-ietf-mpls-ldp-survey2002-00.txt
	Pages		: 22
	Date		: 2005-10-4
	
   Multiprotocol Label Switching (MPLS) is a method for forwarding
   packets that uses short, fixed-length values carried by packets,
   called labels, to determine packet nexthops [RFC3031]).  A
   fundamental concept in MPLS is that two Label Switching Routers
   (LSRs) must agree on the meaning of the labels used to forward
   traffic between and through them.  This common understanding is
   achieved by using a set of procedures, called a label distribution
   protocol, by which one LSR informs another of label bindings it has
   made.  One such protocol called LDP [RFC3036] is used by LSRs to
   distribute labels to support MPLS forwarding along normally routed
   paths.  This document reports on a survey of LDP implementations
   conducted in August 2002 as part of the process of advancing LDP from
   proposed to draft standard.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-survey2002-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> 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-ldp-survey2002-00.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 <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-ldp-survey2002-00.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.
Attachment: message/external-body, 143 bytes
_______________________________________________
mpls mailing list
mpls <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls

v6 over v4 using igp shortcut

Hello all,
To transport v6 traffic over v4 only islands , is it feasible to advertise
v4 tunnels between the edges of the v4 island into v6 igp as shortcuts and
use them. This could be an alternative to the 6PE mechanism wherever
appropriate. 

Regards,
Vijay
DISCLAIMER 
This message and any attachment(s) contained here are information that is confidential, proprietary to
HCL Technologies 
and its customers. Contents may be privileged or otherwise protected by law. The information is solely
intended for the 
individual or the entity it is addressed to. If you are not the intended recipient of this message, you are
not authorized to 
read, forward, print, retain, copy or disseminate this message or any part of it. If you have received this
e-mail in error, 
please notify the sender immediately by return e-mail and delete it from your computer

_______________________________________________
mpls mailing list
mpls <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls

George Swallow | 5 Oct 23:17 2005
Picon

One week last-last call on LSP Ping

Folks -

In response to the GEN-ART review and also correcting a few errors I've
made some changes to LSP Ping that need wg approval

The changes are summarized at the begining of draft-10.  This begins a
one week last call on draft-ietf-mpls-lsp-ping-10.txt.

Comments are limited to the changes.

Last call ends 2400 UTC 10/12/2005.

...George

========================================================================
George Swallow             Cisco Systems                  (978) 936-1398
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719

_______________________________________________
mpls mailing list
mpls <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls

xuxiaohu 41208 | 6 Oct 09:28 2005

Bidirectional RSVP-TE tunnel

Dear members of the mpls distribution list: 

Virtual router technology provides a easy and flexible procedure to implement L3VPN. But as GRE/IPsec
tunnel has no properties such as TE, QoS and fast convergence features, the L3VPN implemented on
GRE/IPsec tunnel is not popular with service providers. 

RSVP-TE is very suitable to provide MPLS VPN service with the requirement of high availability and QoS
assurance because it consists of many good features such as TE, QoS and fast convergence. As RSVP-TE
tunnel is unidirectional, it can not be used to implement L3VPN through virtual router technology as GRE
tunnel. 

Through the binding of two unidirectional RSVP-TE tunnels established between a pair of LSRs destined to
each other, a bidirectional RSVP-TE tunnel is formed. Like GRE/IPsec tunnel, the bidirectional RSVP-TE
tunnel can be used to establish L3VPN with virtual router. In contrast to BGP/MPLS VPN defined in
[RFC2547bis], multicast is easier to be implemented and multicast traffics can travel in RSVP-TE tunnel
with such L3VPN. This L3VPN fully 
inherits the property of RSVP-TE, such as TE, QoS and fast convergence features. In addition, the
bidirectional RSVP-TE tunnel has many other purposes, such as interconnection of two separate routing
domains through a RSVP-TE tunnel and implementing LDP over TE. 

The decision factors of RSVP-TE tunnel binding include tunnel source address, tunnel destination
address and binding key. The reason for making binding key as one of the decision factors is that a LSR can
setup different RSVP-TE tunnels with the same pair of tunnel source address and tunnel destination
address, but these tunnel interfaces must be configured with different binding keys. 

Any comment is welcomed! 

Best regards! 

Steven Joe 

Huawei Technology Co.,Ltd. 

xuxh <at> huawei.com 

Attachment (x41208.vcf): text/x-vcard, 90 bytes
_______________________________________________
mpls mailing list
mpls <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls

Gmane