From mpls-bounces@lists.ietf.org Sun Oct 02 10:33:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EM4uM-0005HT-Bu; Sun, 02 Oct 2005 10:33:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EM4uJ-0005GG-L0 for mpls@megatron.ietf.org; Sun, 02 Oct 2005 10:33:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18461 for ; Sun, 2 Oct 2005 10:33:37 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EM52Z-0002KW-KS for mpls@ietf.org; Sun, 02 Oct 2005 10:42:13 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 02 Oct 2005 10:33:29 -0400 X-IronPort-AV: i="3.97,164,1125892800"; d="scan'208"; a="72622117:sNHT22179844" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j92EXQQl024319; Sun, 2 Oct 2005 10:33:26 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 2 Oct 2005 10:33:26 -0400 Received: from swallow-mini-mac.local ([10.86.240.246]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 2 Oct 2005 10:33:25 -0400 Received: from cisco.com (localhost [127.0.0.1]) by swallow-mini-mac.local (Postfix) with ESMTP id 2AFC1140B0B; Sun, 2 Oct 2005 10:31:13 -0400 (EDT) To: Fred Baker Subject: Re: [mpls] MPLS 2005 Conference In-reply-to: Your message of "Sun, 02 Oct 2005 07:18:29 +0430." <082C0844-2705-4201-82D7-A1A330D1DB32@cisco.com> From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1-RC3; GNU Emacs 21.2.1 Date: Sun, 02 Oct 2005 10:31:13 -0400 Message-Id: <20051002143113.2AFC1140B0B@swallow-mini-mac.local> X-OriginalArrivalTime: 02 Oct 2005 14:33:25.0776 (UTC) FILETIME=[3F98D100:01C5C75E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: fenner@research.att.com, mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org 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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Sun Oct 02 19:01:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMCq1-0007EU-C5; Sun, 02 Oct 2005 19:01:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMCpz-0007EP-Q6 for mpls@megatron.ietf.org; Sun, 02 Oct 2005 19:01:43 -0400 Received: from smtpoutuk02.marconi.com (smtpoutuk02.marconi.com [128.87.251.113]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07646 for ; Sun, 2 Oct 2005 19:01:40 -0400 (EDT) Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpoutuk02.marconi.com (8.12.11/8.12.11) with ESMTP id j92N0vPP006674 for ; Mon, 3 Oct 2005 00:01:03 +0100 (envelope-from Ingo.Krueger@marconi.com) From: "Ingo Krueger" To: "mpls" Message-ID: Date: Mon, 3 Oct 2005 01:01:05 +0200 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(5012HF354 | August 26, 2003) at 03/10/2005 00:01:05 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Cc: Subject: [mpls] Ingo Krueger/MAIN/MC1 not in the Office this Week X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Ich werde ab 01.10.2005 nicht im B=FCro sein. Ich kehre zur=FCck am 08.10.2005. Hello, I'm not in the office. I'll be back on 10.10.2005 Kind regards Ingo Kr=FCger = _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Oct 03 10:36:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMRQn-0004Ob-DF; Mon, 03 Oct 2005 10:36:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMLP7-0008BH-Vz; Mon, 03 Oct 2005 04:10:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09928; Mon, 3 Oct 2005 04:10:31 -0400 (EDT) Received: from rodin.i2r.a-star.edu.sg ([192.122.139.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMLXU-00079S-NJ; Mon, 03 Oct 2005 04:19:16 -0400 Received: from rodin.i2r.a-star.edu.sg (localhost [127.0.0.1]) by rodin.i2r.a-star.edu.sg (8.13.1/8.13.1) with ESMTP id j938AFiR029819; Mon, 3 Oct 2005 16:10:15 +0800 (SGT) Received: from newmailhost.i2r.a-star.edu.sg ([192.122.134.76])by rodin.i2r.a-star.edu.sg (8.13.1/8.13.1) with ESMTP id j938AC4J029765; Mon, 3 Oct 2005 16:10:13 +0800 (SGT) Received: from bearty ([192.168.152.97])by mailhost.lit.org.sg (Sun Java System Messaging Server 6.1 HotFix 0.06(built Nov 11 2004)) with SMTP id <0INR001ZNYOOMSB0@mailhost.lit.org.sg>; Mon,03 Oct 2005 16:10:00 +0800 (SGT) Date: Mon, 03 Oct 2005 16:33:25 +0800 From: Boon Sain Yeo To: Message-id: <024401c5c7f5$1f36d7d0$6198a8c0@bearty> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-Priority: 3 X-MSMail-priority: Normal X-imss-version: 2.031 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:5 C:4 M:4 S:4 R:4 (1.5000 1.5000) X-Spam-Score: 0.5 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 X-Mailman-Approved-At: Mon, 03 Oct 2005 10:36:39 -0400 Cc: Subject: [mpls] CFP - SensorWare 2006 (deadline extended) X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0757177317==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0757177317== Content-type: multipart/alternative; boundary="Boundary_(ID_ym05HW4gMhgnJlDYqaaqaQ)" This is a multi-part message in MIME format. --Boundary_(ID_ym05HW4gMhgnJlDYqaaqaQ) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT (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@rit.edu), RIT, USA Boon Sain Yeo (boonyeo@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@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 --Boundary_(ID_ym05HW4gMhgnJlDYqaaqaQ) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
(My apologies if you receive multiple = copies of=20 this message)
 
***********************************************************
1= st=20 International Workshop on Software for Sensor Networks (SensorWare) =96=20 CFP
***********************************************************
&nb= sp;
 
Welcome to the 1st International = Workshop on=20 Software for Sensor Networks (SensorWare) to be held on the 8 January = 2006. The=20 workshop is held in conjunction with COMSWARE 2006 in the beautiful and=20 historical city of New Delhi.
 
 
Advances in technology have made = deployment of=20 miniature sensors a realistic proposition. These sensors are low-power,=20 inexpensive, smart devices with multiple on-board sensors, and are = connected=20 through wireless links, so as to form a collaborative sensor network to = perform=20 a specific task. As a result, it opens up a new paradigm of ubiquitous = computing=20 and enables a range of applications that are previously unrealizable or = too=20 costly to be realized. However, given the limitation of on-board = hardware, one=20 of the key areas towards achieving superior performance is through the = software=20 implementation. The workshop is intended for the presentation and = discussion of=20 novel algorithms and software implementation for sensor networks. This = workshop,=20 intends to bring together engineering experts and academicians to = discuss the=20 current status, technical challenges, standards, fundamental issues, and = future=20 services and applications in the form of panels and technical=20 presentation.
 
 
 
Topics of interest include but are not = limited to=20 the following:
 
 
 
Operating System
Efficient = algorithms=20
Protocol design
Performance analysis
Performance related = issues=20
Sensor applications
Deployment issues and scenarios =
Middleware=20
Sensor security
Sensor network design and=20 modeling 
 
 
Workshop co-chairs:
 
Nirmala Shenoy (ns@rit.edu), RIT, USA
Boon Sain Yeo = (boonyeo@ieee.org), Institute for = Infocomm=20 Research, Singapore
 
 
 
TPC Members:
 
Holger Karl, University of Paderborn,=20 Germany,
Ling-Jyh Chen, Academia Sinica, Taiwan
Kui Wu, University = of=20 Victoria, Canada,
Daeyoung Kim, ICU, Korea
Leonard Barolli, = Fukuoka=20 Institute of Technology, Japan,
Wei-Peng, Fujitsu Labs of America,=20 USA
Jason Redi, BBN Technologies, USA      =
Biao=20 Chen, Syracuse University, USA
Hairong  Qi, University of = Tennessee,=20 USA
Xiaojun Cao, Rochester Institute of Technology, USA
Xin Wang,=20 University of Buffalo, USA
James Minseok Kwon, RIT, USA
Wenye = Wang, North=20 Carolina State University, USA
Fei Hu, RIT, USA
Robin Chellappa, = Deakin=20 Univeristy, Australia 
 
Technical Papers has to be submitted to = the=20 co-chairs at boonyeo@ieee.org.=20
 
Papers should be written in English and = should=20 preferably follow the instructions in template.pdf. Preferred maximum = paper=20 length is 6 printed pages (10-point font) including = figures.
 

Important Dates:
 
Paper Submission Deadline: = 14 October=20 2005
Notification Acceptance/Rejection: 14 November = 2005
Final=20 Camera-Ready Paper Submission: 2 December 2005
 
Please visit the workshop website at http://www.sensorware.org for = more=20 info.
 
We look forward to seeing you at=20 SensorWare.
 
Many thanks
Best = regards,
 
Boon and Nirmala
Workshop=20 co-chairs
--Boundary_(ID_ym05HW4gMhgnJlDYqaaqaQ)-- --===============0757177317== 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 --===============0757177317==-- From mpls-bounces@lists.ietf.org Mon Oct 03 15:50:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMWK4-0002KQ-S9; Mon, 03 Oct 2005 15:50:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMWK2-0002Iu-Bs for mpls@megatron.ietf.org; Mon, 03 Oct 2005 15:50:02 -0400 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27884 for ; Mon, 3 Oct 2005 15:50:00 -0400 (EDT) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EMWK2-0006KB-1B; Mon, 03 Oct 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 03 Oct 2005 15:50:02 -0400 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-lsp-ping-10.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org 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 : 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@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@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. --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: <2005-10-3115617.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lsp-ping-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lsp-ping-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-3115617.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 Tue Oct 04 15:50:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMsnj-00012j-4Q; Tue, 04 Oct 2005 15:50:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMsna-00010D-RB for mpls@megatron.ietf.org; Tue, 04 Oct 2005 15:50:04 -0400 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21243 for ; Tue, 4 Oct 2005 15:50:00 -0400 (EDT) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EMsnZ-0006u4-TY; Tue, 04 Oct 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 04 Oct 2005 15:50:01 -0400 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-ldp-survey2002-00.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org 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 : 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@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@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. --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: <2005-10-4150855.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ldp-survey2002-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ldp-survey2002-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-4150855.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 Wed Oct 05 02:07:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN2Qr-00016r-22; Wed, 05 Oct 2005 02:07:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN2Qp-00016i-Bn; Wed, 05 Oct 2005 02:07:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08026; Wed, 5 Oct 2005 02:07:07 -0400 (EDT) Received: from rose.ctd.hcltech.com ([202.54.64.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN2Zb-0007ul-AZ; Wed, 05 Oct 2005 02:16:16 -0400 X-MessageTextProcessor: DisclaimIt (2.50.252) [HCL Technologies Limited] Content-Class: urn:content-classes:message Received: from Ganesh.ctd.hcltech.com ([202.54.64.2]) by rose.ctd.hcltech.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 5 Oct 2005 11:36:53 +0530 Received: by Ganesh.ctd.hcltech.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Oct 2005 11:36:53 +0530 Message-ID: <86094352DBA45B4E8575CE0748C16A6B1B59FB@Haritha.ctd.hcltech.com> From: "Vijayanand C - CTD, Chennai." To: , Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Oct 2005 11:36:52 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 05 Oct 2005 06:06:53.0496 (UTC) FILETIME=[FBA02B80:01C5C972] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Cc: Subject: [mpls] v6 over v4 using igp shortcut X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org 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.=20 Regards, Vijay DISCLAIMER=20 This message and any attachment(s) contained here are information that = is confidential, proprietary to HCL Technologies=20 and its customers. Contents may be privileged or otherwise protected by = law. The information is solely intended for the=20 individual or the entity it is addressed to. If you are not the intended = recipient of this message, you are not authorized to=20 read, forward, print, retain, copy or disseminate this message or any = part of it. If you have received this e-mail in error,=20 please notify the sender immediately by return e-mail and delete it from = your computer _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Oct 05 17:17:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENGe4-0007S6-Oo; Wed, 05 Oct 2005 17:17:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENGe2-0007RD-Mk for mpls@megatron.ietf.org; Wed, 05 Oct 2005 17:17:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29815 for ; Wed, 5 Oct 2005 17:17:43 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENGmz-0004cf-6o for mpls@ietf.org; Wed, 05 Oct 2005 17:27:01 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 05 Oct 2005 14:17:35 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j95LGF4t011485; Wed, 5 Oct 2005 14:17:33 -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.211); Wed, 5 Oct 2005 17:17:28 -0400 Received: from swallow-mini-mac.local ([10.86.242.222]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Oct 2005 17:17:27 -0400 Received: from cisco.com (localhost [127.0.0.1]) by swallow-mini-mac.local (Postfix) with ESMTP id AE4CB1478B0; Wed, 5 Oct 2005 17:17:21 -0400 (EDT) To: mpls@ietf.org From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1-RC3; GNU Emacs 21.2.1 Date: Wed, 05 Oct 2005 17:17:21 -0400 Message-Id: <20051005211721.AE4CB1478B0@swallow-mini-mac.local> X-OriginalArrivalTime: 05 Oct 2005 21:17:27.0633 (UTC) FILETIME=[301BE410:01C5C9F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [mpls] One week last-last call on LSP Ping X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org 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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Oct 06 03:29:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENQBu-0001nY-8R; Thu, 06 Oct 2005 03:29:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENQBr-0001nT-Sm for mpls@megatron.ietf.org; Thu, 06 Oct 2005 03:29:19 -0400 Received: from huawei.com (usaga01-in.huawei.com [12.129.211.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13480 for ; Thu, 6 Oct 2005 03:29:17 -0400 (EDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0INX00FUXGMI4B@usaga01-in.huawei.com> for mpls@lists.ietf.org; Thu, 06 Oct 2005 00:25:30 -0700 (PDT) Received: from huawei.com ([172.17.1.218]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0INX00I0RGMHAT@usaga01-in.huawei.com> for mpls@lists.ietf.org; Thu, 06 Oct 2005 00:25:30 -0700 (PDT) Received: from [172.24.1.3] (Forwarded-For: [219.236.72.253]) by szxmc02-in.huawei.com (mshttpd); Thu, 06 Oct 2005 15:28:55 +0800 Date: Thu, 06 Oct 2005 15:28:55 +0800 From: xuxiaohu 41208 To: mpls@ietf.org Message-id: <4ef7d54eec31.4eec314ef7d5@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: multipart/mixed; boundary="Boundary_(ID_A5HjD11spUbADOCKABFlxg)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal Cc: Subject: [mpls] Bidirectional RSVP-TE tunnel X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --Boundary_(ID_A5HjD11spUbADOCKABFlxg) Content-type: text/plain; charset=us-ascii Content-disposition: inline Content-Transfer-Encoding: 7BIT 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@huawei.com --Boundary_(ID_A5HjD11spUbADOCKABFlxg) Content-type: text/x-vcard; name=x41208.vcf; charset=gb2312 Content-disposition: attachment; filename=x41208.vcf Content-description: Card for xuxiaohu 41208 Content-Transfer-Encoding: 7BIT begin:vcard n:;xuxiaohu fn:xuxiaohu version:2.1 email;internet:xuxh@huawei.com end:vcard --Boundary_(ID_A5HjD11spUbADOCKABFlxg) 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 --Boundary_(ID_A5HjD11spUbADOCKABFlxg)-- From mpls-bounces@lists.ietf.org Thu Oct 06 03:54:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENQZl-00010c-W1; Thu, 06 Oct 2005 03:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENQZk-00010X-B0 for mpls@megatron.ietf.org; Thu, 06 Oct 2005 03:54:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15434 for ; Thu, 6 Oct 2005 03:53:58 -0400 (EDT) From: richard.spencer@bt.com Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENQim-0002F4-Us for mpls@ietf.org; Thu, 06 Oct 2005 04:03:21 -0400 Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Oct 2005 08:53:45 +0100 Received: from I2KM11-UKBR.domain1.systemhost.net ([193.113.197.28]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 6 Oct 2005 08:53:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] Bidirectional RSVP-TE tunnel Date: Thu, 6 Oct 2005 08:53:44 +0100 Message-ID: Thread-Topic: [mpls] Bidirectional RSVP-TE tunnel Thread-Index: AcXKSC2p6886r24TQFucdKTnPyadNQAAISjQ To: , X-OriginalArrivalTime: 06 Oct 2005 07:53:45.0542 (UTC) FILETIME=[13EA7E60:01C5CA4B] X-Spam-Score: 0.3 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Steven, Before asking for more comments from another WG, wouldn't it be better = to first address the comments/questions raised by Robert Raszuk and = myself on the L3VPN mailing list? I think you will find that a significant number of people subscribe to = both mailing lists, and that the L3VPN mailing list is more appropriate = for your draft as it is focussed on L3VPNs. To make things easier, I have summarised the comments that have been = raised so far below. Regards, Richard ------------------------------------------- >From Robert Raszuk: >

Virtual router > technology provides a easy and flexible procedure to implement L3VPN. That's a pretty brave statement. Let me just point out that there are at least of couple of alternatives to provide L3VPNs a bit wider deployed then VR's based L3VPNs. > 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.

I am afraid that those are not the reasons for wider deployment of tunneling with MPLS then with GRE/IPSec :). Your observation is correct that if you require traffic to flow in both directions between VRs over unidirectional TE tunnels you may require a pair of those - I don't think a lot of people will argue with that. As far as QoS or convergence if you have correctly architected diff-serve in your network using TOS bits from GRE IP header or from MPLS EXP field should result in the same PHB. > In contrast to BGP/MPLS VPN defined in > [RFC2547bis], multicast is easier to be impl! emented and multicast > traffics can travel in RSVP-TE tunnel with such L3VPN. Would you care to elaborate on that point ? If possible could you list the data points and facts you base your opinion on ? Please include the comparison of replication efficiency and number of m-cast states in your response. > and more efficient method to meet the reqirement.

First, > GRE/IPsec tunnel have no multiplexor,if you want to establish many > tunnels between a pair of PEs, you must use different pairs of tunnel > source and destination address. Not true. In 2547 VPN label behind a GRE tunnel is the multiplexor and works just fine. >

Second, the efficiency of > encapsulation and de-encapsulation process of GRE/IPsec is not > desirable,especially in the case of fragmentation.=20 That depends on your hardware and is just an implementation detail. >

Third, although > the diff-serv model using TOS bits of GRE IP header or MPLS EXP > field can meet the requirement of QoS, the diff-serv enabled RSVP-TE > tunnel is more suitable for service providers to offer triply > services and VPN services in a single MPLS/IP network because of its > easiness for configuration and maintenance . DS-TE does not give you anythinng if your network is not full TE network, you have policing implemented on all ingress points as well as you can account for other theraffic types then just unicast ipv4 (for example multicast). AFAIK that set of requrements is rearly met in production. Keep in mind that TE is a contorl plane only tool ! >

For MVPN, from the aspect of replication efficiency, deploying > multicast in provider's network is prefered in the case of hub-spoke > network structure, but the requirement for P devices is high, and the > complexity and the amount of multicast states maintained for the data > MDT like solutions can not be ignored. Fair. Can you indicate the number of today's multicast states P routers can support as well as the number of states which is required ? I agree that SPs should have a way to bound the number of m-cast states in the P routers but there are already many ways to achive that even today. For example by seting proper threshold for MDT data trigger. > Beside, PE is more powerful > than P in today's provider networks, so I believe multicast > relication in unicast tunnel is more acceptable for service > providers. IMHO it is a waist of bandwith. If one's vendor P routers have issues in replication of MVPN groups for control/data MDT they equally may have problems for distribution of internet multicast flows and therefor it may be good idea not to use them as P routers. > As routing protocols such as OSPF and PIM can be run over > bidirectional RSVP-TE tunnel interfaces, so MVPN is easy to be > implemented and multicast traffices travelling in TE tunnel can > inherit all of the benifits of RSVP-TE tunnel, such as QoS and > FRR.

There is nothing to prevent one to put control/data MDTs into p2mp TE LSPs today. ---------------------------------------------- >From Richard Spencer: >

Third, although the diff-serv model using TOS bits of GRE IP header = > or MPLS EXP field can meet the requirement of QoS, the diff-serv = enabled=20 > RSVP-TE tunnel is more suitable for service providers to offer triply > services and VPN services in a single MPLS/IP network because of its > easiness for configuration and maintenance. I don't understand your logic here, you state that diffserv is adequate = to meet QoS requirements, but then go on to say that diffserv TE is more = suitable for triple play services because its easier to = configure/maintain. How can diffserv TE be easier to configure/maintain = than diffserv alone? Why is simplifying configuration/maintenance for = triple play service more important than for other services? Diffserv TE doesn't improve QoS, the forwarding behaviour in the data = plane is exactly the same. Instead, diffserv TE allows a provider to = reserve bandwidth (using backup TE tunnels) for higher priority traffic = to guarantee that if a failure occurs, there will still be enough = bandwidth for higher priority traffic. Depending on the amount of high = priority traffic being carried and the amount of spare capacity in the = network under normal load conditions (over provisioning), diffserv TE = may or may not be the best solution. As the amount of higher priority = traffic being carried increases, the more likely it is that diffserv TE = will be beneficial, although diffserv alone with multiple ECMP paths may = still be adequate.=20 I would argue that diffserv TE is much more difficult to = configure/maintain, not only do you need to configure diffserv, but you = need to setup the RSVP-TE tunnels and engineer backup tunnels in such a = way that when a failure occurs there is enough capacity in the network = to continue to forward the higher priority traffic. You also need to = configure policers and queue weights to police the bandwidth limits = signalled using RSVP-TE, whilst taking failures scenarios into account. To be clear, I'm not saying that diffserv TE isn't useful/important. My = point is that its not easier to configure/maintain than diffserv alone = and that it doesn't improve QoS. Instead, it offers the ability to = guarantee bandwidth for higher priority traffic classes under failure = conditions. > Beside, PE is more powerful than P in today's provider networks, A PE (edge) router is more powerful than a P (core) router with respect = to what? If this simplistic statement were true then why do we have core = routers at all, why not use edge routers in the core? Also, why are core = routers in general much more expensive than edge routers then? Obviously = your simplistic statement is incorrect, although it is true to say that = edge routers and core routers are designed to meet different = requirements and therefore are optimised to support different = features/functions. > so I believe multicast relication in unicast tunnel is more=20 > acceptable for service providers. Can you expand on your reasoning behind this? If replication at the edge = based on unicast tunnels was acceptable, then why do you think = vendors/providers spent time developing/deploying PIM/GRE IP VPN and = RSVP-TE P2MP solutions? Replication in the core may or may not be required depending on the = network topology, where the traffic source is located, and on the = bandwidth requirements of the multicast traffic being carried. However, = in most cases where multicast traffic is being carried edge-to-edge = across the core, such as in the VPN environment, I would say that = replication in the core is essential. > -----Original Message----- > From: mpls-bounces@lists.ietf.org=20 > [mailto:mpls-bounces@lists.ietf.org]On Behalf Of xuxiaohu 41208 > Sent: 06 October 2005 08:29 > To: mpls@ietf.org > Subject: [mpls] Bidirectional RSVP-TE tunnel >=20 >=20 > Dear members of the mpls distribution list:=20 >=20 > Virtual router technology provides a easy and flexible=20 > procedure to implement L3VPN. But as GRE/IPsec tunnel has no=20 > properties such as TE, QoS and fast convergence features, the=20 > L3VPN implemented on GRE/IPsec tunnel is not popular with=20 > service providers.=20 >=20 > RSVP-TE is very suitable to provide MPLS VPN service with the=20 > requirement of high availability and QoS assurance because it=20 > consists of many good features such as TE, QoS and fast=20 > convergence. As RSVP-TE tunnel is unidirectional, it can not=20 > be used to implement L3VPN through virtual router technology=20 > as GRE tunnel.=20 >=20 > Through the binding of two unidirectional RSVP-TE tunnels=20 > established between a pair of LSRs destined to each other, a=20 > bidirectional RSVP-TE tunnel is formed. Like GRE/IPsec=20 > tunnel, the bidirectional RSVP-TE tunnel can be used to=20 > establish L3VPN with virtual router. In contrast to BGP/MPLS=20 > VPN defined in [RFC2547bis], multicast is easier to be=20 > implemented and multicast traffics can travel in RSVP-TE=20 > tunnel with such L3VPN. This L3VPN fully=20 > inherits the property of RSVP-TE, such as TE, QoS and fast=20 > convergence features. In addition, the bidirectional RSVP-TE=20 > tunnel has many other purposes, such as interconnection of=20 > two separate routing domains through a RSVP-TE tunnel and=20 > implementing LDP over TE.=20 >=20 > The decision factors of RSVP-TE tunnel binding include tunnel=20 > source address, tunnel destination address and binding key.=20 > The reason for making binding key as one of the decision=20 > factors is that a LSR can setup different RSVP-TE tunnels=20 > with the same pair of tunnel source address and tunnel=20 > destination address, but these tunnel interfaces must be=20 > configured with different binding keys.=20 >=20 >=20 > Any comment is welcomed!=20 >=20 >=20 > Best regards!=20 >=20 >=20 >=20 > Steven Joe=20 >=20 > Huawei Technology Co.,Ltd.=20 >=20 > xuxh@huawei.com=20 > =20 > =20 >=20 >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Oct 06 06:14:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENSlZ-00065f-HH; Thu, 06 Oct 2005 06:14:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENSlW-000655-RO; Thu, 06 Oct 2005 06:14:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22273; Thu, 6 Oct 2005 06:14:15 -0400 (EDT) Received: from usaga01-in.huawei.com ([12.129.211.51] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENSuZ-00084P-9K; Thu, 06 Oct 2005 06:23:41 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0INX00FFFO9U4B@usaga01-in.huawei.com>; Thu, 06 Oct 2005 03:10:42 -0700 (PDT) Received: from huawei.com ([172.17.1.218]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0INX008YBO9RJT@usaga01-in.huawei.com>; Thu, 06 Oct 2005 03:10:42 -0700 (PDT) Received: from [172.24.1.3] (Forwarded-For: [219.236.72.253]) by szxmc02-in.huawei.com (mshttpd); Thu, 06 Oct 2005 18:14:04 +0800 Date: Thu, 06 Oct 2005 18:14:04 +0800 From: xuxiaohu 41208 Subject: Re: [mpls] Bidirectional RSVP-TE tunnel To: richard.spencer@bt.com, richard.spencer@bt.com, raszuk@cisco.com, raszuk@cisco.com Message-id: <4fb29c4fd1c6.4fd1c64fb29c@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: multipart/mixed; boundary="Boundary_(ID_r6b3hbt+j5c0xSfA2TsdFA)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Cc: mpls@ietf.org, l3vpn@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --Boundary_(ID_r6b3hbt+j5c0xSfA2TsdFA) Content-type: text/plain; charset=us-ascii Content-disposition: inline Content-Transfer-Encoding: 7BIT Dear Richard and Robert, Thank you very much for your attention and your professional comments. I will give my opinion from the following two aspects: First, I agree Robert's opinion that 2547bis VPN is more widely deployed. VR-based VPN is just another option of L3VPN using GRE, IP-IN-IP or IPsec tunnel as connection between VRs, and the above tunnel can also be encapsulated in TE tunnel in order to realize L3VPN with QoS and high availability features. Since bidirectional TE tunnel itself can do the function of the two protocols, why not make thing simple? Second, regarding multicast replication efficiency, replication on P routers should be prefered,especially in hub-spoke network topology. But from the aspects of protecting original investment and implementing complexity, it's not a good option. It's not easy to implement multicast replication according to demand based on per multicast group in MVPNs. In my opinion, the backbone is just a transport platform with adequent bandwidth, more and more potential and complicated functions/features such as MVPN should be more considered on PE or SR devices with minimum impact to P devices. Thanks for your comments once again. Best regards! Steven Joe Huawei Technologies Co.,Ltd. xuxh@huawei.com ----- Original Message ----- From: To: ; Sent: Thursday, October 06, 2005 3:53 PM Subject: RE: [mpls] Bidirectional RSVP-TE tunnel Steven, Before asking for more comments from another WG, wouldn't it be better to first address the comments/questions raised by Robert Raszuk and myself on the L3VPN mailing list? I think you will find that a significant number of people subscribe to both mailing lists, and that the L3VPN mailing list is more appropriate for your draft as it is focussed on L3VPNs. To make things easier, I have summarised the comments that have been raised so far below. Regards, Richard ------------------------------------------- >From Robert Raszuk: >

Virtual router > technology provides a easy and flexible procedure to implement L3VPN. That's a pretty brave statement. Let me just point out that there are at least of couple of alternatives to provide L3VPNs a bit wider deployed then VR's based L3VPNs. > 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.

I am afraid that those are not the reasons for wider deployment of tunneling with MPLS then with GRE/IPSec :). Your observation is correct that if you require traffic to flow in both directions between VRs over unidirectional TE tunnels you may require a pair of those - I don't think a lot of people will argue with that. As far as QoS or convergence if you have correctly architected diff-serve in your network using TOS bits from GRE IP header or from MPLS EXP field should result in the same PHB. > In contrast to BGP/MPLS VPN defined in > [RFC2547bis], multicast is easier to be impl! emented and multicast > traffics can travel in RSVP-TE tunnel with such L3VPN. Would you care to elaborate on that point ? If possible could you list the data points and facts you base your opinion on ? Please include the comparison of replication efficiency and number of m-cast states in your response. > and more efficient method to meet the reqirement.

First, > GRE/IPsec tunnel have no multiplexor,if you want to establish many > tunnels between a pair of PEs, you must use different pairs of tunnel > source and destination address. Not true. In 2547 VPN label behind a GRE tunnel is the multiplexor and works just fine. >

Second, the efficiency of > encapsulation and de-encapsulation process of GRE/IPsec is not > desirable,especially in the case of fragmentation. That depends on your hardware and is just an implementation detail. >

Third, although > the diff-serv model using TOS bits of GRE IP header or MPLS EXP > field can meet the requirement of QoS, the diff-serv enabled RSVP-TE > tunnel is more suitable for service providers to offer triply > services and VPN services in a single MPLS/IP network because of its > easiness for configuration and maintenance . DS-TE does not give you anythinng if your network is not full TE network, you have policing implemented on all ingress points as well as you can account for other theraffic types then just unicast ipv4 (for example multicast). AFAIK that set of requrements is rearly met in production. Keep in mind that TE is a contorl plane only tool ! >

For MVPN, from the aspect of replication efficiency, deploying > multicast in provider's network is prefered in the case of hub-spoke > network structure, but the requirement for P devices is high, and the > complexity and the amount of multicast states maintained for the data > MDT like solutions can not be ignored. Fair. Can you indicate the number of today's multicast states P routers can support as well as the number of states which is required ? I agree that SPs should have a way to bound the number of m-cast states in the P routers but there are already many ways to achive that even today. For example by seting proper threshold for MDT data trigger. > Beside, PE is more powerful > than P in today's provider networks, so I believe multicast > relication in unicast tunnel is more acceptable for service > providers. IMHO it is a waist of bandwith. If one's vendor P routers have issues in replication of MVPN groups for control/data MDT they equally may have problems for distribution of internet multicast flows and therefor it may be good idea not to use them as P routers. > As routing protocols such as OSPF and PIM can be run over > bidirectional RSVP-TE tunnel interfaces, so MVPN is easy to be > implemented and multicast traffices travelling in TE tunnel can > inherit all of the benifits of RSVP-TE tunnel, such as QoS and > FRR.

There is nothing to prevent one to put control/data MDTs into p2mp TE LSPs today. ---------------------------------------------- >From Richard Spencer: >

Third, although the diff-serv model using TOS bits of GRE IP header > or MPLS EXP field can meet the requirement of QoS, the diff-serv enabled > RSVP-TE tunnel is more suitable for service providers to offer triply > services and VPN services in a single MPLS/IP network because of its > easiness for configuration and maintenance. I don't understand your logic here, you state that diffserv is adequate to meet QoS requirements, but then go on to say that diffserv TE is more suitable for triple play services because its easier to configure/maintain. How can diffserv TE be easier to configure/maintain than diffserv alone? Why is simplifying configuration/maintenance for triple play service more important than for other services? Diffserv TE doesn't improve QoS, the forwarding behaviour in the data plane is exactly the same. Instead, diffserv TE allows a provider to reserve bandwidth (using backup TE tunnels) for higher priority traffic to guarantee that if a failure occurs, there will still be enough bandwidth for higher priority traffic. Depending on the amount of high priority traffic being carried and the amount of spare capacity in the network under normal load conditions (over provisioning), diffserv TE may or may not be the best solution. As the amount of higher priority traffic being carried increases, the more likely it is that diffserv TE will be beneficial, although diffserv alone with multiple ECMP paths may still be adequate. I would argue that diffserv TE is much more difficult to configure/maintain, not only do you need to configure diffserv, but you need to setup the RSVP-TE tunnels and engineer backup tunnels in such a way that when a failure occurs there is enough capacity in the network to continue to forward the higher priority traffic. You also need to configure policers and queue weights to police the bandwidth limits signalled using RSVP-TE, whilst tak ing failures scenarios into account. To be clear, I'm not saying that diffserv TE isn't useful/important. My point is that its not easier to configure/maintain than diffserv alone and that it doesn't improve QoS. Instead, it offers the ability to guarantee bandwidth for higher priority traffic classes under failure conditions. > Beside, PE is more powerful than P in today's provider networks, A PE (edge) router is more powerful than a P (core) router with respect to what? If this simplistic statement were true then why do we have core routers at all, why not use edge routers in the core? Also, why are core routers in general much more expensive than edge routers then? Obviously your simplistic statement is incorrect, although it is true to say that edge routers and core routers are designed to meet different requirements and the refore are optimised to support different features/functions. > so I believe multicast relication in unicast tunnel is more > acceptable for service providers. Can you expand on your reasoning behind this? If replication at the edge based on unicast tunnels was acceptable, then why do you think vendors/providers spent time developing/deploying PIM/GRE IP VPN and RSVP-TE P2MP solutions? Replication in the core may or may not be required depending on the network topology, where the traffic source is located, and on the bandwidth requirements of the multicast traffic being carried. However, in most cases where multicast traffic is being carried edge-to-edge across the core, such as in the VPN environment, I would say that replication in the core is essential. > -----Original Message----- > From: mpls-bounces@lists.ietf.org > [mailto:mpls-bounces@lists.ietf.org]On Behalf Of xuxiaohu 41208 > Sent: 06 October 2005 08:29 > To: mpls@ietf.org > Subject: [mpls] 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@huawei.com > > > > --Boundary_(ID_r6b3hbt+j5c0xSfA2TsdFA) Content-type: text/x-vcard; name=x41208.vcf; charset=gb2312 Content-disposition: attachment; filename=x41208.vcf Content-description: Card for xuxiaohu 41208 Content-Transfer-Encoding: 7BIT begin:vcard n:;xuxiaohu fn:xuxiaohu version:2.1 email;internet:xuxh@huawei.com end:vcard --Boundary_(ID_r6b3hbt+j5c0xSfA2TsdFA) 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 --Boundary_(ID_r6b3hbt+j5c0xSfA2TsdFA)-- From mpls-bounces@lists.ietf.org Thu Oct 06 09:38:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENVxN-0002xE-Bh; Thu, 06 Oct 2005 09:38:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENPTZ-0006Ao-US for mpls@megatron.ietf.org; Thu, 06 Oct 2005 02:43:34 -0400 Received: from huawei.com (usaga01-in.huawei.com [12.129.211.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11368 for ; Thu, 6 Oct 2005 02:43:32 -0400 (EDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0INX00F57EI84B@usaga01-in.huawei.com> for mpls@lists.ietf.org; Wed, 05 Oct 2005 23:39:45 -0700 (PDT) Received: from huawei.com ([172.17.1.218]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0INX00IIKEI7AT@usaga01-in.huawei.com> for mpls@lists.ietf.org; Wed, 05 Oct 2005 23:39:44 -0700 (PDT) Received: from [172.24.1.3] (Forwarded-For: [219.236.72.253]) by szxmc02-in.huawei.com (mshttpd); Thu, 06 Oct 2005 14:43:09 +0800 Date: Thu, 06 Oct 2005 14:43:09 +0800 From: xuxiaohu 41208 To: mpls@ietf.org Message-id: <4ef13a4efba6.4efba64ef13a@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: multipart/mixed; boundary="Boundary_(ID_qfAaGZWQITfGo74MPjyT6w)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal X-Mailman-Approved-At: Thu, 06 Oct 2005 09:38:43 -0400 Cc: Subject: [mpls] Bidirectional RSVP-TE tunnel X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --Boundary_(ID_qfAaGZWQITfGo74MPjyT6w) Content-type: text/plain; charset=us-ascii Content-disposition: inline Content-Transfer-Encoding: 7BIT Dear members of the mpls distribution list: I would like to introduce some ideas about Bidirectional RSVP-TE tunnel, any comments from you is welcomed. 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 Technologies Co.,Ltd. xuxh@huawei.com --Boundary_(ID_qfAaGZWQITfGo74MPjyT6w) Content-type: text/x-vcard; name=x41208.vcf; charset=gb2312 Content-disposition: attachment; filename=x41208.vcf Content-description: Card for xuxiaohu 41208 Content-Transfer-Encoding: 7BIT begin:vcard n:;xuxiaohu fn:xuxiaohu version:2.1 email;internet:xuxh@huawei.com end:vcard --Boundary_(ID_qfAaGZWQITfGo74MPjyT6w) 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 --Boundary_(ID_qfAaGZWQITfGo74MPjyT6w)-- From mpls-bounces@lists.ietf.org Thu Oct 06 17:22:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENdBu-0007MP-Hf; Thu, 06 Oct 2005 17:22:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENdBr-0007KN-2G for mpls@megatron.ietf.org; Thu, 06 Oct 2005 17:22:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17236 for ; Thu, 6 Oct 2005 17:22:07 -0400 (EDT) Received: from bgslc11.burtongroup.com ([63.99.125.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENdKz-0000sX-Ka for mpls@ietf.org; Thu, 06 Oct 2005 17:31:39 -0400 Received: bgslc11.burtongroup.com 63.99.125.13 from 216.151.229.244 216.151.229.244 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.2.0.050811 Date: Thu, 06 Oct 2005 17:21:51 -0400 From: Irwin Lazar To: Message-ID: Thread-Topic: MPLScon 2006 Call for Presentations Thread-Index: AcXKu/eANlXMXjavEdqPbQAKlZoW5A== Mime-version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: mpls-ops@mplsrc.com Subject: [mpls] MPLScon 2006 Call for Presentations X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0777125180==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0777125180== Content-type: multipart/alternative; boundary="B_3211464112_11028370" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3211464112_11028370 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit The Call for Presentations for MPLScon 2006 is now available at http://www.mplscon.com/speaker/submit_pres.html MPLScon 2006 takes place May 22-26 in New York City. Please see the above web site for additional details or contact me with any questions regarding speaking at the event. Irwin --B_3211464112_11028370 Content-type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable MPLScon 2006 Call for Presentations The C= all for Presentations for MPLScon 2006 is now available at http://www.mplscon.com/speaker/subm= it_pres.html

MPLScon 2006 takes place May 22-26 in New York City.  Please see the a= bove web site for additional details or contact me with any questions regard= ing speaking at the event.

Irwin
 --B_3211464112_11028370-- --===============0777125180== 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 --===============0777125180==-- From mpls-bounces@lists.ietf.org Fri Oct 07 04:35:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENnhO-0001YK-Dq; Fri, 07 Oct 2005 04:35:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENnhM-0001X7-4k for mpls@megatron.ietf.org; Fri, 07 Oct 2005 04:35:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04163 for ; Fri, 7 Oct 2005 04:35:21 -0400 (EDT) Received: from oberon.imc.kth.se ([193.10.152.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENnqb-0002p6-2u for mpls@ietf.org; Fri, 07 Oct 2005 04:44:58 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.13.1/8.13.1) with ESMTP id j978dmmK020096 for ; Fri, 7 Oct 2005 10:39:48 +0200 Received: from [127.0.0.1] ([172.16.2.209]) by mail1.imc.kth.se; Fri, 07 Oct 2005 10:33:24 +0200 Message-ID: <434632C5.8080801@pi.se> Date: Fri, 07 Oct 2005 10:33:09 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: Subject: [mpls] Internet-Drafts Submission Cutoff Dates for the 64th IETF Meeting in Vancouver, British Columbia, Canada] X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org WG, for your information. /Loa There are two (2) Internet-Draft cutoff dates for the 64th IETF Meeting in Vancouver, British Columbia, Canada: October 17th: Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions All initial Internet-Drafts (version -00) must be submitted by Monday, October 17th at 9:00 AM ET. As always, all initial submissions with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. The Secretariat would appreciate receiving WG Chair approval by Monday, October 10th at 9:00 AM ET. October 24th: Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (version -01 and higher) must be submitted by Monday, October 24th at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced until on or after Monday, November 7th at 9:00 AM ET, when Internet-Draft posting resumes. Please do not wait until the last minute to submit. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 64th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_64.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Sun Oct 09 08:35:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOaOu-0004dt-DK; Sun, 09 Oct 2005 08:35:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOaOs-0004dK-CH for mpls@megatron.ietf.org; Sun, 09 Oct 2005 08:35:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14135 for ; Sun, 9 Oct 2005 08:35:33 -0400 (EDT) Received: from oberon.imc.kth.se ([193.10.152.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOaYY-0002PO-Nq for mpls@ietf.org; Sun, 09 Oct 2005 08:45:36 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.13.1/8.13.1) with ESMTP id j99CYVhg015104 for ; Sun, 9 Oct 2005 14:34:31 +0200 Received: from [127.0.0.1] ([172.16.2.209]) by mail1.imc.kth.se; Fri, 07 Oct 2005 17:20:24 +0200 Message-ID: <43469228.7020804@pi.se> Date: Fri, 07 Oct 2005 17:20:08 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: Subject: [mpls] mpls working meeting in Vancouver - agenda slots X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Working group, it is time to start putting the agenda for Vancouver together. Please send request for agenda slots to the wg co-chairs. As usual we expect authors and/or editors of wg doc to report status, either directly at the meeting or through the wg co-chairs. /Loa and George -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Oct 11 16:01:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPQJC-0006Fn-K5; Tue, 11 Oct 2005 16:01:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPQJ9-0006FB-Jz for mpls@megatron.ietf.org; Tue, 11 Oct 2005 16:01:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28148 for ; Tue, 11 Oct 2005 16:01:04 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPQTH-0007SE-Oq for mpls@ietf.org; Tue, 11 Oct 2005 16:11:38 -0400 Received: from hsitaraman-pc.avici.com (hsitaraman-pc.avici.com [10.2.20.46]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id j9BK0gH1022233 for ; Tue, 11 Oct 2005 16:00:42 -0400 Message-Id: <5.1.0.14.2.20051011140919.026a3650@pop.avici.com> X-Sender: hsitaraman@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 11 Oct 2005 16:00:03 -0400 To: mpls@ietf.org From: Harish Sitaraman Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [mpls] TTL exception processing on P2MP LSPs X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi, How does TTL expiration on the MPLS header work for P2MP LSPs ? If the payload is IP, then the ICMP error message (such as time exceeded) is tagged and sent along the LSP towards the egress, which would then hopefully route the packet towards the source. For P2MP LSPs, wouldn't this packet be replicated across all the branches ? If so, the set of egress PEs that receive this packet might route this packet towards the source. Is this an understood behavior for P2MP ? This probably doesn't cause any issues at the ingress when it receives multiple similar ICMP error messages. I'm aware of the draft proposing P2MP extensions for LSP ping. If tools such as mtrace are used in IP multicast networks, will these work with P2MP LSPs ? Thanks Harish _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Oct 11 17:19:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPRX1-00042f-Vi; Tue, 11 Oct 2005 17:19:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPRX0-00042P-DH for mpls@megatron.ietf.org; Tue, 11 Oct 2005 17:19:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04857 for ; Tue, 11 Oct 2005 17:19:27 -0400 (EDT) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPRh9-00026U-Jk for mpls@ietf.org; Tue, 11 Oct 2005 17:30:01 -0400 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by astro.systems.pipex.net (Postfix) with ESMTP id C12F4E0000A8; Tue, 11 Oct 2005 22:19:07 +0100 (BST) Received: from Puppy ([217.158.132.228] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Oct 2005 22:19:06 +0100 Message-ID: <29ba01c5cea9$d3d23210$f2849ed9@Puppy> From: "Adrian Farrel" To: , "Harish Sitaraman" References: <5.1.0.14.2.20051011140919.026a3650@pop.avici.com> Subject: Re: [mpls] TTL exception processing on P2MP LSPs Date: Tue, 11 Oct 2005 22:09:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 11 Oct 2005 21:19:07.0517 (UTC) FILETIME=[6A1F7AD0:01C5CEA9] X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi Harish, > How does TTL expiration on the MPLS header work for P2MP LSPs ? If the > payload is IP, then the ICMP error message (such as time exceeded) is > tagged and sent along the LSP towards the egress, which would then > hopefully route the packet towards the source. For P2MP LSPs, wouldn't this > packet be replicated across all the branches ? If so, the set of egress PEs > that receive this packet might route this packet towards the source. Is > this an understood behavior for P2MP ? This probably doesn't cause any > issues at the ingress when it receives multiple similar ICMP error messages. Yup. RFC3032 suggests this technique for P2P LSPs where the detecting router cannot route the ICMP error message back to the source. What you say about P2MP LSPs is true. Applying this technique would cause an ICMP error message to be received by all destinations downstream of the detecting node, and this would result in multiple ICMP error messages being sent to the source in response to one failed data packet. I think that the main issue that arrises is that the ingress may be swamped in some cases. Any suggestions? > I'm aware of the draft proposing P2MP extensions for LSP ping. If tools > such as mtrace are used in IP multicast networks, will these work with P2MP > LSPs ? As far as I recall, mtrace actually operates using unicast addresses, and is initiated by an egress of the multicast IP flow. [I may be wrong here, it is a little while since I looked at this.] If what I say is correct, then the interactions with P2MP MPLS are limited because the mtrace packets will not use the P2MP LSP. OK looks like we need some thought on the interaction of mtrace with P2MP LSP ping. Ideas? Cheers, Adrian _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Oct 12 03:12:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPanG-0002c0-Oh; Wed, 12 Oct 2005 03:12:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPanE-0002bV-Qo for mpls@megatron.ietf.org; Wed, 12 Oct 2005 03:12:52 -0400 Received: from smtp3.clb.oleane.net (smtp3.clb.oleane.net [213.56.31.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01612 for ; Wed, 12 Oct 2005 03:12:49 -0400 (EDT) Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be forged)) (authenticated) by smtp3.clb.oleane.net with ESMTP id j9C7CEli029026 for ; Wed, 12 Oct 2005 09:12:17 +0200 Message-Id: <200510120712.j9C7CEli029026@smtp3.clb.oleane.net> From: "Chantal Ladouce" To: Date: Wed, 12 Oct 2005 09:12:08 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXO/EHi8GSuqvwzQgOB6zcKini6BA== Cc: Subject: [mpls] MPLS World Congress 2006 - Paris - France X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1978433316==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1978433316== Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01C5CF0D.07ABC7F0" This is a multi-part message in MIME format. ------=_NextPart_000_002D_01C5CF0D.07ABC7F0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit MPLS World Congress 2006 will stand in Paris next February 7 to 10. Particular attention is paid this year to the Ethernet Metro and WAN architectures and the relationship with MPLS networks. New sessions include Triple Play (with an emphasis on Video transport) and MPLS role in mobile networks. The agenda is available online at: http://www.upperside.fr/mpls2006/mplsworld2006intro.htm ------=_NextPart_000_002D_01C5CF0D.07ABC7F0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

MPLS World Congress 2006 will stand in = Paris next = February 7 to 10.

Particular attention is paid this year to the Ethernet Metro and WAN architectures and the relationship with MPLS = networks.
New sessions include Triple Play (with an emphasis on Video transport) = and MPLS role in mobile networks.

 

The agenda is available online = at:

http://www.upperside.fr/mpls2006/mplsworld2006intro.htm

 

------=_NextPart_000_002D_01C5CF0D.07ABC7F0-- --===============1978433316== 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 --===============1978433316==-- From mpls-bounces@lists.ietf.org Wed Oct 12 17:01:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPnjI-0006JH-Sg; Wed, 12 Oct 2005 17:01:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPnjH-0006JC-3C for mpls@megatron.ietf.org; Wed, 12 Oct 2005 17:01:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05389 for ; Wed, 12 Oct 2005 17:01:35 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPnte-00058m-Nq for mpls@ietf.org; Wed, 12 Oct 2005 17:12:23 -0400 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by galaxy.systems.pipex.net (Postfix) with ESMTP id 2C2F2E0000B2; Wed, 12 Oct 2005 22:01:23 +0100 (BST) Received: from Puppy ([217.158.132.178] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Oct 2005 21:51:29 +0100 Message-ID: <2d8e01c5cf6f$23dd6ac0$f2849ed9@Puppy> From: "Adrian Farrel" To: , "Loa Andersson" , "George Swallow" Date: Wed, 12 Oct 2005 21:53:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 12 Oct 2005 20:51:30.0517 (UTC) FILETIME=[B8E31850:01C5CF6E] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: 7bit Cc: "Thomas D. Nadeau" Subject: [mpls] Fw: I-D ACTION:draft-yasukawa-mpls-p2mp-oam-reqs-01.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi, We have produced an updated version of our P2MP OAM requirements I-D to address comments made on the list, in Paris, and in private emails. We would welcome further input on this I-D. We would also like to suggest to the chairs that this I-D is in scope for the WG and would be of value in advancing the charter item on P2MP MPLS-TE. We ask that they consider making it a WG draft. In summary the changes are: Section 4.1 Add paragraph to discuss scaling issues with using ping in probing mode for P2MP LSPs. Section 4.2 Clarify use of timeout while listening for ping response in diagnostic mode Section 4.3 Reword text about path characterization to make the meaning clearer, and add example. Section 4.6 Add text to explain that alarm aggregation takes place in two dimensions for P2MP LSPs. Section 4.8 Fixed goofed text Section 4.8 Add note about fault recovery. Section 4.9 Fix goofed text Section 4.11 Clarify requirement for understanding where traffic is branched. Cheers, Adrian ----- Original Message ----- From: To: Sent: Wednesday, October 12, 2005 8:50 PM Subject: I-D ACTION:draft-yasukawa-mpls-p2mp-oam-reqs-01.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : OAM Requirements for Point-to-Multipoint MPLS Networks > Author(s) : S. Yasukawa, et al. > Filename : draft-yasukawa-mpls-p2mp-oam-reqs-01.txt > Pages : 12 > Date : 2005-10-12 > > Multi-Protocol Label Switching (MPLS) has been extended to encompass > point-to-multipoint (P2MP) Label Switched Paths (LSPs). As with > point-to-point MPLS LSPs the requirement to detect, handle and > diagnose control and dataplane defects is critical. > > For operators deploying services based on P2MP MPLS LSPs the > detection and specification of how to handle those defects is > important because such defects may not only affect the fundamental > of an MPLS network, but also because they MAY impact service level > specification commitments for customers of their network. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-yasukawa-mpls-p2mp-oam-reqs-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-yasukawa-mpls-p2mp-oam-reqs-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-yasukawa-mpls-p2mp-oam-reqs-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 Thu Oct 13 18:50:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBtl-0007vO-DI; Thu, 13 Oct 2005 18:50:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBti-0007tv-2D for mpls@megatron.ietf.org; Thu, 13 Oct 2005 18:50:02 -0400 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24873 for ; Thu, 13 Oct 2005 18:49:57 -0400 (EDT) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EQBth-0007hN-LS; Thu, 13 Oct 2005 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 13 Oct 2005 18:50:01 -0400 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-lc-if-mib-07.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org 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 : Multiprotocol Label Switching (MPLS) Label-Controlled ATM and Frame-Relay Management Interface Definition Author(s) : T. Nadeau, S. Hegde Filename : draft-ietf-mpls-lc-if-mib-07.txt Pages : 22 Date : 2005-10-13 This memo defines two MIB modules and corresponding MIB Object Definitions that describe how label switching controlled Frame-Relay and ATM interfaces can be managed given the interface stacking as defined in the MPLS-LSR-STD-MIB and MPLS-TE-STD-MIB. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lc-if-mib-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-lc-if-mib-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-lc-if-mib-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-13162549.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lc-if-mib-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lc-if-mib-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-13162549.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 Tue Oct 18 09:45:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERrm7-000758-J1; Tue, 18 Oct 2005 09:45:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERrm5-00074u-TO for mpls@megatron.ietf.org; Tue, 18 Oct 2005 09:45:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00345 for ; Tue, 18 Oct 2005 09:44:58 -0400 (EDT) Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERrxc-0005Y4-Fw for mpls@ietf.org; Tue, 18 Oct 2005 09:57:01 -0400 Received: from [205.252.31.254] (helo=[205.252.31.254]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1ERrls-0003ot-Tf; Tue, 18 Oct 2005 15:44:55 +0200 Message-ID: <4354FC4E.6070105@pi.se> Date: Tue, 18 Oct 2005 15:44:46 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: Subject: [mpls] Consensus on making two drafts mpls wg documents? X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Working group, the authors of draft-rosen-mpls-multicast-encaps and draft-raggarwa-upstream-label has asked that these documents are adopted as working group documents. The working group chairs would like to see if there is a consensus for this. Please send your comments to the mailing list Oct 30th the latest. In this case we like to have comments from both those in favor and those opposed. /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Oct 18 11:20:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERtFy-0003Tx-Jc; Tue, 18 Oct 2005 11:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERtFw-0003TX-L4 for mpls@megatron.ietf.org; Tue, 18 Oct 2005 11:20:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09439 for ; Tue, 18 Oct 2005 11:19:52 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERtRQ-00014D-TB for mpls@ietf.org; Tue, 18 Oct 2005 11:31:57 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA08301; Tue, 18 Oct 2005 10:19:37 -0500 (CDT) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9IFJbJ22332; Tue, 18 Oct 2005 08:19:37 -0700 (PDT) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Oct 2005 08:18:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Consensus on making two drafts mpls wg documents? Date: Tue, 18 Oct 2005 08:18:51 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC836964E@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: [mpls] Consensus on making two drafts mpls wg documents? Thread-Index: AcXT6oksBHog6+K8TZiyl5VD0IXU5AADLGcQ From: "Drake, John E" To: "Loa Andersson" , X-OriginalArrivalTime: 18 Oct 2005 15:18:52.0801 (UTC) FILETIME=[3FA3CF10:01C5D3F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org absolutely > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.se] > Sent: Tuesday, October 18, 2005 6:45 AM > To: mpls@ietf.org > Subject: [mpls] Consensus on making two drafts mpls wg documents? >=20 >=20 > Working group, >=20 > the authors of draft-rosen-mpls-multicast-encaps and > draft-raggarwa-upstream-label has asked that these documents are > adopted as working group documents. >=20 > The working group chairs would like to see if there is a consensus > for this. Please send your comments to the mailing list Oct 30th the > latest. In this case we like to have comments from both those in > favor and those opposed. >=20 > /Loa >=20 > -- > Loa Andersson >=20 > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se >=20 > _______________________________________________ > 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 Tue Oct 18 11:23:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERtJb-0004qS-LX; Tue, 18 Oct 2005 11:23:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERtJa-0004qD-7b for mpls@megatron.ietf.org; Tue, 18 Oct 2005 11:23:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09792 for ; Tue, 18 Oct 2005 11:23:38 -0400 (EDT) From: jordan.britnell@bell.ca Received: from bellwfep4.bellnexxia.net ([207.236.237.110] helo=bellwfep4-srv.bellnexxia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERtV7-0001Bh-L4 for mpls@ietf.org; Tue, 18 Oct 2005 11:35:43 -0400 Received: from dm3cn8.bell.ca ([206.47.0.145]) by bellwfep4-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20051018152334.NHSI23597.bellwfep4-srv.bellnexxia.net@dm3cn8.bell.ca> for ; Tue, 18 Oct 2005 11:23:34 -0400 Received: from 142.182.84.162dm3cn8.bell.ca with ESMTP (Tumbleweed MMS SMTP Relay (MMS v5.0)); Tue, 18 Oct 2005 11:23:23 -0400 X-Server-Uuid: D4A4E604-913A-4A1B-8C07-2866D92AD410 Received: from TOROONDC915.bell.corp.bce.ca ([142.182.89.18]) by toroondc550.bell.corp.bce.ca with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Oct 2005 11:23:24 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [mpls] Consensus on making two drafts mpls wg documents? Date: Tue, 18 Oct 2005 11:23:23 -0400 Message-ID: <5BA2482D51EA8440B36B8329127619B803594FAF@Toroondc915.bell.corp.bce.ca> Thread-Topic: [mpls] Consensus on making two drafts mpls wg documents? thread-index: AcXT6oksBHog6+K8TZiyl5VD0IXU5AADLGcQAAAm80A= To: mpls@ietf.org X-OriginalArrivalTime: 18 Oct 2005 15:23:24.0027 (UTC) FILETIME=[E14D9CB0:01C5D3F7] X-WSS-ID: 6F4BCCE17599-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Sounds good to me. =20 Jordan Britnell, CCNA IP Technology Research BCE/Bell Canada (416) 215-3729 jordan.britnell@bell.ca -----Original Message----- From: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org] On Behalf Of Drake, John E Sent: October 18, 2005 11:19 AM To: Loa Andersson; mpls@ietf.org Subject: RE: [mpls] Consensus on making two drafts mpls wg documents? absolutely > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.se] > Sent: Tuesday, October 18, 2005 6:45 AM > To: mpls@ietf.org > Subject: [mpls] Consensus on making two drafts mpls wg documents? >=20 >=20 > Working group, >=20 > the authors of draft-rosen-mpls-multicast-encaps and > draft-raggarwa-upstream-label has asked that these documents are > adopted as working group documents. >=20 > The working group chairs would like to see if there is a consensus > for this. Please send your comments to the mailing list Oct 30th the > latest. In this case we like to have comments from both those in > favor and those opposed. >=20 > /Loa >=20 > -- > Loa Andersson >=20 > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se >=20 > _______________________________________________ > 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 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Oct 18 15:53:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERxX5-0007nO-1Y; Tue, 18 Oct 2005 15:53:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERxX2-0007n9-MW for mpls@megatron.ietf.org; Tue, 18 Oct 2005 15:53:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24797 for ; Tue, 18 Oct 2005 15:53:49 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERxic-0000Ko-JL for mpls@ietf.org; Tue, 18 Oct 2005 16:05:56 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 18 Oct 2005 12:53:46 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9IJqqvD028725; Tue, 18 Oct 2005 12:53:38 -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.211); Tue, 18 Oct 2005 15:53:37 -0400 Received: from 205-252-31-79.btnaccess.net ([10.86.242.226]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Oct 2005 15:53:36 -0400 Received: from cisco.com (localhost [127.0.0.1]) by 205-252-31-79.btnaccess.net (Postfix) with ESMTP id ADD281082B5; Tue, 18 Oct 2005 15:53:33 -0400 (EDT) To: Loa Andersson In-reply-to: Your message of "Tue, 18 Oct 2005 15:44:46 +0200." <4354FC4E.6070105@pi.se> From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1-RC3; GNU Emacs 21.2.1 Date: Tue, 18 Oct 2005 15:53:33 -0400 Message-Id: <20051018195333.ADD281082B5@205-252-31-79.btnaccess.net> X-OriginalArrivalTime: 18 Oct 2005 19:53:37.0238 (UTC) FILETIME=[A1214760:01C5D41D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: mpls@ietf.org Subject: [mpls] Re: Consensus on making two drafts mpls wg documents? X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org With chair hat off, Yes! ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Oct 20 03:13:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESUbq-0004UV-Aw; Thu, 20 Oct 2005 03:13:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESUbn-0004ME-HK for mpls@megatron.ietf.org; Thu, 20 Oct 2005 03:13:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20118 for ; Thu, 20 Oct 2005 03:12:53 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESUnh-0004oa-2C for mpls@ietf.org; Thu, 20 Oct 2005 03:25:21 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 09:13:01 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [mpls] Consensus on making two drafts mpls wg documents? Date: Thu, 20 Oct 2005 09:13:00 +0200 Message-ID: Thread-Topic: [mpls] Consensus on making two drafts mpls wg documents? Thread-Index: AcXT6ojw1czNkVSaRQ6H/kvr0ZzR3QBWpK2A From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Loa Andersson" , X-OriginalArrivalTime: 20 Oct 2005 07:13:01.0210 (UTC) FILETIME=[B4C387A0:01C5D545] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi Loa, all, This is a really relevant extension of the MPLS architecture with = applications such as=20 P2MP MPLS on LANs, Mulicast VPN aggregation and P2MP Hierarchy. Hence I'm strongly in favor. Regards, JL=20 > -----Message d'origine----- > De : mpls-bounces@lists.ietf.org=20 > [mailto:mpls-bounces@lists.ietf.org] De la part de Loa Andersson > Envoy=E9 : mardi 18 octobre 2005 15:45 > =C0 : mpls@ietf.org > Objet : [mpls] Consensus on making two drafts mpls wg documents? >=20 >=20 > Working group, >=20 > the authors of draft-rosen-mpls-multicast-encaps and=20 > draft-raggarwa-upstream-label has asked that these documents=20 > are adopted as working group documents. >=20 > The working group chairs would like to see if there is a=20 > consensus for this. Please send your comments to the mailing=20 > list Oct 30th the latest. In this case we like to have=20 > comments from both those in favor and those opposed. >=20 > /Loa >=20 > -- > Loa Andersson >=20 > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Oct 20 18:50:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESjEb-0006AE-3q; Thu, 20 Oct 2005 18:50:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESjEY-000693-JR for mpls@megatron.ietf.org; Thu, 20 Oct 2005 18:50:02 -0400 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20154 for ; Thu, 20 Oct 2005 18:49:52 -0400 (EDT) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ESjEY-00066o-01; Thu, 20 Oct 2005 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 20 Oct 2005 18:50:02 -0400 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-rfc3036bis-03.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org 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 : LDP Specification Author(s) : L. Andersson, et al. Filename : draft-ietf-mpls-rfc3036bis-03.txt Pages : 135 Date : 2005-10-20 The architecture for Multi Protocol Label Switching (MPLS) is described in RFC 3031 [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. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rfc3036bis-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-ietf-mpls-rfc3036bis-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-ietf-mpls-rfc3036bis-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. --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: <2005-10-20180344.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-rfc3036bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-rfc3036bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-20180344.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 Fri Oct 21 03:17:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESr9Q-0000YF-DK; Fri, 21 Oct 2005 03:17:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESr9N-0000Va-Is for mpls@megatron.ietf.org; Fri, 21 Oct 2005 03:17:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02740 for ; Fri, 21 Oct 2005 03:17:03 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESrLS-0004rq-PC for mpls@ietf.org; Fri, 21 Oct 2005 03:29:44 -0400 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 09:17:10 +0200 Received: from l-8613.rd.francetelecom.fr ([10.193.15.36]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 09:17:09 +0200 Subject: Re: [mpls] Consensus on making two drafts mpls wg documents? From: Thomas Morin To: Loa Andersson In-Reply-To: <4354FC4E.6070105@pi.se> References: <4354FC4E.6070105@pi.se> Content-Type: text/plain Organization: France Telecom R&D Date: Fri, 21 Oct 2005 09:17:17 +0200 Message-Id: <1129879037.23908.2.camel@wintermute> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2005 07:17:10.0056 (UTC) FILETIME=[73802A80:01C5D60F] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org I'm in favor. -Thomas Loa Andersson : > Working group, > > the authors of draft-rosen-mpls-multicast-encaps and > draft-raggarwa-upstream-label has asked that these documents are > adopted as working group documents. > > The working group chairs would like to see if there is a consensus > for this. Please send your comments to the mailing list Oct 30th the > latest. In this case we like to have comments from both those in > favor and those opposed. > > /Loa > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Oct 21 10:50:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESyDc-0002M5-RU; Fri, 21 Oct 2005 10:50:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESyDa-0002Kr-V0 for mpls@megatron.ietf.org; Fri, 21 Oct 2005 10:50:03 -0400 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25771 for ; Fri, 21 Oct 2005 10:49:51 -0400 (EDT) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ESyDa-0008El-05; Fri, 21 Oct 2005 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 21 Oct 2005 10:50:02 -0400 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-lc-if-mib-08.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org 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 : Multiprotocol Label Switching (MPLS) Label-Controlled ATM and Frame-Relay Management Interface Definition Author(s) : T. Nadeau, S. Hegde Filename : draft-ietf-mpls-lc-if-mib-08.txt Pages : 22 Date : 2005-10-21 This memo defines two MIB modules and corresponding MIB Object Definitions that describe how label switching controlled Frame-Relay and ATM interfaces can be managed given the interface stacking as defined in the MPLS-LSR-STD-MIB and MPLS-TE-STD-MIB. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lc-if-mib-08.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-lc-if-mib-08.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-lc-if-mib-08.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: <2005-10-21094812.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lc-if-mib-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lc-if-mib-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-21094812.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 Mon Oct 24 15:50:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU8Ka-0002so-PF; Mon, 24 Oct 2005 15:50:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU8KY-0002q8-Jw for mpls@megatron.ietf.org; Mon, 24 Oct 2005 15:50:02 -0400 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28547 for ; Mon, 24 Oct 2005 15:49:48 -0400 (EDT) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EU8KY-0002Ax-8B; Mon, 24 Oct 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 24 Oct 2005 15:50:02 -0400 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-ecmp-bcp-02.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org 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 : Avoiding Equal Cost Multipath Treatment in MPLS Networks Author(s) : G. Swallow, et al. Filename : draft-ietf-mpls-ecmp-bcp-02.txt Pages : 7 Date : 2005-10-24 This document describes the Equal Cost Multipath (ECMP) behavior of currently deployed MPLS networks and makes best practice recommendations for anyone defining an application to run over an MPLS network and wishes to avoid such treatment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ecmp-bcp-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-ecmp-bcp-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-ecmp-bcp-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-24124258.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ecmp-bcp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ecmp-bcp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-24124258.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 Tue Oct 25 19:01:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUXnY-0001lL-KI; Tue, 25 Oct 2005 19:01:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUXnX-0001l0-Bp for mpls@megatron.ietf.org; Tue, 25 Oct 2005 19:01:39 -0400 Received: from smtpoutuk02.marconi.com (smtpoutuk02.marconi.com [128.87.251.113]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23665 for ; Tue, 25 Oct 2005 19:01:22 -0400 (EDT) Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpoutuk02.marconi.com (8.12.11/8.12.11) with ESMTP id j9PN0wcp000774 for ; Wed, 26 Oct 2005 00:00:58 +0100 (envelope-from Ingo.Krueger@marconi.com) From: "Ingo Krueger" To: "mpls" Message-ID: Date: Wed, 26 Oct 2005 01:01:03 +0200 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(5012HF354 | August 26, 2003) at 26/10/2005 00:01:05 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Cc: Subject: [mpls] Ingo Krueger/MAIN/MC1 not in the Office this Week X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Ich werde ab 25.10.2005 nicht im B=FCro sein. Ich kehre zur=FCck am 02.11.2005. Hello, I'm not in the office. I'll be back on 02.11.2005 Kind regards Ingo Kr=FCger = _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Oct 26 06:21:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUiPo-00009W-LO; Wed, 26 Oct 2005 06:21:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUiPm-00006X-1J for mpls@megatron.ietf.org; Wed, 26 Oct 2005 06:21:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09621 for ; Wed, 26 Oct 2005 06:21:34 -0400 (EDT) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUict-0004N7-PN for mpls@ietf.org; Wed, 26 Oct 2005 06:35:25 -0400 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 39522E00033F; Wed, 26 Oct 2005 11:21:38 +0100 (BST) Received: from Puppy ([217.158.132.20] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 11:17:23 +0100 Message-ID: <027101c5da16$e1b61770$de849ed9@Puppy> From: "Adrian Farrel" To: Date: Wed, 26 Oct 2005 11:16:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 26 Oct 2005 10:17:24.0737 (UTC) FILETIME=[759E4710:01C5DA16] X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: Subject: [mpls] Fw: I-D ACTION:draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi, Just to draw your attention to this I-D. Since Paris we have added quite a lot of new text to describe three potential mechanisms for supporting multicast LDP traffic on multi-access links and over P2MP MPLS-TE tunnels. Out intention with this I-D is to generate some discussion about the issues surrounding this function. We are not, at this stage, recommending any one solution, but we do think that it would be valuable to discuss the pros and cons of the different solutions. Comments, as always, would be welcome. We have requested a slot on the agenda in Vancouver to highlight some of the issues and to open up the discussion. Thanks, Adrian ----- Original Message ----- From: To: Sent: Tuesday, October 25, 2005 11:50 PM Subject: I-D ACTION:draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Support of LDP Multicast Label Switched Paths > over Point-to-Multipoint Label Switched Path > Tunnels and on Multi-Access Links > Author(s) : S. Yasukawa, A. Farrel > Filename : draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt > Pages : 28 > Date : 2005-10-25 > > Multiprotocol Label Switching (MPLS) includes the facility to > provision point-to-multipoint (P2MP) Traffic Engineered (TE) Label > Switched Paths (LSPs) which can be used to construct P2MP tunnels > across MPLS networks. > > The Label Distribution Protocol (LDP) has also been extended to > support label distribution for multicast traffic by forming multicast > LSPs. > > When traffic for a user network is carried across a provider network, > it is common practice for the traffic to be placed in tunnels. This > document examines the requirements to carry multicast LDP traffic > across a provider network within P2MP MPLS tunnels, and introduces > solution models that meet those requirements. > > Note that the requirements and solutions discussed in this document > are also applicable to the use of multicast LDP on multi-access > networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Oct 26 15:50:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUrHg-0005F2-Uv; Wed, 26 Oct 2005 15:50:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUrHf-0005E8-8I for mpls@megatron.ietf.org; Wed, 26 Oct 2005 15:50:03 -0400 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17748 for ; Wed, 26 Oct 2005 15:49:47 -0400 (EDT) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUrHe-00070C-2C; Wed, 26 Oct 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 26 Oct 2005 15:50:02 -0400 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-lsr-self-test-06.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org 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 : Label Switching Router Self-Test Author(s) : G. Swallow, et al. Filename : draft-ietf-mpls-lsr-self-test-06.txt Pages : 14 Date : 2005-10-26 This document defines a means for a Label-Switching Router (LSR) to verify that its data plane is functioning for certain key Multi-Protocol Label Switching (MPLS) applications, including unicast forwarding and traffic engineering tunnels. A new Loopback FEC type is defined to allow an upstream neighbor to assist in the testing at very low cost. MPLS Verification Request and MPLS Verification Reply messages are defined to do the actual probing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-self-test-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-lsr-self-test-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-lsr-self-test-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: <2005-10-26105548.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lsr-self-test-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lsr-self-test-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-26105548.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 Thu Oct 27 15:50:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVDlR-0007hR-E2; Thu, 27 Oct 2005 15:50:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVDlD-0007aa-OW for mpls@megatron.ietf.org; Thu, 27 Oct 2005 15:50:05 -0400 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25283 for ; Thu, 27 Oct 2005 15:49:47 -0400 (EDT) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EVDlC-0006Q9-RV; Thu, 27 Oct 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 27 Oct 2005 15:50:02 -0400 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-rsvp-te-p2mp-03.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org 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-03.txt Pages : 51 Date : 2005-10-27 This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the setup 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-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-ietf-mpls-rsvp-te-p2mp-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-ietf-mpls-rsvp-te-p2mp-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. --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: <2005-10-27114330.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-rsvp-te-p2mp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-rsvp-te-p2mp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-27114330.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 Thu Oct 27 20:10:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVHpT-0000C2-4q; Thu, 27 Oct 2005 20:10:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVHpQ-000095-Iz for mpls@megatron.ietf.org; Thu, 27 Oct 2005 20:10:40 -0400 Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28865 for ; Thu, 27 Oct 2005 20:10:23 -0400 (EDT) Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9S096L16195; Thu, 27 Oct 2005 17:09:06 -0700 (PDT) Message-Id: <200510280009.j9S096L16195@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 27 Oct 2005 17:09:05 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 4201 on Link Bundling in MPLS Traffic Engineering (TE) X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4201 Title: Link Bundling in MPLS Traffic Engineering (TE) Author(s): K. Kompella, Y. Rekhter, L. Berger Status: Standards Track Date: October 2005 Mailbox: kireeti@juniper.net, yakov@juniper.net, lberger@movaz.com Pages: 12 Characters: 27033 Updates: 3471, 3472, 3473 I-D Tag: draft-ietf-mpls-bundle-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4201.txt For the purpose of Generalized Multi-Protocol Label Switching (GMPLS) signaling, in certain cases a combination of is not sufficient to unambiguously identify the appropriate resource used by a Label Switched Path (LSP). Such cases are handled by using the link bundling construct, which is described in this document. This document updates the interface identification TLVs, which are defined in the GMPLS Signaling Functional Description. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <051027170732.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4201 --OtherAccess Content-Type: Message/External-body; name="rfc4201.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <051027170732.RFC@RFC-EDITOR.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 Thu Oct 27 20:19:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVHxk-0002Qy-Or; Thu, 27 Oct 2005 20:19:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVHxj-0002Qf-5H for mpls@megatron.ietf.org; Thu, 27 Oct 2005 20:19:15 -0400 Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29885 for ; Thu, 27 Oct 2005 20:18:57 -0400 (EDT) Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9S0GNL18706; Thu, 27 Oct 2005 17:16:23 -0700 (PDT) Message-Id: <200510280016.j9S0GNL18706@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 27 Oct 2005 17:16:23 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 4206 on Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE) X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4206 Title: Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE) Author(s): K. Kompella, Y. Rekhter Status: Standards Track Date: October 2005 Mailbox: kireeti@juniper.net, yakov@juniper.net Pages: 14 Characters: 31965 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-lsp-hierarchy-08.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4206.txt To improve scalability of Generalized Multi-Protocol Label Switching (GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) by creating a hierarchy of such LSPs. A way to create such a hierarchy is by (a) a Label Switching Router (LSR) creating a Traffic Engineering Label Switched Path (TE LSP), (b) the LSR forming a forwarding adjacency (FA) out of that LSP (by advertising this LSP as a Traffic Engineering (TE) link into the same instance of ISIS/OSPF as the one that was used to create the LSP), (c) allowing other LSRs to use FAs for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct). This document describes the mechanisms to accomplish this. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <051027171505.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4206 --OtherAccess Content-Type: Message/External-body; name="rfc4206.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <051027171505.RFC@RFC-EDITOR.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 Mon Oct 31 09:09:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWaLu-0006uF-Vg; Mon, 31 Oct 2005 09:09:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWaLr-0006tt-Rg for mpls@megatron.ietf.org; Mon, 31 Oct 2005 09:09:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09897 for ; Mon, 31 Oct 2005 09:09:12 -0500 (EST) Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWaa3-0006eY-1w for mpls@ietf.org; Mon, 31 Oct 2005 09:24:12 -0500 Received: from gw.imc.kth.se ([193.10.152.67] helo=[172.16.2.217]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1EWaLe-00034T-K3 for mpls@ietf.org; Mon, 31 Oct 2005 15:09:20 +0100 Message-ID: <436624FC.2000805@pi.se> Date: Mon, 31 Oct 2005 15:06:52 +0100 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: Subject: [mpls] wg agenda for the Vancouver meeting X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org All, I've uploaded an agenda (for some value of agenda), to http://www3.ietf.org/proceedings/05nov/agenda/mpls.txt it is still extremely preliminary, and will be updated shortly. Please, if you requested a agenda slot, check that your request has been addressed. /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Oct 31 13:53:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWemC-0007zJ-38; Mon, 31 Oct 2005 13:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWem8-0007yc-Su for mpls@megatron.ietf.org; Mon, 31 Oct 2005 13:52:57 -0500 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28013 for ; Mon, 31 Oct 2005 13:52:37 -0500 (EST) Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EWem8-0004lO-9A; Mon, 31 Oct 2005 13:52:56 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 31 Oct 2005 13:52:56 -0500 Cc: mpls mailing list , Internet Architecture Board , RFC Editor Subject: [mpls] Protocol Action: 'Multiprotocol Label Switching (MPLS) Label-Controlled ATM and Frame-Relay Management Interface Definition' to Proposed Standard X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org The IESG has approved the following document: - 'Multiprotocol Label Switching (MPLS) Label-Controlled ATM and Frame-Relay Management Interface Definition ' as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lc-if-mib-08.txt Technical Summary This memo defines two MIB modules and corresponding MIB Object Definitions that describe how label switching controlled Frame-Relay and ATM interfaces can be managed given the interface stacking as defined in the MPLS-LSR-STD-MIB and MPLS-TE-STD-MIB. Working Group Summary There was consensus within the WG to progress this document. Protocol Quality Alex Zinin and Bert Wijnen reviewed the document for the IESG. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls