From mailman-bounces@ietf.org Mon Nov 1 05:24:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12133 for ; Mon, 1 Nov 2004 05:24:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COZbf-0003bP-Px for mpls-archive@ietf.org; Mon, 01 Nov 2004 05:40:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COZ3s-0006m4-1r for mpls-archive@ietf.org; Mon, 01 Nov 2004 05:05:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: lists.ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: mpls-archive@ietf.org X-No-Archive: yes Message-ID: Date: Mon, 01 Nov 2004 05:02:19 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your lists.ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@lists.ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@lists.ietf.org. Thanks! Passwords for mpls-archive@ietf.org: List Password // URL ---- -------- mpls@lists.ietf.org duubek https://www1.ietf.org/mailman/options/mpls/mpls-archive%40ietf.org From mpls-bounces@ietf.org Mon Nov 1 11:53:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01989; Mon, 1 Nov 2004 11:53:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COffz-0003yy-2V; Mon, 01 Nov 2004 12:09:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COf3Q-0006lg-Cf; Mon, 01 Nov 2004 11:29:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COeXd-0001cW-7F for mpls@megatron.ietf.org; Mon, 01 Nov 2004 10:56:21 -0500 Received: from oberon.imc.kth.se (oberon.imc.kth.se [193.10.152.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24234 for ; Mon, 1 Nov 2004 10:56:19 -0500 (EST) Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.11.6/8.11.6) with ESMTP id iA1Fofr29946 for ; Mon, 1 Nov 2004 16:50:41 +0100 Received: from [127.0.0.1] ([172.16.2.190]) by mail1.imc.kth.se; Mon, 01 Nov 2004 16:56:01 +0100 Message-ID: <41865C8F.8080505@pi.se> Date: Mon, 01 Nov 2004 16:55:59 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org, Alex Zinin , Bill Fenner , George Swallow , Internet-Drafts Administrator Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [mpls] draft-allan-nadeau-mpls-oam-frmwk-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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit All, I've asked the authors of this document to publish it as a wg document, regrettably I waited so long that they couldn't make the cut off date. The document will be published after the meeting in Washington as draft-ietf-mpls-oam-frmwk-00.txt, till then it will for all practical purposes be treated as a wg doc. /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@ietf.org Mon Nov 1 12:33:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07129; Mon, 1 Nov 2004 12:33:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COgIK-0005C8-2w; Mon, 01 Nov 2004 12:48:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COfjU-0003Pl-Lf; Mon, 01 Nov 2004 12:12:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COfTQ-00038U-RH; Mon, 01 Nov 2004 11:56:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02270; Mon, 1 Nov 2004 11:56:03 -0500 (EST) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COfiN-00042W-2l; Mon, 01 Nov 2004 12:11:31 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id iA1GtNK4004265; Mon, 1 Nov 2004 11:55:23 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA05919; Mon, 1 Nov 2004 11:55:23 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Mon, 1 Nov 2004 11:55:22 -0500 Message-ID: <5551AD75D2C0BC459A85A2CEFAE4F8001C6088@usvissfp01.win.marconi.com> From: "Shmunis, Gregory" To: "'Loa Andersson'" , mpls@ietf.org, Alex Zinin , Bill Fenner , George Swallow , Internet-Drafts Administrator Subject: RE: [mpls] draft-allan-nadeau-mpls-oam-frmwk-00.txt Date: Mon, 1 Nov 2004 11:55:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Please take a notice. Greg. -----Original Message----- From: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org]On Behalf Of Loa Andersson Sent: Monday, November 01, 2004 10:56 AM To: mpls@ietf.org; Alex Zinin; Bill Fenner; George Swallow; Internet-Drafts Administrator Subject: [mpls] draft-allan-nadeau-mpls-oam-frmwk-00.txt All, I've asked the authors of this document to publish it as a wg document, regrettably I waited so long that they couldn't make the cut off date. The document will be published after the meeting in Washington as draft-ietf-mpls-oam-frmwk-00.txt, till then it will for all practical purposes be treated as a wg doc. /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 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Nov 1 13:10:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11842; Mon, 1 Nov 2004 13:10:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COgs2-0006XF-KN; Mon, 01 Nov 2004 13:25:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COg6L-0001lI-Fo; Mon, 01 Nov 2004 12:36:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COfoa-0005QG-AN for mpls@megatron.ietf.org; Mon, 01 Nov 2004 12:17:56 -0500 Received: from oberon.imc.kth.se (oberon.imc.kth.se [193.10.152.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05446 for ; Mon, 1 Nov 2004 12:17:53 -0500 (EST) Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.11.6/8.11.6) with ESMTP id iA1HCGr31379 for ; Mon, 1 Nov 2004 18:12:16 +0100 Received: from [127.0.0.1] ([172.16.2.190]) by mail1.imc.kth.se; Mon, 01 Nov 2004 18:17:33 +0100 Message-ID: <41866FAA.6040702@pi.se> Date: Mon, 01 Nov 2004 18:17:30 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [mpls] agenda for MPLS meeting in Washington DC 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit All, please find a draft agenda for the mpls wg meeting at: http://www.tla-group.com/~mpls/mpls-agenda-dc.htm It is not yet complete, but please ping me if there are requess for agenda slots that I missed. I'll try to refine it further tomorrow. /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@ietf.org Mon Nov 1 15:07:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23950; Mon, 1 Nov 2004 15:07:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COihU-0001PE-6x; Mon, 01 Nov 2004 15:22:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COi6J-0002vp-9L; Mon, 01 Nov 2004 14:44:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COhqi-0003wR-46 for mpls@megatron.ietf.org; Mon, 01 Nov 2004 14:28:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20349 for ; Mon, 1 Nov 2004 14:28:13 -0500 (EST) Received: from evita3.cs.fredonia.edu ([141.238.30.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COi5f-0000aB-Qm for mpls@ietf.org; Mon, 01 Nov 2004 14:43:44 -0500 Received: from zubairi (zubairi.cs.fredonia.edu [141.238.30.211]) by evita3.cs.fredonia.edu (8.10.2/8.10.2) with SMTP id iA1JRfM19554 for ; Mon, 1 Nov 2004 14:27:41 -0500 Message-ID: <004b01c4c048$e3e80af0$d31eee8d@zubairi> From: "Junaid Ahmed Zubairi" To: Date: Mon, 1 Nov 2004 14:27:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4942.400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: 7bit Subject: [mpls] Telecom Symposium: draft Paper due Dec 7 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Junaid Ahmed Zubairi List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: 7bit Call for Papers 2005 Applied Telecommunication Symposium (ATS'05) "Modeling and Simulation Challenges in Telecommunication Systems" Part of the 2005 Spring Simulation Multiconference (SpringSim'05) Sponsored by: The Society for Modeling and Simulation International (SCS) April 2 - 8, 2005 Hilton Mission Valley Hotel San Diego, CA The Applied Telecommunication Symposium (ATS) is an international forum for exchange of technical knowledge and presentation of original papers on the analysis of telecommunication systems and technologies. It is intended for professionals, engineers, software developers, managers, and others interested in cellular and packet traffic characteristics, analysis of telecommunication networks, and practitioners operating telecommunication networks. We are looking for innovative technical papers describing projects, applications, and research and development work pertinent to telecommunication. This year's Symposium is particularly seeking papers in the following tracks: Wireless Chairs: Hassan Rajaei, Bowling Green State University, USA Axel Lehmann, Universitaet der Bundeswehr Muenchen, Germany Topics: UMTS GSM / CDMA 2.5G/3G Wireless Mobile Internet and Wireless Multimedia Cell Traffic Network Performance and Engineering Measurements SPECIAL SESSION: WLAN research with particular emphasis on QoS, routing, reliability, overload/congestion control, and interworking with 2.5/3G systems. Telecommunications Business and Regulation Chair: George Kraft, Stuart School of Business, Illinois Institute of Technology, USA Topics: Cost modeling Call center operations Billing models E-commerce Network Security and Management Chairs: Susan Lincke-Salecker, University of Wisconsin-Parkside, USA John Laskar, Mitretek Systems, USA Topics: Innovative Network Security methods WLAN Security Influence of security measures on network performance Operations, Administration, Maintenance Overload/congestion control Load balancing Networks and Multimedia Chairs: Aftab Ahmad, Norfolk State University, USA Wolfang Haidegger, Siemens, Austria Topics: Internet QoS Architectures Network performance - analysis and simulation Traffic characterization Packet switch architecture evaluation Modeling Techniques and V&V Chairs: Axel Lehmann, Universitaet der Bundeswehr Muenchen, Germany Shakil Akhtar, UAE University, Al-Ain, United Arab Emirates Topics: Simulation techniques Acceleration methods Distributed Simulation Simulation Tools for Modeling and V & V traffic measurements, analysis and synthesis Combined simulation/analytic procedures Metro area design and modeling Traffic Engineering with Protocols and Devices Chairs: Junaid Zubairi, SUNY at Fredonia, USA Chia J. Liu, AT&T Labs, USA Topics: Traffic Management and control Traffic engineering architectures Bandwidth management GMPLS VPN (Virtual Private Network) Performance Issues General Chair: Bohdan Bodnar Motorola, Inc. Co-Chair: Hassan Rajaei Bowling Green State University, USA Program Chair: George Kraft Stuart School of Business, Illinois Institute of Technology, USA Draft Paper / Extended Abstract Submission Deadline: December 7, 2004. Draft paper or extended abstract should be submitted to http://mc.manuscriptcentral.com/scs/proceedings/ Deadlines Abstract/Draft paper due - December 7, 2004 Notification of acceptance sent - December 21, 2004 Camera-ready paper due - January 31, 2005 Please indicate in the abstract for which track(s) you wish to have your paper considered; note that the final track selection will be at the discretion of the ATS organizers. The abstract must include the author(s), e-mail address(es), and affiliation. Sponsored by The Society for Modeling and Simulation International P.O. Box 17900 San Diego, California 92177 Phone 858-277-3888 Fax 858-277-3930 E-mail scs@scs.org _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Nov 2 19:41:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07526; Tue, 2 Nov 2004 19:41:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP9SW-0003lc-0u; Tue, 02 Nov 2004 19:57:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP94Q-0002qz-SP; Tue, 02 Nov 2004 19:32:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP8kg-0001NH-LC for mpls@megatron.ietf.org; Tue, 02 Nov 2004 19:11:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03929 for ; Tue, 2 Nov 2004 19:11:47 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP8zt-0002ua-9J for mpls@ietf.org; Tue, 02 Nov 2004 19:27:33 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id iA30BE997685; Tue, 2 Nov 2004 16:11:14 -0800 (PST) (envelope-from ina@juniper.net) Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id iA30B1e10535; Tue, 2 Nov 2004 16:11:01 -0800 (PST) (envelope-from ina@juniper.net) Date: Tue, 2 Nov 2004 16:11:01 -0800 (PST) From: Ina Minei To: mpls@ietf.org In-Reply-To: <20041012101652.V87940@garnet.juniper.net> Message-ID: <20041102134640.O39441@garnet.juniper.net> References: <20041012101652.V87940@garnet.juniper.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-554141445-1099432858=:39441" Content-ID: <20041102161032.O69354@garnet.juniper.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Subject: [mpls] Deadline extended on the operator survey for LDP deployments 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-554141445-1099432858=:39441 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <20041102161032.R69354@garnet.juniper.net> Many thanks to those of you who have already replied! I have received several requests to extend the deadline - the new deadline is November 16 (after the ietf). If you haven't done so already, please fill out the survey (attached here again). It should only take a few minutes to a person familiar with the network. The replies can be made confidential, please see below for full details. Thank you, Ina On Tue, 12 Oct 2004, Ina Minei wrote: > > Operators, > > We need to produce a "description of operational experience" > report to accompany the LDP spec to the IESG. > > Rajiv Papneja suggested to formalize this in a questionnaire. Rajiv and > I put together a set of questions, with input from Halit Ustundag, > Bob Thomas and Loa Andersson. > > Please take a few minutes to fill out the survey (at the end of > this email and also attached). Partial responses are also useful, if > you can't/don't_want_to answer any of the questions, just skip to the > next one. > > If you would like to respond anonymously, please state so in the > questionnaire. Confidential responses may be sent to Scott Bradner at > sob@harvard.edu. Scott will strip away the info that would make it > possible to trace the respondee before forwarding us the responses. > Scott has acted in this role for other similar efforts. > In addition, all confidential responses will be summarized in the > final report, to further obscure the source. Many thanks to Scott for > his help. > > Please send your responses by Oct 31st. > > Thank you for your cooperation, > > Ina & Rajiv > > > Feedback on LDP deployments > ============================ > > 1) Contact for the information provided > > Name: > Title: > E-mail: > Organization/department: > Postal address: > Phone: > > 2) Confidentiality > -- I would like the information to be confidential (confidential > responses will be summarized) > -- This information can be made publicly available > > 3) Reason for running LDP in the network (check all that apply) > -- L3VPN > -- L3VPN inter-AS scenario > -- L2VPN > -- VPLS > -- pseudowires > -- label-based forwarding > -- other (please specify) > > 4) Sections of the deployed network where LDP is enabled > -- edge > -- core > -- edge and core > > 5) How long have you run LDP in the network for (how long ago did you > start using LDP). > > 6) Reason why LDP was selected > -- ease of configuration > -- no need for traffic engineering > -- scalability concerns with other protocols > -- use of a particular offline computation tool > -- equipment vendor only supports LDP > -- ease of management > -- interoperability concerns > -- better understanding by staff > -- other > > 7) Are there targeted LDP sessions? If yes, for what purpose? > -- traversing a traffic engineered core > -- pseudo-wires > -- other (please specify) > -- don't use targeted sessions > > 8) Number of LSR running LDP in the network > > 9) Maximum number of sessions per LSR > 10) Average number of sessions per LSR > 11) Average number of targeted sessions per LSR > > 12) Number of LDP adjacencies per session (how many parallel interfaces > connect two peers - one or more than one) > > 13) Number of incoming/outgoing bindings (average) > 14) Number of LDP routes installed > 15) Number of PEs in the network > > 16) Do you use LDP graceful restart? > > 17) LSP setup is accomplished with > -- independent control > -- ordered control > -- both (if some routers support one and some support the other) > -- don't know > > 18) Label distribution is > -- downstream unsolicited mode > -- downstream on demand mode > -- don't know > > 19) If downstream on demand mode is used, is loop detection configured? > > 20) Label retention mode > -- conservative > -- liberal > -- both > -- don't know > > 21) Number of implementations in the network > -- one > -- more than one (please specify how many) > -- optional - please specify the implementations used > > Operations > ============ > 22) What challenges did you encounter in deploying an LDP network? > > 23) What issues did you encounter in running an LDP network? > > 24) Did you encounter any security issues with LDP? > > Other > ====== > 25) Did you face any common interoperability issues if multiple vendors > are used? If yes, please list. > > 26) Please comment on your experience with the protocol (e.g. resilience > to failures, convergence times, silent failures, etc.) > > > --0-554141445-1099432858=:39441 Content-Type: TEXT/PLAIN; NAME="sur.txt" Content-ID: <20041102140058.U39441@garnet.juniper.net> Content-Description: survey Content-Disposition: ATTACHMENT; FILENAME="sur.txt" Content-Transfer-Encoding: BASE64 DQpGZWVkYmFjayBvbiBMRFAgZGVwbG95bWVudHMNCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT0NCg0KMSkgQ29udGFjdCBmb3IgdGhlIGluZm9ybWF0 aW9uIHByb3ZpZGVkIA0KDQpOYW1lOiAgICAgICAgICAgICAgICAgICANClRp dGxlOiAgICAgICAgICAgICAgICAgIA0KRS1tYWlsOiAgICAgICAgICAgICAg ICAgDQpPcmdhbml6YXRpb24vZGVwYXJ0bWVudDogDQpQb3N0YWwgYWRkcmVz czogICAgICAgICAgDQpQaG9uZTogICAgICAgICAgICAgICAgICAgDQoNCjIp IENvbmZpZGVudGlhbGl0eSANCi0tIEkgd291bGQgbGlrZSB0aGUgaW5mb3Jt YXRpb24gdG8gYmUgY29uZmlkZW50aWFsIChjb25maWRlbnRpYWwNCnJlc3Bv bnNlcyB3aWxsIGJlIHN1bW1hcml6ZWQpDQotLSBUaGlzIGluZm9ybWF0aW9u IGNhbiBiZSBtYWRlIHB1YmxpY2x5IGF2YWlsYWJsZQ0KDQozKSBSZWFzb24g Zm9yIHJ1bm5pbmcgTERQIGluIHRoZSBuZXR3b3JrIChjaGVjayBhbGwgdGhh dCBhcHBseSkNCi0tIEwzVlBOICAgICANCi0tIEwzVlBOIGludGVyLUFTIHNj ZW5hcmlvDQotLSBMMlZQTg0KLS0gVlBMUw0KLS0gcHNldWRvd2lyZXMNCi0t IGxhYmVsLWJhc2VkIGZvcndhcmRpbmcNCi0tIG90aGVyIChwbGVhc2Ugc3Bl Y2lmeSkNCg0KNCkgU2VjdGlvbnMgb2YgdGhlIGRlcGxveWVkIG5ldHdvcmsg d2hlcmUgTERQIGlzIGVuYWJsZWQNCi0tIGVkZ2UNCi0tIGNvcmUNCi0tIGVk Z2UgYW5kIGNvcmUNCg0KNSkgSG93IGxvbmcgaGF2ZSB5b3UgcnVuIExEUCBp biB0aGUgbmV0d29yayBmb3IgKGhvdyBsb25nIGFnbyBkaWQgeW91DQpzdGFy dCB1c2luZyBMRFApLiANCg0KNikgUmVhc29uIHdoeSBMRFAgd2FzIHNlbGVj dGVkDQotLSBlYXNlIG9mIGNvbmZpZ3VyYXRpb24NCi0tIG5vIG5lZWQgZm9y IHRyYWZmaWMgZW5naW5lZXJpbmcNCi0tIHNjYWxhYmlsaXR5IGNvbmNlcm5z IHdpdGggb3RoZXIgcHJvdG9jb2xzDQotLSB1c2Ugb2YgYSBwYXJ0aWN1bGFy IG9mZmxpbmUgY29tcHV0YXRpb24gdG9vbA0KLS0gZXF1aXBtZW50IHZlbmRv ciBvbmx5IHN1cHBvcnRzIExEUA0KLS0gZWFzZSBvZiBtYW5hZ2VtZW50DQot LSBpbnRlcm9wZXJhYmlsaXR5IGNvbmNlcm5zDQotLSBiZXR0ZXIgdW5kZXJz dGFuZGluZyBieSBzdGFmZg0KLS0gb3RoZXINCg0KNykgQXJlIHRoZXJlIHRh cmdldGVkIExEUCBzZXNzaW9ucz8gSWYgeWVzLCBmb3Igd2hhdCBwdXJwb3Nl Pw0KLS0gdHJhdmVyc2luZyBhIHRyYWZmaWMgZW5naW5lZXJlZCBjb3JlDQot LSBwc2V1ZG8td2lyZXMNCi0tIG90aGVyIChwbGVhc2Ugc3BlY2lmeSkNCi0t IGRvbid0IHVzZSB0YXJnZXRlZCBzZXNzaW9ucw0KDQo4KSBOdW1iZXIgb2Yg TFNSIHJ1bm5pbmcgTERQIGluIHRoZSBuZXR3b3JrDQoNCjkpIE1heGltdW0g bnVtYmVyIG9mIHNlc3Npb25zIHBlciBMU1IgDQoxMCkgQXZlcmFnZSBudW1i ZXIgb2Ygc2Vzc2lvbnMgcGVyIExTUg0KMTEpIEF2ZXJhZ2UgbnVtYmVyIG9m IHRhcmdldGVkIHNlc3Npb25zIHBlciBMU1INCg0KMTIpIE51bWJlciBvZiBM RFAgYWRqYWNlbmNpZXMgcGVyIHNlc3Npb24gKGhvdyBtYW55IHBhcmFsbGVs IGludGVyZmFjZXMNCmNvbm5lY3QgdHdvIHBlZXJzIC0gb25lIG9yIG1vcmUg dGhhbiBvbmUpDQoNCjEzKSBOdW1iZXIgb2YgaW5jb21pbmcvb3V0Z29pbmcg YmluZGluZ3MgKGF2ZXJhZ2UpDQoxNCkgTnVtYmVyIG9mIExEUCByb3V0ZXMg aW5zdGFsbGVkDQoxNSkgTnVtYmVyIG9mIFBFcyBpbiB0aGUgbmV0d29yayAN Cg0KMTYpIERvIHlvdSB1c2UgTERQIGdyYWNlZnVsIHJlc3RhcnQ/DQoNCjE3 KSBMU1Agc2V0dXAgaXMgYWNjb21wbGlzaGVkIHdpdGggDQotLSBpbmRlcGVu ZGVudCBjb250cm9sDQotLSBvcmRlcmVkIGNvbnRyb2wNCi0tIGJvdGggKGlm IHNvbWUgcm91dGVycyBzdXBwb3J0IG9uZSBhbmQgc29tZSBzdXBwb3J0IHRo ZSBvdGhlcikNCi0tIGRvbid0IGtub3cNCg0KMTgpIExhYmVsIGRpc3RyaWJ1 dGlvbiBpcyANCi0tIGRvd25zdHJlYW0gdW5zb2xpY2l0ZWQgbW9kZQ0KLS0g ZG93bnN0cmVhbSBvbiBkZW1hbmQgbW9kZQ0KLS0gZG9uJ3Qga25vdw0KDQox OSkgSWYgZG93bnN0cmVhbSBvbiBkZW1hbmQgbW9kZSBpcyB1c2VkLCBpcyBs b29wIGRldGVjdGlvbiBjb25maWd1cmVkPw0KDQoyMCkgTGFiZWwgcmV0ZW50 aW9uIG1vZGUNCi0tIGNvbnNlcnZhdGl2ZQ0KLS0gbGliZXJhbCANCi0tIGJv dGgNCi0tIGRvbid0IGtub3cNCg0KMjEpIE51bWJlciBvZiBpbXBsZW1lbnRh dGlvbnMgaW4gdGhlIG5ldHdvcmsNCi0tIG9uZSANCi0tIG1vcmUgdGhhbiBv bmUgKHBsZWFzZSBzcGVjaWZ5IGhvdyBtYW55KQ0KLS0gb3B0aW9uYWwgLSBw bGVhc2Ugc3BlY2lmeSB0aGUgaW1wbGVtZW50YXRpb25zIHVzZWQNCg0KT3Bl cmF0aW9ucw0KPT09PT09PT09PT09DQoyMikgV2hhdCBjaGFsbGVuZ2VzIGRp ZCB5b3UgZW5jb3VudGVyIGluIGRlcGxveWluZyBhbiBMRFAgbmV0d29yaz8N Cg0KMjMpIFdoYXQgaXNzdWVzIGRpZCB5b3UgZW5jb3VudGVyIGluIHJ1bm5p bmcgYW4gTERQIG5ldHdvcms/DQoNCjI0KSBEaWQgeW91IGVuY291bnRlciBh bnkgc2VjdXJpdHkgaXNzdWVzIHdpdGggTERQPw0KDQpPdGhlcg0KPT09PT09 DQoyNSkgRGlkIHlvdSBmYWNlIGFueSBjb21tb24gaW50ZXJvcGVyYWJpbGl0 eSBpc3N1ZXMgaWYgbXVsdGlwbGUgdmVuZG9ycw0KYXJlIHVzZWQ/IElmIHll cywgcGxlYXNlIGxpc3QuDQoNCjI2KSBQbGVhc2UgY29tbWVudCBvbiB5b3Vy IGV4cGVyaWVuY2Ugd2l0aCB0aGUgcHJvdG9jb2wgKGUuZy4gcmVzaWxpZW5j ZQ0KdG8gZmFpbHVyZXMsIGNvbnZlcmdlbmNlIHRpbWVzLCBzaWxlbnQgZmFp bHVyZXMsIGV0Yy4pDQoNCg0KDQo= --0-554141445-1099432858=:39441 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --0-554141445-1099432858=:39441-- From mpls-bounces@ietf.org Tue Nov 2 19:45:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07979; Tue, 2 Nov 2004 19:45:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP9WG-0003r2-5S; Tue, 02 Nov 2004 20:01:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP96N-0003ry-TL; Tue, 02 Nov 2004 19:34:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP8wm-00085x-5I for mpls@megatron.ietf.org; Tue, 02 Nov 2004 19:24:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05437 for ; Tue, 2 Nov 2004 19:24:17 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP9Bz-0003II-7j for mpls@ietf.org; Tue, 02 Nov 2004 19:40:03 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id iA30Mo997759; Tue, 2 Nov 2004 16:22:50 -0800 (PST) (envelope-from ina@juniper.net) Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id iA30Mie12014; Tue, 2 Nov 2004 16:22:44 -0800 (PST) (envelope-from ina@juniper.net) Date: Tue, 2 Nov 2004 16:22:44 -0800 (PST) From: Ina Minei To: mpls@ietf.org Message-ID: <20041101112411.K33618@garnet.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [mpls] draft-minei-mpls-ldp-planned-restart-01.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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 At the Seoul ietf we presented a draft for LDP graceful restart for planned outages. Here is a new version of the draft, which addresses some of the operational concerns raised over the initial draft. http://www.ietf.org/internet-drafts/draft-minei-mpls-ldp-planned-restart-01.txt Abstract This document proposes an enhancement to the LDP graceful restart procedures defined in RFC 3478. The proposed extension allows operators to apply graceful restart only when the restart is planned (as opposed to both planned and unplanned restart). Your comments are welcome, Ina _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Nov 3 08:28:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07750; Wed, 3 Nov 2004 08:28:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPLRG-0004nP-Av; Wed, 03 Nov 2004 08:44:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPL2d-0003nf-8J; Wed, 03 Nov 2004 08:19:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COhEi-0001hX-07; Mon, 01 Nov 2004 13:49:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17297; Mon, 1 Nov 2004 13:48:57 -0500 (EST) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COhTb-00089a-79; Mon, 01 Nov 2004 14:04:27 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.11/8.12.11) with ESMTP id iA1ImN1r031328; Mon, 1 Nov 2004 10:48:23 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.12.11/8.12.11/Submit) id iA1ImNY9031327; Mon, 1 Nov 2004 10:48:23 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 1 Nov 2004 10:48:23 -0800 From: David Meyer To: pim@ietf.org, mpls@ietf.org, mboned@lists.uoregon.edu Message-ID: <20041101184823.GA29981@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go" -- John Lennon X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Wed, 03 Nov 2004 08:19:08 -0500 Cc: fenner@research.att.com, david.kessens@nokia.com Subject: [mpls] MP-LSP issues to be discussed at MBONED 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Folks, In an attempt to ensure that we have good communication between the multicast and MPLS groups around the P2MP LSP issues (really MP-LSP), I have scheduled some time during the MBONED WG for overview and discussion. So far this part of the agenda looks like this: MP-LSPs (Requirements/overview of current status) 30 minutes p2mp ping and traceroute 15 minutes draft-yasukawa-mpls-p2mp-lsp-ping-00.txt Farrel, et. al. If you have additional topics you would like to see discussed, please let me know. Thanks, Dave _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Nov 3 11:41:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24991; Wed, 3 Nov 2004 11:41:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPORZ-0000u1-BJ; Wed, 03 Nov 2004 11:57:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPO5y-0004zk-BY; Wed, 03 Nov 2004 11:34:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPNwR-0003Sq-9g for mpls@megatron.ietf.org; Wed, 03 Nov 2004 11:24:59 -0500 Received: from oberon.imc.kth.se (oberon.imc.kth.se [193.10.152.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23679 for ; Wed, 3 Nov 2004 11:24:56 -0500 (EST) Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.11.6/8.11.6) with ESMTP id iA3GJBr17907 for ; Wed, 3 Nov 2004 17:19:11 +0100 Received: from [127.0.0.1] ([172.16.2.190]) by mail1.imc.kth.se; Wed, 03 Nov 2004 17:24:26 +0100 Message-ID: <41890638.3060709@pi.se> Date: Wed, 03 Nov 2004 17:24:24 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org, Alex Zinin , Bill Fenner , George Swallow Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [mpls] status of the draft-raggarwa-mpls-rsvp-te-p2mp-01.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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit All, an earlier version of the draft-raggarwa-mpls-rsvp-te-p2mp-01.txt were discussed in San Diego, we also asked the room if ther were support for making this a working group document. There were a very good support for this, since then the editors has also asked for support for making this a working group document on the mailing list. We missed the cut off date, due to last minutes updates. I've asked the editors to republish the draft as a working group draft after the Washington meeting. /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@ietf.org Wed Nov 3 13:54:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07826; Wed, 3 Nov 2004 13:54:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPQWp-0004R4-53; Wed, 03 Nov 2004 14:10:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPQ9D-000341-CK; Wed, 03 Nov 2004 13:46:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPQ7J-0002FM-Ih; Wed, 03 Nov 2004 13:44:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06581; Wed, 3 Nov 2004 13:44:20 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPQMg-00045c-9b; Wed, 03 Nov 2004 14:00:15 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 03 Nov 2004 14:07:31 -0500 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iA3Ihkv7009172; Wed, 3 Nov 2004 13:43:47 -0500 (EST) Received: from swallow-mac.cisco.com ([161.44.74.242]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMT70570; Wed, 3 Nov 2004 13:43:45 -0500 (EST) Received: by swallow-mac.cisco.com (Postfix, from userid 501) id C0E37167651; Wed, 3 Nov 2004 13:43:54 -0500 (EST) Received: from cisco.com (localhost [127.0.0.1]) by swallow-mac.cisco.com (Postfix) with ESMTP id 91B80167648; Wed, 3 Nov 2004 13:43:54 -0500 (EST) To: David Meyer Subject: Re: [mpls] MP-LSP issues to be discussed at MBONED In-reply-to: Your message of "Mon, 01 Nov 2004 10:48:23 PST." <20041101184823.GA29981@1-4-5.net> From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1; GNU Emacs 21.2.1 Date: Wed, 03 Nov 2004 13:43:53 -0500 Message-Id: <20041103184354.C0E37167651@swallow-mac.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: mpls@ietf.org, david.kessens@nokia.com, mboned@lists.uoregon.edu, fenner@research.att.com, pim@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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Dave - Since the members of the MPLS wg are not of a single opinion on what MPLS is trying to accomplish, I'd like a few minutes up front to say (wearing my chair hat) what I believe we are chartered to do (and by implication what we are not chartered to do). ...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@ietf.org Fri Nov 5 03:29:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15700; Fri, 5 Nov 2004 03:29:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPziq-0004he-TG; Fri, 05 Nov 2004 03:45:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPzOA-0004tz-VV; Fri, 05 Nov 2004 03:24:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPzM6-0004Xm-7w for mpls@megatron.ietf.org; Fri, 05 Nov 2004 03:21:58 -0500 Received: from oberon.imc.kth.se (oberon.imc.kth.se [193.10.152.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15258 for ; Fri, 5 Nov 2004 03:21:56 -0500 (EST) Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.11.6/8.11.6) with ESMTP id iA58G1r27401 for ; Fri, 5 Nov 2004 09:16:01 +0100 Received: from [127.0.0.1] ([172.16.2.190]) by mail1.imc.kth.se; Fri, 05 Nov 2004 09:21:25 +0100 Message-ID: <418B3804.5090703@pi.se> Date: Fri, 05 Nov 2004 09:21:24 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org, IETF Agenda via RT Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Bill Fenner Subject: [mpls] wg agenda for Washington 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Working Group, please find an updated agenda at: http://www.tla-group.com/~mpls/mpls-agenda-dc.htm /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@ietf.org Mon Nov 8 12:07:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02033; Mon, 8 Nov 2004 12:07:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRCzg-0007Ir-Ls; Mon, 08 Nov 2004 12:07:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRCm9-00058D-QA; Mon, 08 Nov 2004 11:53:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRCUx-0004uj-7n for mpls@megatron.ietf.org; Mon, 08 Nov 2004 11:36:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27995 for ; Mon, 8 Nov 2004 11:36:04 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRCVT-0006EI-T4 for mpls@ietf.org; Mon, 08 Nov 2004 11:36:43 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iA8GbNnQ024098 for ; Mon, 8 Nov 2004 09:37:23 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id iA8GZrZX032407 for ; Mon, 8 Nov 2004 10:35:53 -0600 Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id ; Mon, 8 Nov 2004 11:35:53 -0500 Message-ID: <62173B970AE0A044AED8723C3BCF238101C93BA8@ma19exm01.e6.bcs.mot.com> From: Shah Miral-MGIA0588 To: mpls@ietf.org Date: Mon, 8 Nov 2004 11:35:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.6 (++) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [mpls] Mpls Ping Using LDP 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="===============0347497976==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 2.3 (++) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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. --===============0347497976== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C5B1.01490564" 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. ------_=_NextPart_001_01C4C5B1.01490564 Content-Type: text/plain Hello, I'm testing the MPLS-PING feature using LDP/RSVP(Draft: Detecting data path failures) with different routers. Interop with Cisco(GSR12000), barring a couple changes different from the draft, works fine. But when I try it with Juniper I somehow am not able to interop. When I mpls-ping juniper (M20 with JUNOS 6.14 release), it works perfectly fine. But the other way round, it somehow doesnt like the echo-reply sent by my router even though its exactly the same as what it had received, when I pinged it. Has anyone tried interop with juniper for this particular feature.? Any suggestions on what I could've missed or what could be wrong with the reply? Thanx, Miral Shah P.S: I'm trying to post this on the mpls-archive list. hope this works!! ------_=_NextPart_001_01C4C5B1.01490564 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0NzYiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFz cz03Mzg1ODIzMTYtMDgxMTIwMDQ+SGVsbG8sIEknbSB0ZXN0aW5nIA0KdGhlIE1QTFMtUElORyBm ZWF0dXJlIHVzaW5nIExEUC9SU1ZQKERyYWZ0OiBEZXRlY3RpbmcgZGF0YSBwYXRoIA0KZmFpbHVy ZXMpJm5ic3A7d2l0aCBkaWZmZXJlbnQgcm91dGVycy4gSW50ZXJvcCB3aXRoIENpc2NvKEdTUjEy MDAwKSwgYmFycmluZyBhIA0KY291cGxlIGNoYW5nZXMgZGlmZmVyZW50IGZyb20gdGhlIGRyYWZ0 LCB3b3JrcyBmaW5lLiBCdXQgd2hlbiZuYnNwO0kgdHJ5IGl0IHdpdGggDQpKdW5pcGVyIEkgc29t ZWhvdyBhbSBub3QgYWJsZSB0byBpbnRlcm9wLiBXaGVuJm5ic3A7SSZuYnNwO21wbHMtcGluZyBq dW5pcGVyIA0KKE0yMCB3aXRoIEpVTk9TIDYuMTQgcmVsZWFzZSksIGl0IHdvcmtzIHBlcmZlY3Rs eSBmaW5lLiBCdXQgdGhlIG90aGVyIHdheSByb3VuZCwgDQppdCBzb21laG93IGRvZXNudCBsaWtl IHRoZSBlY2hvLXJlcGx5IHNlbnQmbmJzcDtieSBteSByb3V0ZXIgZXZlbiB0aG91Z2ggaXRzIA0K ZXhhY3RseSB0aGUgc2FtZSBhcyB3aGF0IGl0IGhhZCByZWNlaXZlZCwgd2hlbiZuYnNwO0kgcGlu Z2VkIGl0LiZuYnNwO0hhcyBhbnlvbmUgDQp0cmllZCBpbnRlcm9wIHdpdGgganVuaXBlciBmb3Ig dGhpcyBwYXJ0aWN1bGFyIGZlYXR1cmUuPyBBbnkgc3VnZ2VzdGlvbnMgb24gDQp3aGF0Jm5ic3A7 SSBjb3VsZCd2ZSBtaXNzZWQgb3Igd2hhdCBjb3VsZCBiZSB3cm9uZyB3aXRoIHRoZSANCnJlcGx5 PzwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFO IA0KY2xhc3M9NzM4NTgyMzE2LTA4MTEyMDA0PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9NzM4NTgyMzE2LTA4MTEy MDA0PlRoYW54LDwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6 ZT0yPjxTUEFOIA0KY2xhc3M9NzM4NTgyMzE2LTA4MTEyMDA0PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNzPTczODU4MjMx Ni0wODExMjAwND5NaXJhbCANClNoYWg8L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBm YWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCmNsYXNzPTczODU4MjMxNi0wODExMjAwND48L1NQQU4+ PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBj bGFzcz03Mzg1ODIzMTYtMDgxMTIwMDQ+UC5TOiBJJ20gdHJ5aW5nIHRvIA0KcG9zdCB0aGlzIG9u IHRoZSBtcGxzLWFyY2hpdmUgbGlzdC4gaG9wZSB0aGlzIHdvcmtzISEgDQo8L1NQQU4+PC9GT05U PjwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------_=_NextPart_001_01C4C5B1.01490564-- --===============0347497976== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0347497976==-- From mpls-bounces@ietf.org Mon Nov 8 13:22:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09200; Mon, 8 Nov 2004 13:22:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CREAH-0000ng-LG; Mon, 08 Nov 2004 13:22:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRE2k-0007YD-HU; Mon, 08 Nov 2004 13:15:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRDru-0005TI-HD for mpls@megatron.ietf.org; Mon, 08 Nov 2004 13:03:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07536 for ; Mon, 8 Nov 2004 13:03:51 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRDsT-0000IJ-UP for mpls@ietf.org; Mon, 08 Nov 2004 13:04:31 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id iA8I3MBm005123; Mon, 8 Nov 2004 10:03:22 -0800 (PST) (envelope-from ina@juniper.net) Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id iA8I3Ie41320; Mon, 8 Nov 2004 10:03:22 -0800 (PST) (envelope-from ina@juniper.net) Date: Mon, 8 Nov 2004 10:03:18 -0800 (PST) From: Ina Minei To: Shah Miral-MGIA0588 Subject: Re: [mpls] Mpls Ping Using LDP In-Reply-To: <62173B970AE0A044AED8723C3BCF238101C93BA8@ma19exm01.e6.bcs.mot.com> Message-ID: <20041108095718.L20236@garnet.juniper.net> References: <62173B970AE0A044AED8723C3BCF238101C93BA8@ma19exm01.e6.bcs.mot.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Shah, Juniper code was successfully tested with several vendors, Cisco being one of them. It is not clear to me the exact nature of the difficulty you are encountering, but this mailing list is not the right place to discuss it, unless you believe you are seeing a standards issue. Ina On Mon, 8 Nov 2004, Shah Miral-MGIA0588 wrote: > Hello, I'm testing the MPLS-PING feature using LDP/RSVP(Draft: Detecting data path failures) with different routers. Interop with Cisco(GSR12000), barring a couple changes different from the draft, works fine. But when I try it with Juniper I somehow am not able to interop. When I mpls-ping juniper (M20 with JUNOS 6.14 release), it works perfectly fine. But the other way round, it somehow doesnt like the echo-reply sent by my router even though its exactly the same as what it had received, when I pinged it. Has anyone tried interop with juniper for this particular feature.? Any suggestions on what I could've missed or what could be wrong with the reply? > > Thanx, > > Miral Shah > > P.S: I'm trying to post this on the mpls-archive list. hope this works!! > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Nov 9 09:07:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29030; Tue, 9 Nov 2004 09:07:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRWf7-0004NI-Sq; Tue, 09 Nov 2004 09:07:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRWP9-0007ey-RA; Tue, 09 Nov 2004 08:51:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRWMD-00070w-6g for mpls@megatron.ietf.org; Tue, 09 Nov 2004 08:48:25 -0500 Received: from web15705.mail.cnb.yahoo.com (web15705.mail.cnb.yahoo.com [202.165.102.72]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA26498 for ; Tue, 9 Nov 2004 08:48:19 -0500 (EST) Message-ID: <20041109134725.18750.qmail@web15705.mail.cnb.yahoo.com> Received: from [210.77.19.17] by web15705.mail.cnb.yahoo.com via HTTP; Tue, 09 Nov 2004 21:47:25 CST Date: Tue, 9 Nov 2004 21:47:25 +0800 (CST) From: =?gb2312?q?=BD=DC=20=D0=EC?= To: mpls@ietf.org MIME-Version: 1.0 X-MIME-Autoconverted: from 8bit to base64 by ietf.org id IAA26498 Subject: [mpls] Is it useful to implement multi-path in MPLS? 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="===============1166680954==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 --===============1166680954== Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: base64 ICAgIEluIG9yZGVyIHRvIGF2b2lkIGNvbmdlc3Rpb24sc29tZXRpbWVzIG11bHRpcGF0aHMN CmFyZSB1c2VkLGlzIGl0IHRoZSBzYW1lIHRoaW5nIGluIE1QTFM/DQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRG8gWW91 IFlhaG9vIT8NCjE1MM3yx/pNUDO36L/xy9GjrLT4xPq0s8jr0vTA1rXuzMMNCmh0dHA6Ly9t dXNpYy55aXNvdS5jb20vDQrDwMWuw/fQx9Om09C+odPQo6zL0bHpw8DNvKGi0d7NvLrNv+HN vA0KaHR0cDovL2ltYWdlLnlpc291LmNvbQ0KMUe+zcrHMTAwMNXXo6zRxbuitefTytfU1vrA qcjdo6ENCmh0dHA6Ly9jbi5yZC55YWhvby5jb20vbWFpbF9jbi90YWcvMWcvKmh0dHA6Ly9j bi5tYWlsLnlhaG9vLmNvbS9ldmVudC9tYWlsXzFnLw0K --===============1166680954== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1166680954==-- From mpls-bounces@ietf.org Tue Nov 9 16:43:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16292; Tue, 9 Nov 2004 16:43:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRdmM-0007VA-4j; Tue, 09 Nov 2004 16:43:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRdi7-0007JJ-RX; Tue, 09 Nov 2004 16:39:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRdhI-00079b-Um for mpls@megatron.ietf.org; Tue, 09 Nov 2004 16:38:40 -0500 Received: from wombat.seabridge.co.il ([212.25.127.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15847 for ; Tue, 9 Nov 2004 16:38:38 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 9 Nov 2004 23:35:40 +0200 Message-ID: <6FAB860EC6AE3C4EB327204DEC33A528E541AD@wombat.seabridge.co.il> Thread-Topic: BFD For MPLS LSPs Thread-Index: AcTGpAGGO9mo0tGrSK+YfOI2QL9LuQ== From: "Nurit Sprecher" To: , Cc: Nurit Sprecher Subject: [mpls] BFD For MPLS 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: , Content-Type: multipart/mixed; boundary="===============1648901016==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 This is a multi-part message in MIME format. --===============1648901016== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C6A4.0F077660" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C6A4.0F077660 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have some questions about the BFD's draft on BFD for MPLS LSPs. 1. I think that this should be an MPLS work. It is a specific mechanism for the MPLS. 2. It looks like being companion to the ITU-T OAM mechanism defined for the MPLS. Is it? What is the attitude of the MPLS guys for this draft? 3. What is the status of this draft? (there was no BFD session this week). 4. Is it compliant to the requirements for the MPLS OAM? 5. Is it a reasonable solution? Thanks, Nurit, ------_=_NextPart_001_01C4C6A4.0F077660 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have some questions about the BFD's draft on BFD = for MPLS LSPs.

  1. I think that this = should be an MPLS work. It is a specific mechanism for the = MPLS.
  2. It looks like being = companion to the ITU-T OAM mechanism defined for the MPLS. Is it? What is the attitude of the MPLS guys for this = draft?
  3. What is the status of = this draft? (there was no BFD session this = week).
  4. Is it compliant to the requirements for the MPLS OAM?
  5. Is it a reasonable = solution?

Thanks,

Nurit,

------_=_NextPart_001_01C4C6A4.0F077660-- --===============1648901016== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1648901016==-- From mpls-bounces@ietf.org Tue Nov 9 17:33:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21977; Tue, 9 Nov 2004 17:33:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CReZ0-0000OG-Mi; Tue, 09 Nov 2004 17:34:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CReHb-0007PM-Ee; Tue, 09 Nov 2004 17:16:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CReC0-0006Bu-Mc; Tue, 09 Nov 2004 17:10:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19663; Tue, 9 Nov 2004 17:10:22 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CReCo-0008Ew-An; Tue, 09 Nov 2004 17:11:16 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 09 Nov 2004 17:09:52 -0500 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iA9M9nR5004780; Tue, 9 Nov 2004 17:09:49 -0500 (EST) Received: from [130.129.139.226] (rtp-vpn1-86.cisco.com [10.82.224.86]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMX58798; Tue, 9 Nov 2004 17:09:47 -0500 (EST) In-Reply-To: <6FAB860EC6AE3C4EB327204DEC33A528E541AD@wombat.seabridge.co.il> References: <6FAB860EC6AE3C4EB327204DEC33A528E541AD@wombat.seabridge.co.il> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0FC68842-329C-11D9-AF25-000D93AD480A@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: [mpls] BFD For MPLS LSPs Date: Tue, 9 Nov 2004 17:09:44 -0500 To: "Nurit Sprecher" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, rtg-bfd@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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit On Nov 9, 2004, at 4:35 PM, Nurit Sprecher wrote: > I have some questions about the BFD's draft on BFD for MPLS LSPs. > 1. I think that this should be an MPLS work. It is a specific > mechanism for the MPLS. It was decided to do it in BFD. I don't think it matters much where it is done. > 2. It looks like being companion to the ITU-T OAM mechanism defined > for the MPLS. Which ITU OAM mechanism are you referring to? > Is it? What is the attitude of the MPLS guys for this draft? Which "MPLS guys" are you referring to? > 3. What is the status of this draft? (there was no BFD session this > week). It is almost ready for last call. There are some security concerns with the baseline BFD draft, so we are waiting to make changes to align with any changes there. > 4. Is it compliant to the requirements for the MPLS OAM? Yes, I think so. Many of the same authors worked on both. > 5. Is it a reasonable solution? I think so. 8) --Tom > > Thanks, > > Nurit, > _______________________________________________ > 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@ietf.org Tue Nov 9 23:27:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21123; Tue, 9 Nov 2004 23:27:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRk5w-0007W5-5n; Tue, 09 Nov 2004 23:28:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRk15-0001Wj-MI; Tue, 09 Nov 2004 23:23:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRjz9-0001HF-2r for mpls@megatron.ietf.org; Tue, 09 Nov 2004 23:21:31 -0500 Received: from huawei.com (szxga02-in.huawei.com [61.144.161.54] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20747 for ; Tue, 9 Nov 2004 23:21:15 -0500 (EST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I6Y00CQM400Y9@szxga02-in.huawei.com> for Mpls@lists.ietf.org; Wed, 10 Nov 2004 12:19:12 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar3 2004)) with ESMTP id <0I6Y00D5U400VP@szxga02-in.huawei.com> forMpls@lists.ietf.org; Wed, 10 Nov 2004 12:19:12 +0800 (CST) Received: from l04955 ([10.110.67.7]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar3 2004)) with ESMTPA id <0I6Y004SY3ZYVJ@szxml02-in.huawei.com> forMpls@lists.ietf.org; Wed, 10 Nov 2004 12:19:11 +0800 (CST) Date: Wed, 10 Nov 2004 12:21:41 +0800 From: lidefeng <77cronux.leed0621@huawei.com> To: Mpls@ietf.org Message-id: <00aa01c4c6dc$c7f39270$07436e0a@l04955> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-Priority: 3 X-MSMail-priority: Normal X-imss-version: 2.7 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com Subject: [mpls] Fw: Questions about draft-ietf-mpls-rsvp-lsp-fastreroute-07 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="===============1891059268==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 3.1 (+++) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 This is a multi-part message in MIME format. --===============1891059268== Content-type: multipart/alternative; boundary="Boundary_(ID_85EGlAdG7UoarMEbCshq7A)" This is a multi-part message in MIME format. --Boundary_(ID_85EGlAdG7UoarMEbCshq7A) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: base64 DQoNCkkgaGF2ZSBzb21lIHF1ZXN0aW9ucyBhYm91dCBkcmFmdC1pZXRmLW1wbHMtcnN2cC1sc3At ZmFzdHJlcm91dGUtMDcsY291bGQgeW91IHBsZWFzZSBleHBsYWluIHRoZW0gZm9yIG1lPw0KDQoo MSkgV2hhdCBpcyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuICJCYWNrdXAgVHVubmVsIiBhbmQgIkJ5 cGFzcyBUdW5uZWwiLCB0aGVpciBkZWZpbml0aW9ucyBhcmUgYXMgZm9sbG93czoNCg0KQnlwYXNz IFR1bm5lbCAtIEFuIExTUCB0aGF0IGlzIHVzZWQgdG8gcHJvdGVjdCBhIHNldCBvZiBMU1BzICBw YXNzaW5nIG92ZXIgYSBjb21tb24gZmFjaWxpdHkuDQoNCkJhY2t1cCBUdW5uZWwgLSBUaGUgTFNQ IHRoYXQgaXMgdXNlZCB0byBiYWNrdXAgdXAgb25lIG9mIHRoZSBtYW55IExTUHMgaW4gbWFueS10 by1vbmUgYmFja3VwLg0KDQogDQoNCiAoMikgSW4gc2VjdGlvbiAiNS4xIEZBU1RfUkVST1VURSBP YmplY3QiLCBmb2xsb3dpbmcgZmllbGRzIGFyZSBkZWZpbmVkOg0KDQpFeGNsdWRlLWFueTogQSAz Mi1iaXQgdmVjdG9yIHJlcHJlc2VudGluZyBhIHNldCBvZiBhdHRyaWJ1dGUgZmlsdGVycyBhc3Nv Y2lhdGVkIHdpdGggYSBiYWNrdXAgcGF0aCBhbnkgb2Ygd2hpY2ggcmVuZGVycyBhIGxpbmsgdW5h Y2NlcHRhYmxlLg0KDQogSW5jbHVkZS1hbnk6IEEgMzItYml0IHZlY3RvciByZXByZXNlbnRpbmcg YSBzZXQgb2YgYXR0cmlidXRlIGZpbHRlcnMgIGFzc29jaWF0ZWQgd2l0aCBhIGJhY2t1cCBwYXRo IGFueSBvZiANCg0Kd2hpY2ggcmVuZGVycyBhIGxpbmsgYWNjZXB0YWJsZSAod2l0aCByZXNwZWN0 IHRvIHRoaXMgdGVzdCkuIEEgbnVsbCBzZXQgKGFsbCBiaXRzIHNldCB0byB6ZXJvKSBhdXRvbWF0 aWNhbGx5IA0KDQpwYXNzZXMuDQoNCg0KDQpNeSBxdWVzdGlvbiBpc6O6IEhvdyBkb2VzIFBMUiBr bm93IHdoaWNoIGxpbmsgaXMgcmVsYXRlZCB0byB0aGUgcGFydGljdWxhciBiaXQgaW4gdGhlIDMy LWJpdCB2ZWN0b3I/IGkuZS4gd2l0aCBhIHBhcnRpY3VsYXIgMzItYml0IHZlY3RvciB2YWx1ZSwg aG93IGRvZXMgUExSIGtub3cgd2hpY2ggbGlua3MgYXJlIGFjY2VwdGFibGUsIGFuZCB3aGljaCBs aW5rcyBhcmUgdW5hY2NlcHRhYmxlLCBhbmQgaWYgd2UgaGF2ZSB0aGUgobBFeGNsdWRlLWFueaGx IHZlY3Rvciwgd2h5IHdlIHN0aWxsIG5lZWQgdGhlIKGwSW5jbHVkZS1hbnmhsSB2ZWN0b3IsIEkg dGhpbmssIHdpdGggdGhlIGluZm9ybWF0aW9uIG9mIGxpbmtzIHdoaWNoIG1hcmtlZCBhcyChsHVu YWNjZXB0YWJsZaGxIGJ5IEV4Y2x1ZGUtYW55IHZlY3Rvciwgd2UgY2FuIGdldCB0aGUgaW5mb3Jt YXRpb24gb2YgbGlua3Mgd2hpY2ggbWFya2VkIGFzIKGwYWNjZXB0YWJsZaGxIGJ5IKGwSW5jbHVk ZS1hbnmhsSB2ZWN0b3IuDQoNCg0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIQ0KDQoNCg0KUmVnYXJk cw0KDQoNCg0KRGVmZW5nIExpDQo= --Boundary_(ID_85EGlAdG7UoarMEbCshq7A) Content-type: text/html; charset=gb2312 Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zOm8gPSAidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6 b2ZmaWNlIj48SEVBRD4NCjxNRVRBIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRl eHQvaHRtbDsgY2hhcnNldD1nYjIzMTIiPg0KPE1FVEEgY29udGVudD0iTVNIVE1MIDYuMDAuMjgw MC4xMTA2IiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFEPg0KPEJPRFkg YmdDb2xvcj0jZmZmZmZmPg0KPERJVj48QlI+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4NCjxQ IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PEZPTlQgc2l6ZT0z PjxCPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iQ09MT1I6IGJsYWNrIj48Rk9OVCBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPkkgaGF2ZSBzb21lIHF1ZXN0aW9ucyBhYm91dCANCmRyYWZ0LWlldGYt bXBscy1yc3ZwLWxzcC1mYXN0cmVyb3V0ZS0wNyxjb3VsZCB5b3UgcGxlYXNlIGV4cGxhaW4gdGhl bSBmb3IgDQptZT88L0ZPTlQ+PC9TUEFOPjwvQj48L0ZPTlQ+PC9QPg0KPFAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48Rk9OVCBzaXplPTM+PFNQQU4+PEZPTlQg DQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPigxKSBXaGF0IGlzIHRoZSBkaWZmZXJlbmNlIGJldHdl ZW4gIkJhY2t1cCBUdW5uZWwiIGFuZCANCiI8L0ZPTlQ+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj5CeXBhc3MgVHVubmVsIiwgdGhlaXIgZGVmaW5pdGlvbnMgYXJlIGFzIA0KZm9sbG93czo8 L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJ TjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iQ09MT1I6IGJsYWNrIj48 Rk9OVCBzaXplPTM+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5CeXBhc3MgVHVubmVsIC0g DQpBbiBMU1AgdGhhdCBpcyB1c2VkIHRvIHByb3RlY3QgYSBzZXQgb2YgTFNQcyA8U1BBTiANCnN0 eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7PC9TUEFOPnBhc3Npbmcgb3ZlciBhIGNvbW1v biANCmZhY2lsaXR5LjxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVT IA0Kc3R5bGU9IkNPTE9SOiBibGFjayI+PEZPTlQgc2l6ZT0zPjxGT05UIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+QmFja3VwIFR1bm5lbCAtIA0KVGhlIExTUCB0aGF0IGlzIHVzZWQgdG8gYmFja3Vw IHVwIG9uZSBvZiB0aGUgbWFueSBMU1BzIGluIG1hbnktdG8tb25lIA0KYmFja3VwLjxvOnA+PC9v OnA+PC9GT05UPjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJN QVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkNPTE9SOiBibGFj ayI+PG86cD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIA0Kc2l6ZT0zPjxTVFJPTkc+PC9T VFJPTkc+PC9GT05UPjwvbzpwPjwvU1BBTj4mbmJzcDs8L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iQ09M T1I6IGJsYWNrIj48bzpwPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PEZPTlQgc2l6ZT0z PiZuYnNwOzxGT05UIA0KZmFjZT3LzszlPigyKSBJbiBzZWN0aW9uICI1LjEgRkFTVF9SRVJPVVRF IE9iamVjdCIsIGZvbGxvd2luZyBmaWVsZHMgYXJlIA0KZGVmaW5lZDo8L0ZPTlQ+PC9GT05UPjwv Rk9OVD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46 IDBjbSAwY20gMHB0Ij48Rk9OVCBzaXplPTQ+PEZPTlQgDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxTUEFOPkV4Y2x1ZGUtYW55OiA8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHls ZT0iQ09MT1I6IGJsYWNrIj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkEgMzItYml0IHZl Y3RvciByZXByZXNlbnRpbmcgYSANCnNldCBvZiBhdHRyaWJ1dGUgZmlsdGVycyBhc3NvY2lhdGVk IHdpdGggYSBiYWNrdXAgcGF0aCBhbnkgb2Ygd2hpY2ggcmVuZGVycyBhIA0KbGluayB1bmFjY2Vw dGFibGUuPG86cD48L286cD48L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L1A+DQo8UCBjbGFzcz1Nc29O b3JtYWwgDQpzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCAzNnB0OyBURVhULUlOREVOVDogLTM2 cHQ7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IDM2LjBwdCI+PEZP TlQgDQpzaXplPTQ+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48U1BBTj48U1BBTiBzdHls ZT0ibXNvLWxpc3Q6IElnbm9yZSI+PFNQQU4gDQpzdHlsZT0iRk9OVDogN3B0ICdUaW1lcyBOZXcg Um9tYW4nIj4mbmJzcDs8L1NQQU4+PC9TUEFOPkluY2x1ZGUtYW55OiANCjwvU1BBTj48L0ZPTlQ+ PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iQ09MT1I6IGJsYWNrIj48Rk9OVCANCmZhY2U9IlRpbWVz IE5ldyBSb21hbiI+QSAzMi1iaXQgdmVjdG9yIHJlcHJlc2VudGluZyBhIHNldCBvZiBhdHRyaWJ1 dGUgZmlsdGVycyANCjxTUEFOIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7PC9TUEFO PmFzc29jaWF0ZWQgd2l0aCBhIGJhY2t1cCBwYXRoIGFueSANCm9mIDwvRk9OVD48L1NQQU4+PC9G T05UPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCANCnN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0 IDM2cHQ7IFRFWFQtSU5ERU5UOiAtMzZwdDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWIt c3RvcHM6IGxpc3QgMzYuMHB0Ij48Rk9OVCANCnNpemU9ND48U1BBTiBsYW5nPUVOLVVTIHN0eWxl PSJDT0xPUjogYmxhY2siPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+d2hpY2ggDQpyZW5k ZXJzIGEgbGluayBhY2NlcHRhYmxlICh3aXRoIHJlc3BlY3QgdG8gdGhpcyB0ZXN0KS4gQSBudWxs IHNldCAoYWxsIGJpdHMgc2V0IA0KdG8gemVybykgYXV0b21hdGljYWxseSA8L0ZPTlQ+PC9TUEFO PjwvRk9OVD48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgDQpzdHlsZT0iTUFSR0lOOiAwY20gMGNt IDBwdCAzNnB0OyBURVhULUlOREVOVDogLTM2cHQ7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsg dGFiLXN0b3BzOiBsaXN0IDM2LjBwdCI+PEZPTlQgDQpzaXplPTQ+PFNQQU4gbGFuZz1FTi1VUyBz dHlsZT0iQ09MT1I6IGJsYWNrIj48Rk9OVCANCmZhY2U9IlRpbWVzIE5ldyBSb21hbiI+cGFzc2Vz LjxvOnA+PC9vOnA+PC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48Rk9OVCBzaXplPTM+PFNQQU4gDQpzdHlsZT0i Q09MT1I6IGJsYWNrOyBGT05ULUZBTUlMWTogy87M5TsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJzsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu JyI+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1B UkdJTjogMGNtIDBjbSAwcHQiPjxGT05UIHNpemU9Mz48U1BBTiANCnN0eWxlPSJDT0xPUjogYmxh Y2s7IEZPTlQtRkFNSUxZOiDLzszlOyBtc28tYXNjaWktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nOyBtc28taGFuc2ktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nIj5NeSANCnF1 ZXN0aW9uIGlzo7o8L1NQQU4+PFNQQU4gc3R5bGU9IkNPTE9SOiBibGFjayI+PEZPTlQgDQpmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxTVFJPTkc+IDxTUEFOIGxhbmc9RU4tVVM+SG93IGRvZXMgUExS IGtub3cgd2hpY2ggbGluayBpcyANCnJlbGF0ZWQgdG8gdGhlIHBhcnRpY3VsYXIgYml0IGluIHRo ZSAzMi1iaXQgdmVjdG9yPyBpLmUuIHdpdGggYSBwYXJ0aWN1bGFyIA0KMzItYml0IHZlY3RvciB2 YWx1ZSwgaG93IGRvZXMgUExSIGtub3cgd2hpY2ggbGlua3MgYXJlIGFjY2VwdGFibGUsIGFuZCB3 aGljaCANCmxpbmtzIGFyZSB1bmFjY2VwdGFibGUsIGFuZCBpZiB3ZSBoYXZlIHRoZSChsEV4Y2x1 ZGUtYW55obEgdmVjdG9yLCB3aHkgd2Ugc3RpbGwgDQpuZWVkIHRoZSChsEluY2x1ZGUtYW55obEg dmVjdG9yLCBJIHRoaW5rLCB3aXRoIHRoZSBpbmZvcm1hdGlvbiBvZiBsaW5rcyB3aGljaCANCm1h cmtlZCBhcyChsHVuYWNjZXB0YWJsZaGxIGJ5IEV4Y2x1ZGUtYW55IHZlY3Rvciwgd2UgY2FuIGdl dCB0aGUgaW5mb3JtYXRpb24gb2YgDQpsaW5rcyB3aGljaCBtYXJrZWQgYXMgobBhY2NlcHRhYmxl obEgYnkgobBJbmNsdWRlLWFueaGxIA0KdmVjdG9yLjwvU1BBTj48L1NUUk9ORz48L0ZPTlQ+PC9T UEFOPjwvRk9OVD48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBj bSAwcHQiPjxGT05UIHNpemU9Mz48U1BBTiANCnN0eWxlPSJDT0xPUjogYmxhY2siPjxGT05UIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PFNUUk9ORz48U1BBTiANCmxhbmc9RU4tVVM+PC9TUEFOPjwv U1RST05HPjwvRk9OVD48L1NQQU4+PC9GT05UPiZuYnNwOzwvUD4NCjxQIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PEZPTlQgc2l6ZT0zPjxTUEFOIA0Kc3R5bGU9 IkNPTE9SOiBibGFjayI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48U1RST05HPjxTUEFO IGxhbmc9RU4tVVM+VGhhbmsgDQp5b3UgdmVyeSBtdWNoITwvU1BBTj48L1NUUk9ORz48L0ZPTlQ+ PC9TUEFOPjwvRk9OVD48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNt IDBjbSAwcHQiPjxGT05UIHNpemU9Mz48U1BBTiANCnN0eWxlPSJDT0xPUjogYmxhY2siPjxGT05U IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PFNUUk9ORz48U1BBTiANCmxhbmc9RU4tVVM+PC9TUEFO PjwvU1RST05HPjwvRk9OVD48L1NQQU4+PC9GT05UPiZuYnNwOzwvUD4NCjxQIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PEZPTlQgc2l6ZT0zPjxTUEFOIA0Kc3R5 bGU9IkNPTE9SOiBibGFjayI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48U1RST05HPjxT UEFOIA0KbGFuZz1FTi1VUz5SZWdhcmRzPC9TUEFOPjwvU1RST05HPjwvRk9OVD48L1NQQU4+PC9G T05UPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+ PEZPTlQgc2l6ZT0zPjxTUEFOIA0Kc3R5bGU9IkNPTE9SOiBibGFjayI+PEZPTlQgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48U1RST05HPjxTUEFOIA0KbGFuZz1FTi1VUz48L1NQQU4+PC9TVFJPTkc+ PC9GT05UPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSJNQVJHSU46IDBjbSAwY20gMHB0Ij48Rk9OVCBzaXplPTM+PFNQQU4gDQpzdHlsZT0iQ09MT1I6 IGJsYWNrIj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxTVFJPTkc+PFNQQU4gDQpsYW5n PUVOLVVTPkRlZmVuZyANCkxpPG86cD48L286cD48L1NQQU4+PC9TVFJPTkc+PC9GT05UPjwvU1BB Tj48L0ZPTlQ+PC9QPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K --Boundary_(ID_85EGlAdG7UoarMEbCshq7A)-- --===============1891059268== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1891059268==-- From mpls-bounces@ietf.org Wed Nov 10 03:44:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10076; Wed, 10 Nov 2004 03:44:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRo6G-00046x-EE; Wed, 10 Nov 2004 03:45:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRo3d-0006rB-Tn; Wed, 10 Nov 2004 03:42:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRo1u-0006eu-Em for mpls@megatron.ietf.org; Wed, 10 Nov 2004 03:40:38 -0500 Received: from huawei.com (szxga03-in.huawei.com [61.144.161.55] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09712 for ; Wed, 10 Nov 2004 03:40:06 -0500 (EST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I6Y0042SFYC75@szxga03-in.huawei.com> for mpls@lists.ietf.org; Wed, 10 Nov 2004 16:37:24 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar3 2004)) with ESMTP id <0I6Y0038BFXJON@szxga03-in.huawei.com> formpls@lists.ietf.org; Wed, 10 Nov 2004 16:37:24 +0800 (CST) Received: from l04955 ([10.110.67.7]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar3 2004)) with ESMTPA id <0I6Y00A4METH5P@szxml02-in.huawei.com> formpls@lists.ietf.org; Wed, 10 Nov 2004 16:12:53 +0800 (CST) Date: Wed, 10 Nov 2004 16:15:23 +0800 From: lidefeng <77cronux.leed0621@huawei.com> To: mpls@ietf.org Message-id: <00ca01c4c6fd$6dae1fd0$07436e0a@l04955> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-Priority: 3 X-MSMail-priority: Normal X-imss-version: 2.7 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com Subject: [mpls] Question about draft-ietf-mpls-rsvp-lsp-fastreroute-07 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="===============0232726241==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 1.9 (+) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c This is a multi-part message in MIME format. --===============0232726241== Content-type: multipart/alternative; boundary="Boundary_(ID_tuKTfIhMl+MCqDRRp8PItw)" This is a multi-part message in MIME format. --Boundary_(ID_tuKTfIhMl+MCqDRRp8PItw) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT In section "7.2 Procedures for Backup Path Computation", it states that: "Before CSPF computation, the following information should be collected at a PLR: -... -... - The upstream uni-directional links that the protected LSP passes through. This information is learned from the RECORD_ROUTE objects; it is only needed for setting up one-to-one protection. In the path-specific method, it is necessary to avoid the detour and the protected LSP sharing a common next-hop upstream of the failure. In the sender-template-specific mode, this same restriction is necessary to avoid sharing bandwidth between the detour and its protected LSP, where that bandwidth has only been reserved once." My question is (a) In the following diagram,if failure is R3 node, then next-hop upstream of the failure is R2,right? (b) if (a) is right? why should we avoid avoid the detour and the protected LSP sharing a common next-hop upstream of the failure in path-specific method and in sender-template-specific mode? and in the following diagram, Protected LSP is [R1->R2->R3->R4->R5]. Detour LSP is [R2->R6->R7->R4], they share the common next-hop upstream of the failure when R3 is failure, is it a contradiction? L32 L33 L34 L35 R1-------R2-------R3-------R4-------R5 | | L46 | L47 | L44 R6---------------R7 Protected LSP: [R1->R2->R3->R4->R5] Detour LSP: [R2->R6->R7->R4] Regards Defeng Li --Boundary_(ID_tuKTfIhMl+MCqDRRp8PItw) Content-type: text/html; charset=gb2312 Content-Transfer-Encoding: 7BIT
In section "7.2 Procedures for Backup Path Computation", it states that:
 
"Before CSPF computation, the following information should be collected at a PLR:
-...
-...
- The upstream uni-directional links that the protected LSP
        passes through.  This information is learned from the
        RECORD_ROUTE objects; it is only needed for setting up
        one-to-one protection.  In the path-specific method, it is
        necessary to avoid the detour and the protected LSP sharing
        a common next-hop upstream of the failure.  In the
        sender-template-specific mode, this same restriction is
        necessary to avoid sharing bandwidth between the detour and
        its protected LSP, where that bandwidth has only been reserved
        once."
 
My question is
(a) In the following diagram,if failure is R3 node, then next-hop upstream of the failure is R2,right?
(b) if (a) is right? why should we avoid avoid the detour and the protected LSP sharing a common next-hop upstream of the failure in path-specific method and in sender-template-specific mode? and in the following diagram,   Protected LSP is [R1->R2->R3->R4->R5].  Detour LSP is [R2->R6->R7->R4], they share the common next-hop upstream of the failure when R3 is failure, is it a contradiction?
               L32      L33      L34      L35
           R1-------R2-------R3-------R4-------R5
                    |                |
               L46  |      L47       | L44
                    R6---------------R7
 
            Protected LSP: [R1->R2->R3->R4->R5]
            Detour LSP:    [R2->R6->R7->R4]
 
Regards
 
Defeng Li
--Boundary_(ID_tuKTfIhMl+MCqDRRp8PItw)-- --===============0232726241== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0232726241==-- From mpls-bounces@ietf.org Wed Nov 10 08:35:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06679; Wed, 10 Nov 2004 08:35:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRsdt-00021r-PB; Wed, 10 Nov 2004 08:36:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRsaJ-0008Le-Ip; Wed, 10 Nov 2004 08:32:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRsWz-00083T-EP for mpls@megatron.ietf.org; Wed, 10 Nov 2004 08:29:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06256 for ; Wed, 10 Nov 2004 08:28:59 -0500 (EST) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRsXs-0001ul-IJ for mpls@ietf.org; Wed, 10 Nov 2004 08:30:01 -0500 Received: from webmail.avici.com (mailhost.avici.com [127.0.0.1]) by mailhost.avici.com (8.12.8/8.12.8) with SMTP id iAADRGnh018477; Wed, 10 Nov 2004 08:27:16 -0500 Received: from 10.2.2.223 (SquirrelMail authenticated user pbeeram) by webmail.avici.com with HTTP; Wed, 10 Nov 2004 08:27:16 -0500 (EST) Message-ID: <37170.10.2.2.223.1100093236.squirrel@webmail.avici.com> In-Reply-To: <00ca01c4c6fd$6dae1fd0$07436e0a@l04955> References: <00ca01c4c6fd$6dae1fd0$07436e0a@l04955> Date: Wed, 10 Nov 2004 08:27:16 -0500 (EST) Subject: Re: [mpls] Question about draft-ietf-mpls-rsvp-lsp-fastreroute-07 From: "Vishnu Pavan Beeram" To: "lidefeng" <77cronux.leed0621@huawei.com> User-Agent: SquirrelMail/1.4.0-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Avici-MailScanner-Information: Please contact the ISP for more information X-Avici-MailScanner: Found to be clean X-Spam-Score: 0.8 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Defeng Li, It is not the upstream "node" along the primary path that needs to be avoided. It is the upstream "link" in the same direction that needs to be avoided. The upstream link can be used in the reverse direction. As the text in the draft says, this is done to avoid sharing resources between the backup and the primary. Consider the following fig.. F ------- G | | | | A -- B -- C -- D -- E | | | | | | H -- I ------------ K Primary LSP : A-B-C-D-E Valid Backup(s) at PLR, C : C-B-I-K-E (or) C-G-F-A-H-I-K-E Invalid Backup at PLR, C : C-G-F-A-B-I-K-E [Link A-B cannot be used] -Pavan > In section "7.2 Procedures for Backup Path Computation", it states that: > > "Before CSPF computation, the following information should be collected at > a PLR: > -... > -... > - The upstream uni-directional links that the protected LSP > passes through. This information is learned from the > RECORD_ROUTE objects; it is only needed for setting up > one-to-one protection. In the path-specific method, it is > necessary to avoid the detour and the protected LSP sharing > a common next-hop upstream of the failure. In the > sender-template-specific mode, this same restriction is > necessary to avoid sharing bandwidth between the detour and > its protected LSP, where that bandwidth has only been reserved > once." > > My question is > (a) In the following diagram,if failure is R3 node, then next-hop upstream > of the failure is R2,right? > (b) if (a) is right? why should we avoid avoid the detour and the > protected LSP sharing a common next-hop upstream of the failure in > path-specific method and in sender-template-specific mode? and in the > following diagram, Protected LSP is [R1->R2->R3->R4->R5]. Detour LSP is > [R2->R6->R7->R4], they share the common next-hop upstream of the failure > when R3 is failure, is it a contradiction? > > L32 L33 L34 L35 > R1-------R2-------R3-------R4-------R5 > | | > L46 | L47 | L44 > R6---------------R7 > > Protected LSP: [R1->R2->R3->R4->R5] > Detour LSP: [R2->R6->R7->R4] > > Regards > > Defeng Li > _______________________________________________ > 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@ietf.org Wed Nov 10 12:29:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03780; Wed, 10 Nov 2004 12:29:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRwJB-0008Db-Q0; Wed, 10 Nov 2004 12:31:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRwAc-0006Od-Cp; Wed, 10 Nov 2004 12:22:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRw8r-0005LX-Rn; Wed, 10 Nov 2004 12:20:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02755; Wed, 10 Nov 2004 12:20:18 -0500 (EST) From: neil.2.harrison@bt.com Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRw9r-0007wd-Bp; Wed, 10 Nov 2004 12:21:24 -0500 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Wed, 10 Nov 2004 17:20:57 +0000 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 10 Nov 2004 17:20:56 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.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] BFD For MPLS LSPs Date: Wed, 10 Nov 2004 17:20:56 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A353890A9F146E@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: [mpls] BFD For MPLS LSPs Thread-Index: AcTGrHPkn/ntaNxgSS2nSORQXxPaCwAWvhhg To: , X-OriginalArrivalTime: 10 Nov 2004 17:20:56.0870 (UTC) FILETIME=[A3D98C60:01C4C749] X-Spam-Score: 0.3 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: quoted-printable Cc: mpls@ietf.org, rtg-bfd@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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: quoted-printable Nurit.....Here are my observations on your questions and Tom's additional remarks. > On Nov 9, 2004, at 4:35 PM, Nurit Sprecher wrote: >=20 > =09 > > 2. It looks like being companion to the ITU-T OAM=20 > mechanism defined > > for the MPLS. >=20 > Which ITU OAM mechanism are you referring to? NH=3D> I can only assume you mean Y.1711? Though Y.1710 sets the requirements. >=20 > > 4. Is it compliant to the requirements for the MPLS OAM? >=20 > Yes, I think so. Many of the same authors worked on both. NH=3D> No it is not IMO.....but then this depends what the requirements are for and who is defining these. I have seen misinformation presented about Y.1711 in the past, and maybe this has tainted some folks views. I don't how many folks have read this stuff, and even if they have whether they have really grokked many of the nuances that it covers. Y.1711 is about the most minimalist automatic defect detection/handling OAM solution for the co-ps mode. Further, all defects are defined in terms of entry/exit criteria and consequent actions, and careful thought has been applied to relating defects and (un)availability. There is some other stuff I'll come back to in a momemnt (as to why Y.1711 has the correct behaviour vs BFD) but I want to make an important related observation first: The functional components of networks in general (not just OAM, but signalling etc) have a best-of-breed solution in each of the 3 networks modes, and they should therefore be similar irrespective of the particular technology considered (they have been different in the past as each technology that comes along thinks it knows best....this leads to the stovepipe 'technology=3Dservice' problem). The functional components *cannot* however be identical across all the 3 modes, because each mode has fundamental and important differences (and its these differences are the things that are 'good', but in any case they cannot be ignored). For example, let's look at some key differences between GMPLS (co-cs forwarding mode) and MPLS (co-ps forwarding mode): - the co-cs mode forces control/management OOB wrt traffic in GMPLS.....not true in MPLS - the co-cs mode will not allow you to break the connectivity rules of co trails in GMPLS, ie no mp2p is possible even if you try it.....not true in some forms of MPLS, and PHP also causes a similar merging behaviour. - the co-cs mode means there are no QoS/traffic classes in GMPLS (this is actually a far more important observation than some may think).....not true in MPLS - the co-cs mode forces a fixed/known hierarchy in the data-plane of GMPLS, this means one can still get full functional decoupling between layer networks (important for commercial client/server functional decoupling between operators, and also important for scaling/stability).....not true in MPLS, this is a 'digital wrapper'. So, as we can see there are some pretty fundamental important differences in the above. The defect detection/handling requirements for both the co-cs mode and co-ps mode data-planes are actually quite similar, but the differences of the modes means their defects are different. That is (under an assumption of a defect-free control-plane): The only possible defects in the co-cs mode are breaks and swaps between *exactly alike* trails. In the co-ps mode we can get breaks, swaps (between any trails) and various types of mis-branching/merging. For comparison, the cl-ps mode can only ever have breaks. Why so? Well each/every pkt in the cl-ps mode carried its own Connectivity Verification (CV) function (ie SA). In the co-ps and co-cs mode we have to add the CV function in the data-plane in some deterministic way. This is easy in the co-cs mode as the period is determined by the frame/multiframe structure, eg check out the J0 byte (which is like an IP pkt SA function) in an SDH VC4. In Y.1711 a periodic CV pkt carries the SA of the LSP. Worth noting here that we really need a consistent method of source addressing of LSPs so that on swaps/mismerges the offending LSP can be easily identified. I note BFD is now proposing something similar (not quite the same) wrt to the discriminator field. As noted this should be an LSP source address and it should be the same no matter how the LSP is instantiated. Now a few other requirements: - the OAM must be in the data-plane....esp vital when the control/management-plane is OOB, like it is in GMPLS - the OAM must be activated/deactiviated in concert with whatever sets-up/tears-down the LSP, else we are going to get operational problems. I believe BFD suggests using LSP-Ping for this. This is wrong (ie a heavyweight diagnostic OAM tool invoking a lightweight fault detection tool?!), as it still needs synch'ing with whatever is the real set-up/tear-down mechanism, eg signalling or management. - OAM must be unidirectional. This is important for several reasons, 2 keys ones are: * the defects must be detected/handled at the LSP sink so the relevent consequent actions can be taken in the right place, eg suppress traffic, send FDI to clients, etc * in p2mp constructions any server layer failures (ie in whatever is below the p2mp MPLS layer considered) must result in FDI being sent down the affected parts of the (client MPLS) tree towards the sink....where they then take the consequenct actions noted above but only at the affected sink points. You can't really do any of this very well with something that has a bi-directional behaviour like BFD. >=20 > > 5. Is it a reasonable solution? >=20 > I think so. 8) NH=3D> Well, it's starting to look more like Y.1711......some way to go yet as noted above. As noted earlier, the *functional requirements* here remain the same whatever we call it. Though is does beg the question of why re-invent the wheel? regards, Neil >=20 > --Tom >=20 >=20 > > > > Thanks, > > > > Nurit, > > _______________________________________________ > > mpls mailing list > > mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls >=20 >=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@ietf.org Wed Nov 10 12:49:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05437; Wed, 10 Nov 2004 12:49:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRwbp-00008J-85; Wed, 10 Nov 2004 12:50:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRwUs-0001pO-0f; Wed, 10 Nov 2004 12:43:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRwPi-000143-W9 for mpls@megatron.ietf.org; Wed, 10 Nov 2004 12:37:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04681 for ; Wed, 10 Nov 2004 12:37:43 -0500 (EST) Received: from mx2.nyu.edu ([128.122.109.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRwQh-0008OK-UH for mpls@ietf.org; Wed, 10 Nov 2004 12:38:49 -0500 Received: from shreyas.nyu.edu (PANDITS.SLPA.ED.NYU.EDU [128.122.26.146]) by mx2.nyu.edu (8.12.10/8.12.10) with ESMTP id iAAHbCNk027707 for ; Wed, 10 Nov 2004 12:37:13 -0500 (EST) Message-Id: <6.0.1.1.2.20041110123427.0219bbd0@mail.stealth.net> X-Sender: sp543@pop.nyu.edu X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 10 Nov 2004 12:35:08 -0500 To: mpls@ietf.org From: SP Subject: RE: [mpls] what routing protocols have what to do with QoS? In-Reply-To: <0536FC9B908BEC4597EE721BE6A353890A9F146E@i2km07-ukbr.domai n1.systemhost.net> References: <0536FC9B908BEC4597EE721BE6A353890A9F146E@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.9 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 what routing protocols have what to do with QoS? I mean distance vector and link state IGP protocols are just how the routers discuss cost of paths and update each others routing tables. The main ones used for cisco are IGRP, and EIGRP... The QoS is mainly layer 2 to layer 4, with GoS and ToS. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Nov 10 12:51:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05718; Wed, 10 Nov 2004 12:51:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRweV-0000Ap-DL; Wed, 10 Nov 2004 12:53:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRwUt-0001q0-HB; Wed, 10 Nov 2004 12:43:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRwQW-00017h-Gc for mpls@megatron.ietf.org; Wed, 10 Nov 2004 12:38:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04761 for ; Wed, 10 Nov 2004 12:38:33 -0500 (EST) Received: from mx3.nyu.edu ([128.122.109.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRwRU-0008PA-JG for mpls@ietf.org; Wed, 10 Nov 2004 12:39:38 -0500 Received: from shreyas.nyu.edu (PANDITS.SLPA.ED.NYU.EDU [128.122.26.146]) by mx3.nyu.edu (8.12.10/8.12.10) with ESMTP id iAAHc2n3002367 for ; Wed, 10 Nov 2004 12:38:03 -0500 (EST) Message-Id: <6.0.1.1.2.20041110123526.0219ebd0@pop.nyu.edu> X-Sender: sp543@pop.nyu.edu X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 10 Nov 2004 12:36:01 -0500 To: mpls@ietf.org From: SP Subject: RE: [mpls] Pseudo Wire Emulation Edge to Edge (pwe3) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.9 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 does anyone know of any equipment that implements this technology? http://www.ietf.org/html.charters/pwe3-charter.html _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Nov 10 16:28:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06552; Wed, 10 Nov 2004 16:28:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS02L-00080t-FT; Wed, 10 Nov 2004 16:29:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRzu0-0005DD-JT; Wed, 10 Nov 2004 16:21:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRzjm-0008Vp-Aa for mpls@megatron.ietf.org; Wed, 10 Nov 2004 16:10:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03196 for ; Wed, 10 Nov 2004 16:10:39 -0500 (EST) Received: from mx1.nyu.edu ([128.122.109.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRzkn-0007LQ-Tc for mpls@ietf.org; Wed, 10 Nov 2004 16:11:46 -0500 Received: from shreyas.nyu.edu (PANDITS.SLPA.ED.NYU.EDU [128.122.26.146]) by mx1.nyu.edu (8.12.10/8.12.10) with ESMTP id iAAIDnru004747 for ; Wed, 10 Nov 2004 13:13:50 -0500 (EST) Message-Id: <6.0.1.1.2.20041110130928.021d42f0@mail.stealth.net> X-Sender: sp543@pop.nyu.edu X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 10 Nov 2004 13:11:49 -0500 To: mpls@ietf.org From: SP Subject: RE: [mpls] IPv6 qos versus IPv4 QOS In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.9 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de thanks... also does any one have info on IPv6 qos versus IPv4 QOS? also is IP over ATM picking up as the future of QoS, or is MLPS over ethernet the future? _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Nov 10 17:57:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14419; Wed, 10 Nov 2004 17:57:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS1Q8-0001Uj-Tq; Wed, 10 Nov 2004 17:58:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS1IY-0006y7-Lc; Wed, 10 Nov 2004 17:50:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS1E3-0005zc-Vw for mpls@megatron.ietf.org; Wed, 10 Nov 2004 17:46:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13471 for ; Wed, 10 Nov 2004 17:46:01 -0500 (EST) Received: from pop-a065d10.pas.sa.earthlink.net ([207.217.121.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS1F4-0001Ew-My for mpls@ietf.org; Wed, 10 Nov 2004 17:47:09 -0500 Received: from user-38lc0rh.dialup.mindspring.com ([209.86.3.113] helo=earthlink.net) by pop-a065d10.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1CS1Dm-0007g3-00; Wed, 10 Nov 2004 14:45:47 -0800 Message-ID: <41929A3F.BE62DF3B@earthlink.net> Date: Wed, 10 Nov 2004 14:46:23 -0800 From: Erblichs X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: SP Subject: Re: [mpls] what routing protocols have what to do with QoS? References: <0536FC9B908BEC4597EE721BE6A353890A9F146E@i2km07-ukbr.domain1.systemhost.net> <6.0.1.1.2.20041110123427.0219bbd0@mail.stealth.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit SP, OSPFv2, a link state protocol used to have support for QOS, but that was never widely used. One admistrator of a domain may set router path costs within that domain based on delay or other metrics. If one looks at QOS in a granular way, one may set the cost very high with the assumption that their is a alternate path with a lower summed cost. This would in effectly generate a lower loading on the dst paths that are NOT transiting this path. Thus, the dst based paths would get a higher quality of service. However, if you are looking to guarantee a service level of service as a load increases this won't help. Mitchell Erblich ---------------------- SP wrote: > > what routing protocols have what to do with QoS? > > I mean distance vector and link state IGP protocols are just how the > routers discuss cost of paths and update each others routing tables. > > The main ones used for cisco are IGRP, and EIGRP... > The QoS is mainly layer 2 to layer 4, with GoS and ToS. > > _______________________________________________ > 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@ietf.org Wed Nov 10 19:17:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20966; Wed, 10 Nov 2004 19:17:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS2fp-0002tq-9U; Wed, 10 Nov 2004 19:18:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS2c6-0001q4-6Q; Wed, 10 Nov 2004 19:14:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS2Wq-00017D-1Y for mpls@megatron.ietf.org; Wed, 10 Nov 2004 19:09:32 -0500 Received: from ms-smtp-01.rdc-nyc.rr.com (ms-smtp-01-smtplb.rdc-nyc.rr.com [24.29.109.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20558 for ; Wed, 10 Nov 2004 19:09:26 -0500 (EST) Received: from Area-51.nyu.edu (68-175-79-94.nyc.rr.com [68.175.79.94]) by ms-smtp-01.rdc-nyc.rr.com (8.12.10/8.12.7) with ESMTP id iAB09Q6n005374 for ; Wed, 10 Nov 2004 19:09:27 -0500 (EST) Message-Id: <6.0.1.1.2.20041110190915.01fc5258@mail.stealth.net> X-Sender: sp543@mail.stealth.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 10 Nov 2004 19:09:25 -0500 To: mpls@ietf.org From: SP Subject: Re: [mpls] Pseudo Wire Emulation Edge to Edge (pwe3) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: Symantec AntiVirus Scan Engine 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 What Cisco Series Routers/Switches is PWE3 supported on? At 01:13 PM 11/10/2004, you wrote: >Cisco offers PWE3 services using either L2TPv3 or MPLS (aka AToM). >L2TPv3 is used for networks with no MPLS or non-contiguous MPLS clouds. >AToM is used on contiguous MPLS clouds. Pseudowire support for FR, >Ethernet, HDLC, PPP, ATM, VLAN, etc. Take your pick. > >Scott Wainner >Distinguished Systems Engineer >Cisco Systems >Mobile and Inter-Exchange Carrier Sales >(703) 484-5820 > >SP wrote: > >>does anyone know of any equipment that implements this technology? >>http://www.ietf.org/html.charters/pwe3-charter.html >> >> >> >>_______________________________________________ >>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@ietf.org Wed Nov 10 20:14:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26723; Wed, 10 Nov 2004 20:14:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS3YZ-0004KO-2m; Wed, 10 Nov 2004 20:15:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS3Pq-0003nP-Ev; Wed, 10 Nov 2004 20:06:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS3H1-0001JA-BP for mpls@megatron.ietf.org; Wed, 10 Nov 2004 19:57:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24999 for ; Wed, 10 Nov 2004 19:57:13 -0500 (EST) 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.33) id 1CS3I5-0003ne-4G for mpls@ietf.org; Wed, 10 Nov 2004 19:58:21 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 10 Nov 2004 17:08:37 -0800 Received: from fargo.cisco.com (fargo.cisco.com [171.70.170.202]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iAB0ufcp027517; Wed, 10 Nov 2004 16:56:41 -0800 (PST) Received: from dbokolaptop (rtp-vpn1-456.cisco.com [10.82.225.200]) by fargo.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id QAA00311; Wed, 10 Nov 2004 16:56:39 -0800 (PST) Message-Id: <200411110056.QAA00311@fargo.cisco.com> From: "Dmitry Bokotey" To: "'SP'" , Subject: RE: [mpls] Pseudo Wire Emulation Edge to Edge (pwe3) Date: Wed, 10 Nov 2004 18:56:38 -0600 Organization: Cisco Systems, Inc MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <6.0.1.1.2.20041110190915.01fc5258@mail.stealth.net> Thread-Index: AcTHg/K3Zl8IxpLRSiiO3DsPgifTqQABQ8Ig X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbokotey@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit L2TPv3 we support in 1700/3700/7200/7500/10720/12000 AToM support starting from. 7200/7500/10720/6500/7600/12000 platform Hope this helps. ======================================================================= | Dmitry Bokotey - CCIE No. 4460 | Network Consulting Eng Cisco Systems, Inc. | US AS Central Engineering | +1 408 853 0322 - office || || | +1 408 859 2538 - mobile .||. .||. | +1 815 377 6986 - e-Fax .||||. .||||. | +1 888 701 4592 - Pager Number .:||||||||:.:||||||||:. | 4088592538@mobile.att.net Cell Page Are you Ready ? | E-page dbokotey@epage.cisco.com | http://people.cisco.com/dbokotey "MPLS" ======================================================================= "There are two kinds of people, those who do the work and those who take the credit.Try to be in the first group; there is less competition there." -----Original Message----- From: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org] On Behalf Of SP Sent: Wednesday, November 10, 2004 6:09 PM To: mpls@ietf.org Subject: Re: [mpls] Pseudo Wire Emulation Edge to Edge (pwe3) What Cisco Series Routers/Switches is PWE3 supported on? At 01:13 PM 11/10/2004, you wrote: >Cisco offers PWE3 services using either L2TPv3 or MPLS (aka AToM). >L2TPv3 is used for networks with no MPLS or non-contiguous MPLS clouds. >AToM is used on contiguous MPLS clouds. Pseudowire support for FR, >Ethernet, HDLC, PPP, ATM, VLAN, etc. Take your pick. > >Scott Wainner >Distinguished Systems Engineer >Cisco Systems >Mobile and Inter-Exchange Carrier Sales >(703) 484-5820 > >SP wrote: > >>does anyone know of any equipment that implements this technology? >>http://www.ietf.org/html.charters/pwe3-charter.html >> >> >> >>_______________________________________________ >>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@ietf.org Wed Nov 10 23:54:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13940; Wed, 10 Nov 2004 23:54:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS702-0008TM-Va; Wed, 10 Nov 2004 23:55:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS6tI-0003I2-NK; Wed, 10 Nov 2004 23:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS6nA-00020C-QF for mpls@megatron.ietf.org; Wed, 10 Nov 2004 23:42:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13239 for ; Wed, 10 Nov 2004 23:42:37 -0500 (EST) Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS6oG-0008Fi-0T for mpls@ietf.org; Wed, 10 Nov 2004 23:43:48 -0500 Received: from default.mail.com (unknown[130.129.96.160]) by comcast.net (rwcrmhc13) with SMTP id <2004111104420401500la6v0e> (Authid: agmalis@comcast.net); Thu, 11 Nov 2004 04:42:05 +0000 Message-Id: <6.1.2.0.2.20041110233630.05aaaae0@mail.comcast.net> X-Sender: vivacenet\amalis@po1.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 10 Nov 2004 23:41:57 -0500 To: SP From: "Andrew G. Malis" Subject: RE: [mpls] Pseudo Wire Emulation Edge to Edge (pwe3) In-Reply-To: <6.0.1.1.2.20041110123526.0219ebd0@pop.nyu.edu> References: <6.0.1.1.2.20041110123526.0219ebd0@pop.nyu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 A large number of vendors have implemented PWE3 over MPLS, and there's been extensive interoperability testing. See the following for descriptions of the testing: http://www.mplsforum.org/tech/superdemo_2003.pdf http://www.mplsforum.org/tech/MPLSWC2004-WhitePaper-1.1.pdf http://www.mplsforum.org/tech/superdemo_2004.pdf At 11/10/2004 12:36 PM -0500, SP wrote: >does anyone know of any equipment that implements this technology? >http://www.ietf.org/html.charters/pwe3-charter.html Cheers, Andy _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Nov 11 08:37:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09560; Thu, 11 Nov 2004 08:37:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSFAB-00026k-0V; Thu, 11 Nov 2004 08:39:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSF51-0003Oc-2e; Thu, 11 Nov 2004 08:33:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSF0P-0002nv-9e for mpls@megatron.ietf.org; Thu, 11 Nov 2004 08:28:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08779 for ; Thu, 11 Nov 2004 08:28:52 -0500 (EST) Received: from imo-d02.mx.aol.com ([205.188.157.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSF1T-0001tV-LQ for mpls@ietf.org; Thu, 11 Nov 2004 08:30:06 -0500 Received: from ewgray2k@netscape.net by imo-d02.mx.aol.com (mail_out_v37_r3.8.) id l.2.f03e871 (22683) for ; Thu, 11 Nov 2004 08:28:13 -0500 (EST) Received: from [172.16.1.47] ([12.150.188.130]) by air-in04.mx.aol.com (v103.7) with ESMTP id MAILININ44-589b419368e7147; Thu, 11 Nov 2004 08:28:10 -0500 Message-ID: <419368E4.4070201@netscape.net> Date: Thu, 11 Nov 2004 08:28:04 -0500 From: Eric W Gray User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: mpls@ietf.org References: In-Reply-To: X-AOL-IP: 12.150.188.130 X-Mailer: Unknown (No Version) X-Spam-Score: 1.5 (+) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Subject: [mpls] Re: mpls post from shreyas@stealth.net requires approval X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ewgray@GraIyMage.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1744326415==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 1.5 (+) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f --===============1744326415== Content-Type: multipart/alternative; boundary="------------020605050609090401090402" --------------020605050609090401090402 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Forwarded on behalf of Shreyas Pandit. > > Subject: > Re: [mpls] Pseudo Wire Emulation Edge to Edge (pwe3) > From: > Shreyas Pandit > Date: > Wed, 10 Nov 2004 18:11:02 -0500 > To: > Scott Wainner > > To: > Scott Wainner > CC: > mpls@ietf.org > > > > What Cisco Series Routers/Switches is PWE3 supported on? > > > At 01:13 PM 11/10/2004, you wrote: > >> Cisco offers PWE3 services using either L2TPv3 or MPLS (aka AToM). >> L2TPv3 is used for networks with no MPLS or non-contiguous MPLS clouds. >> AToM is used on contiguous MPLS clouds. Pseudowire support for FR, >> Ethernet, HDLC, PPP, ATM, VLAN, etc. Take your pick. >> >> Scott Wainner >> Distinguished Systems Engineer >> Cisco Systems >> Mobile and Inter-Exchange Carrier Sales >> (703) 484-5820 >> >> SP wrote: >> >>> does anyone know of any equipment that implements this technology? >>> http://www.ietf.org/html.charters/pwe3-charter.html >>> >>> >>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/mpls >>> > > > > > ------------------------------------------------------------------------ > > Subject: > confirm 25844c6b31d511a165eac58d7117678372fc9053 > From: > mpls-request@lists.ietf.org > > >If you reply to this message, keeping the Subject: header intact, >Mailman will discard the held message. Do this if the message is >spam. If you reply to this message and include an Approved: header >with the list password in it, the message will be approved for posting >to the list. The Approved: header can also appear in the first line >of the body of the reply. > > --------------020605050609090401090402 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Forwarded on behalf of Shreyas Pandit.

Subject:
Re: [mpls] Pseudo Wire Emulation Edge to Edge (pwe3)
From:
Shreyas Pandit <shreyas@stealth.net>
Date:
Wed, 10 Nov 2004 18:11:02 -0500
To:
Scott Wainner <swainner@cisco.com>
To:
Scott Wainner <swainner@cisco.com>
CC:
mpls@ietf.org


What Cisco Series Routers/Switches is PWE3 supported on?


At 01:13 PM 11/10/2004, you wrote:
Cisco offers PWE3 services using either L2TPv3 or MPLS (aka AToM).
L2TPv3 is used for networks with no MPLS or non-contiguous MPLS clouds.
AToM is used on contiguous MPLS clouds.   Pseudowire support for FR, Ethernet, HDLC, PPP, ATM, VLAN, etc.  Take your pick.

Scott Wainner
Distinguished Systems Engineer
Cisco Systems
Mobile and Inter-Exchange Carrier Sales
(703) 484-5820

SP wrote:

does anyone know of any equipment that implements this technology?
http://www.ietf.org/html.charters/pwe3-charter.html



_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls






Subject:
confirm 25844c6b31d511a165eac58d7117678372fc9053
From:
mpls-request@lists.ietf.org		 

If you reply to this message, keeping the Subject: header intact,
Mailman will discard the held message.  Do this if the message is
spam.  If you reply to this message and include an Approved: header
with the list password in it, the message will be approved for posting
to the list.  The Approved: header can also appear in the first line
of the body of the reply.
--------------020605050609090401090402-- --===============1744326415== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1744326415==-- From mpls-bounces@ietf.org Thu Nov 11 15:08:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19688; Thu, 11 Nov 2004 15:08:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSLGd-0003B6-5I; Thu, 11 Nov 2004 15:10:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSLAK-0002pj-NB; Thu, 11 Nov 2004 15:03:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSKzP-00054a-AM for mpls@megatron.ietf.org; Thu, 11 Nov 2004 14:52:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17249; Thu, 11 Nov 2004 14:52:09 -0500 (EST) Received: from mail.ietf61.org ([130.129.16.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSL0Y-0002hG-VL; Thu, 11 Nov 2004 14:53:27 -0500 Received: from [130.129.133.152] (helo=[127.0.0.1]) by MAIL.ietf61.org with esmtp (Exim 4.24; FreeBSD) id 1CSKy3-0003S9-Bs; Thu, 11 Nov 2004 14:50:51 -0500 Message-ID: <4193C2A3.9080702@pi.se> Date: Thu, 11 Nov 2004 20:50:59 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexa Morris References: <200410071543.i97FhVOE013263@puddle.amsl.com> In-Reply-To: <200410071543.i97FhVOE013263@puddle.amsl.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: rcheruku@cisco.com, Bill Fenner , statements@ietf.org, mpls@ietf.org Subject: [mpls] Response to communication from MPLS & Frame Relay Alliance on RFC 3036 Proposed Revisions 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Please find the response to the communication from the MPLS & Frame Relay Alliance on RFC 3036 revisions included. ------------------- To: Rao Cherukuri MPLS & Frame Relay Alliance Technical Committee Chair RE: Communication of October 7th 2004 to the MPLS working group in IETF from the MPLS & Frame Alliance Dear Rao, thanks for the communication of October 7th 2004 from the MPLS & Frame Relay Alliance on the deprecation of the Host Address FEC TLV from the LDP specification as it is moved to Draft Standard. The MPLS Working Group in the IETF is interested in establishing open and trustful communication with the MPLS & Frame Relay Alliance. From our point of view it is important that such communication is based on a mutual understanding of the position of the organizations. We see the MFA as a potentially very interesting and competent source for requirements on the MPLS and GMPLS protocols, while the working groups could facilitate extensions and improvements that meets these requirements. It should also be agreed that the IETF is the only organization that could make changes and extensions to the MPLS and GMPLS protocols. We would also like to point out that the process on how changes and extensions to the MPLS and GMPLS protocols shall be managed is under discussion in the IETF Routing Area, including how input for such changes and extensions shall be received from sources outside the IETF. The MPLS Working Group is in the process of progressing the LDP specification from Proposed to Draft Standard. The IETF procedure for Draft Standards, requires that only those portions of a Proposed Standard which have been implemented and used operationally may be advanced. The Host Address FEC was discussed at the MPLS working group meeting in Washington DC on November 9th 2004. The consensus of the working group is that the Host Address FEC will be removed. As far as we know the Host Address FEC has not been used. Any information to the contrary would be useful. At the same time it was pointed at that it is possible for the MFA could request a new FEC. If the MFA wanted to keep the same value for the this new FEC as for the Host Address FEC, this could be done following the process for changing MPLS and GMPLS protocols, which is currently under discussion in the IETF Routing Area. The process involves sending an Internet-Draft describing the problem, which will be reviewed by the MPLS Working Group and the IESG before the WG considers the solution. The MPLS WG chairs stand ready to help in the request process to meet the need for a timely allocation of a new FEC to meet the MFA needs. Loa Andersson and George Swallow MPLS Working Group co-chairs -- 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@ietf.org Thu Nov 11 22:22:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02578; Thu, 11 Nov 2004 22:22:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSS2r-00058d-ME; Thu, 11 Nov 2004 22:24:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSRys-0004lA-SF; Thu, 11 Nov 2004 22:20:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSRy8-0004cc-QY for mpls@megatron.ietf.org; Thu, 11 Nov 2004 22:19:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02169 for ; Thu, 11 Nov 2004 22:19:22 -0500 (EST) Received: from ms-smtp-02-smtplb.rdc-nyc.rr.com ([24.29.109.6] helo=ms-smtp-02.rdc-nyc.rr.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSRzQ-000553-MP for mpls@ietf.org; Thu, 11 Nov 2004 22:20:44 -0500 Received: from Area-51.nyu.edu (68-175-79-94.nyc.rr.com [68.175.79.94]) by ms-smtp-02.rdc-nyc.rr.com (8.12.10/8.12.7) with ESMTP id iAC3JLBO021833 for ; Thu, 11 Nov 2004 22:19:21 -0500 (EST) Message-Id: <6.0.1.1.2.20041111221812.0216de50@mail.stealth.net> X-Sender: sp543@mail.stealth.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 11 Nov 2004 22:19:22 -0500 To: mpls@ietf.org From: SP Subject: Re: [mpls] what routing protocols have what to do with QoS? In-Reply-To: <41929A3F.BE62DF3B@earthlink.net> References: <0536FC9B908BEC4597EE721BE6A353890A9F146E@i2km07-ukbr.domain1.systemhost.net> <6.0.1.1.2.20041110123427.0219bbd0@mail.stealth.net> <41929A3F.BE62DF3B@earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.9 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 What layer is MPLS? since MPLS over ip over ethernet... and since ip over ethernet (layer 3 over layer 2)... _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Nov 12 10:01:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08801; Fri, 12 Nov 2004 10:01:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CScwX-00021E-Jh; Fri, 12 Nov 2004 10:02:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CScsS-0005Y6-Nb; Fri, 12 Nov 2004 09:58:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CScij-00039q-NP for mpls@megatron.ietf.org; Fri, 12 Nov 2004 09:48:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07721 for ; Fri, 12 Nov 2004 09:48:11 -0500 (EST) Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSck7-0001h4-PD for mpls@ietf.org; Fri, 12 Nov 2004 09:49:40 -0500 Received: from [192.168.0.4] (pcp09296126pcs.arlngt01.va.comcast.net[69.143.165.226]) by comcast.net (sccrmhc11) with ESMTP id <2004111214473701100od4rle>; Fri, 12 Nov 2004 14:47:38 +0000 Mime-Version: 1.0 X-Sender: hcb8@smtp.comcast.net Message-Id: In-Reply-To: <6.0.1.1.2.20041111221812.0216de50@mail.stealth.net> References: <0536FC9B908BEC4597EE721BE6A353890A9F146E@i2km07-ukbr.domain1.systemhost.n et> <6.0.1.1.2.20041110123427.0219bbd0@mail.stealth.net> <41929A3F.BE62DF3B@earthlink.net> <6.0.1.1.2.20041111221812.0216de50@mail.stealth.net> Date: Fri, 12 Nov 2004 09:47:12 -0500 To: mpls@ietf.org From: "Howard C. Berkowitz" Subject: Re: [mpls] what routing protocols have what to do with QoS? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 At 10:19 PM -0500 11/11/04, SP wrote: >What layer is MPLS? > >since MPLS over ip over ethernet... >and since ip over ethernet (layer 3 over layer 2)... > > Older layering models (e.g., the ISO 7498 basic OSI Refernence Model approved in 1984) are obsolete for discussing modern stacks. If you want ISO/OSI references, I would suggest reading the OSI supplemental report on the Internal Organization of the Network Layer. Unfortunately, as far as I know, ISO only sells it online. Alteratively, look at some of the sub-IP temporary area architectural discussions in the IETF. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Nov 12 16:27:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01374; Fri, 12 Nov 2004 16:27:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSiyl-00082N-Gg; Fri, 12 Nov 2004 16:29:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSilj-0002s7-3p; Fri, 12 Nov 2004 16:15:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSiWz-0003kx-SW for mpls@megatron.ietf.org; Fri, 12 Nov 2004 16:00:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22067 for ; Fri, 12 Nov 2004 16:00:27 -0500 (EST) Received: from natint3.juniper.net ([66.129.224.36] helo=kummer.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSiYQ-0005Nt-Fq for mpls@ietf.org; Fri, 12 Nov 2004 16:01:59 -0500 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id iACKxvDU006594; Fri, 12 Nov 2004 12:59:57 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id iACKxvqI006591; Fri, 12 Nov 2004 12:59:57 -0800 (PST) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Fri, 12 Nov 2004 12:59:57 -0800 (PST) From: Kireeti Kompella To: SP Subject: Re: [mpls] what routing protocols have what to do with QoS? In-Reply-To: <6.0.1.1.2.20041111221812.0216de50@mail.stealth.net> Message-ID: <20041112125356.G6396@kummer.juniper.net> References: <0536FC9B908BEC4597EE721BE6A353890A9F146E@i2km07-ukbr.domain1.systemhost.net> <6.0.1.1.2.20041110123427.0219bbd0@mail.stealth.net> <41929A3F.BE62DF3B@earthlink.net> <6.0.1.1.2.20041111221812.0216de50@mail.stealth.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On Thu, 11 Nov 2004, SP wrote: > since MPLS over ip over ethernet... > and since ip over ethernet (layer 3 over layer 2)... Let MPLS be Layer N. By the above, N > 3. You can also carry Ethernet over MPLS, Hence, 2 > N. Therefore, 2 > 3. QED. Hope that helps :-) Kireeti. ------- _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Sat Nov 13 18:11:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09264; Sat, 13 Nov 2004 18:11:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CT759-00085u-0S; Sat, 13 Nov 2004 18:13:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CT6q2-00066F-Rv; Sat, 13 Nov 2004 17:57:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CT6hh-0004cM-TC for mpls@megatron.ietf.org; Sat, 13 Nov 2004 17:49:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07511 for ; Sat, 13 Nov 2004 17:49:08 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CT6jM-000794-MG for mpls@ietf.org; Sat, 13 Nov 2004 17:50:54 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id iADMmb944711; Sat, 13 Nov 2004 14:48:37 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id iADMmWe62859; Sat, 13 Nov 2004 14:48:32 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200411132248.iADMmWe62859@merlot.juniper.net> To: Kireeti Kompella Subject: Re: [mpls] what routing protocols have what to do with QoS? In-Reply-To: Your message of "Fri, 12 Nov 2004 12:59:57 PST." <20041112125356.G6396@kummer.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18982.1100386112.1@juniper.net> Date: Sat, 13 Nov 2004 14:48:32 -0800 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Kireeti, > On Thu, 11 Nov 2004, SP wrote: > > > since MPLS over ip over ethernet... > > and since ip over ethernet (layer 3 over layer 2)... > > Let MPLS be Layer N. > > By the above, N > 3. > > You can also carry Ethernet over MPLS, > > Hence, 2 > N. > > Therefore, 2 > 3. QED. > > Hope that helps :-) Just to help more, here are few points from one of my presentations on (G)MPLS: (G)MPLS is not a Network Layer on its own, as it does not have routing and addressing on its own - it uses IP addressing + IP routing (with extensions) (G)MPLS is not a Link Layer because MPLS works over various Link Layer technologies (e.g., SONET, Ethernet, ATM, etc.) (G)MPLS is not a Layer in the OSIRM (OSI Reference Model) sense as it does not have a single format for transport of the data from the layer above (e.g., (G)MPLS uses "shim" on SONET, VCI/VPI on ATM, time slot on TDM, lambda on OXC, etc...). Yakov. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Sat Nov 13 18:49:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11999; Sat, 13 Nov 2004 18:49:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CT7fb-0001MD-Nq; Sat, 13 Nov 2004 18:51:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CT7TG-0001mm-NM; Sat, 13 Nov 2004 18:38:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CT7AC-0007MC-D6 for mpls@megatron.ietf.org; Sat, 13 Nov 2004 18:18:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10334 for ; Sat, 13 Nov 2004 18:18:32 -0500 (EST) Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CT7Bp-0008M2-3i for mpls@ietf.org; Sat, 13 Nov 2004 18:20:18 -0500 Received: from [192.168.0.4] (pcp09296126pcs.arlngt01.va.comcast.net[69.143.165.226]) by comcast.net (rwcrmhc12) with ESMTP id <2004111323175701400qqfnhe> (Authid: hcb8); Sat, 13 Nov 2004 23:17:57 +0000 Mime-Version: 1.0 X-Sender: hcb8@smtp.comcast.net Message-Id: In-Reply-To: <200411132248.iADMmWe62859@merlot.juniper.net> References: <200411132248.iADMmWe62859@merlot.juniper.net> Date: Sat, 13 Nov 2004 18:17:19 -0500 To: mpls@ietf.org From: "Howard C. Berkowitz" Subject: Re: [mpls] what routing protocols have what to do with QoS? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa At 2:48 PM -0800 11/13/04, Yakov Rekhter wrote: >Kireeti, > >> On Thu, 11 Nov 2004, SP wrote: >> >> > since MPLS over ip over ethernet... >> > and since ip over ethernet (layer 3 over layer 2)... >> >> Let MPLS be Layer N. >> >> By the above, N > 3. >> >> You can also carry Ethernet over MPLS, >> >> Hence, 2 > N. >> >> Therefore, 2 > 3. QED. >> >> Hope that helps :-) > >Just to help more, here are few points from one of my presentations >on (G)MPLS: > >(G)MPLS is not a Network Layer on its own, as it does not have routing >and addressing on its own - it uses IP addressing + IP routing (with >extensions) > >(G)MPLS is not a Link Layer because MPLS works over various Link Layer >technologies (e.g., SONET, Ethernet, ATM, etc.) > >(G)MPLS is not a Layer in the OSIRM (OSI Reference Model) sense as it >does not have a single format for transport of the data from the >layer above (e.g., (G)MPLS uses "shim" on SONET, VCI/VPI on ATM, time >slot on TDM, lambda on OXC, etc...). > >Yakov. To be excessively pedantic, could (G)MPLS not be either a subnetwork access protocol, or perhaps even a control plane for subnetwork access, under the OSI Internal Organization of the Network Layer definition? _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Sat Nov 13 19:05:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12926; Sat, 13 Nov 2004 19:05:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CT7va-00020d-7f; Sat, 13 Nov 2004 19:07:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CT7lL-0004RB-LZ; Sat, 13 Nov 2004 18:56:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CT7cA-0002xB-9g for mpls@megatron.ietf.org; Sat, 13 Nov 2004 18:47:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11909 for ; Sat, 13 Nov 2004 18:47:27 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CT7dn-0001F4-41 for mpls@ietf.org; Sat, 13 Nov 2004 18:49:14 -0500 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iADNjqO02924; Sat, 13 Nov 2004 18:45:52 -0500 (EST) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 13 Nov 2004 18:45:52 -0500 Message-ID: From: "Peter Ashwood-Smith" To: "'Yakov Rekhter'" , Kireeti Kompella Subject: RE: [mpls] what routing protocols have what to do with QoS? Date: Sat, 13 Nov 2004 18:45:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c 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: , Content-Type: multipart/mixed; boundary="===============0186939398==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 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. --===============0186939398== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C9DA.E7313CD6" 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. ------_=_NextPart_001_01C4C9DA.E7313CD6 Content-Type: text/plain I like Kireeti's better ;) ... I'm reminded of that wonderful chapter in Hitch Hiker's guide ... Hopefully MPLS won't disappear in a 'puff of logic' ;) I used to present MPLS as an L3 protocol controlling an L2.5 data path. I.e. between Ethernet and IP. GMPLS was described as an L3 protocol controlling an L0(lambda) or L1(TDM) data path. Many people get confused by this separation of control/data plane when learning about (G)MPLS. Peter -----Original Message----- From: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org] Sent: Saturday, November 13, 2004 5:49 PM To: Kireeti Kompella Cc: mpls@ietf.org Subject: Re: [mpls] what routing protocols have what to do with QoS? Kireeti, > On Thu, 11 Nov 2004, SP wrote: > > > since MPLS over ip over ethernet... > > and since ip over ethernet (layer 3 over layer 2)... > > Let MPLS be Layer N. > > By the above, N > 3. > > You can also carry Ethernet over MPLS, > > Hence, 2 > N. > > Therefore, 2 > 3. QED. > > Hope that helps :-) Just to help more, here are few points from one of my presentations on (G)MPLS: (G)MPLS is not a Network Layer on its own, as it does not have routing and addressing on its own - it uses IP addressing + IP routing (with extensions) (G)MPLS is not a Link Layer because MPLS works over various Link Layer technologies (e.g., SONET, Ethernet, ATM, etc.) (G)MPLS is not a Layer in the OSIRM (OSI Reference Model) sense as it does not have a single format for transport of the data from the layer above (e.g., (G)MPLS uses "shim" on SONET, VCI/VPI on ATM, time slot on TDM, lambda on OXC, etc...). Yakov. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls ------_=_NextPart_001_01C4C9DA.E7313CD6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [mpls] what routing protocols have what to do with QoS? =

I like Kireeti's better ;) ... I'm reminded of that = wonderful chapter in Hitch Hiker's guide ... Hopefully MPLS won't = disappear in a 'puff of logic' ;)

I used to present MPLS as an L3 protocol controlling = an L2.5 data path.
I.e. between Ethernet and IP.

GMPLS was described as an L3 protocol controlling an = L0(lambda) or L1(TDM) data path.

Many people get confused by this separation of = control/data plane when learning about (G)MPLS.

Peter


-----Original Message-----
From: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ie= tf.org]
Sent: Saturday, November 13, 2004 5:49 PM
To: Kireeti Kompella
Cc: mpls@ietf.org
Subject: Re: [mpls] what routing protocols have what = to do with QoS?


Kireeti,

> On Thu, 11 Nov 2004, SP wrote:
>
> > since MPLS over ip over ethernet...
> > and since ip over ethernet (layer 3 over = layer 2)...
>
> Let MPLS be Layer N.
>
> By the above, N > 3.
>
> You can also carry Ethernet over MPLS,
>
> Hence, 2 > N.
>
> Therefore, 2 > 3.  QED.
>
> Hope that helps :-)

Just to help more, here are few points from one of my = presentations on (G)MPLS:

(G)MPLS is not a Network Layer on its own, as it does = not have routing and addressing on its own - it uses IP addressing + IP = routing (with

extensions)

(G)MPLS is not a Link Layer because MPLS works over = various Link Layer technologies (e.g., SONET, Ethernet, ATM, = etc.)

(G)MPLS is not a Layer in the OSIRM (OSI Reference = Model) sense as it does not have a single format for transport of the = data from the layer above (e.g., (G)MPLS uses "shim" on = SONET, VCI/VPI on ATM, time slot on TDM, lambda on OXC, = etc...).

Yakov.

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls=

------_=_NextPart_001_01C4C9DA.E7313CD6-- --===============0186939398== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0186939398==-- From mpls-bounces@ietf.org Mon Nov 15 04:31:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10423; Mon, 15 Nov 2004 04:31:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTdEb-00036b-1I; Mon, 15 Nov 2004 04:33:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTd9l-0001E6-FA; Mon, 15 Nov 2004 04:28:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTd8X-0001At-8N for mpls@megatron.ietf.org; Mon, 15 Nov 2004 04:27:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10268 for ; Mon, 15 Nov 2004 04:26:59 -0500 (EST) From: neil.2.harrison@bt.com Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTdAV-00032r-23 for mpls@ietf.org; Mon, 15 Nov 2004 04:29:03 -0500 Received: from i2km97-ukbr.domain1.systemhost.net ([193.113.197.30]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Mon, 15 Nov 2004 09:27:37 +0000 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km97-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 15 Nov 2004 09:27:36 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.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] what routing protocols have what to do with QoS? Date: Mon, 15 Nov 2004 09:27:35 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A353890A9F149E@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: [mpls] what routing protocols have what to do with QoS? Thread-Index: AcTI/o2dnbdH+NiJT6+0debgZrTO4QB8js9A To: , X-OriginalArrivalTime: 15 Nov 2004 09:27:36.0272 (UTC) FILETIME=[57D6F500:01C4CAF5] X-Spam-Score: 0.3 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable Kireeti...what a lovely demonstration of the meaningless L1, L2, L3 classification. The only classification that makes any sense is the modal one, ie co-cs, co-ps and cl-ps.....and then an understanding that these modes are not the same, so any '1 size fits all' treatment across all modes makes no sense. Indeed, it is the differences that are the important bits......not sure many folks get this however. All these modes are 'peer L3 networks' in the unreal and restricted OSI 'L3 network layer' view of the networking world. BTW - There are no QoS classes in the co-cs mode.....this is one of its key defining differences. Some others are: - control/management must be OOB....this is not an option in this mode - can't violate the connectivity constraints of the co mode, ie merging is simply not possible here - one always has a fixed/known hierarchy in the data-plane...so one can force functional decoupling between layer networks. All of these are very important properties of the co-cs mode......you don't find them *forced* in the cl-ps mode, and because of this one can sure screw them up in the co-ps mode. If anyone is wondering 'why' this is, it is down to the nature of how the link-connections are defined/manifested in the co-cs mode, ie here they must take on a real/physical property of either time, space or frequency and the bit-rate must be fixed at a known value (cf the co-ps mode where the link-connection IDs are simply abstract 'numbers'). Further: - given a network layer N inherits the performance of the layer N-1 network (ie link-connections in layer N are provided by trails in Layer N-1....theis is the fundamental property (in G.805) that defines layer N topology creation); - this is a recursive behaviour to the duct; - there are (currently at least) no rules for governing what client/server relationship can exist between pairs of modes (there are 9 permutations); - there are no rules govening *how many* client/server instances can exist in an instantiation of a network arch that delivers some end-system application (ie right at the top of the stack); .......then its clear that trying to define any end-end network performance objectives and then trying to apportion these to partitions of this (eg operator domains) in any meaningful/fair manner seems an impossible task at the current time. Thus, any talk of 'QoS' is also a rather meaningless exercise. BTW - If folks were more familar with functional architecture (ie G.805/809 stuff) all the above would be obvious....I saw some of the later posts and its clear to me folks are very confused about layer networks. Very seriously....please have a look at chapter 3 of Reid/Sexton ('BB networking') as this will help. regards, Neil > -----Original Message----- > From: mpls-bounces@lists.ietf.org=20 > [mailto:mpls-bounces@lists.ietf.org] On Behalf Of Kireeti Kompella > Sent: 12 November 2004 21:00 > To: SP > Cc: mpls@ietf.org > Subject: Re: [mpls] what routing protocols have what to do with QoS? >=20 >=20 > On Thu, 11 Nov 2004, SP wrote: >=20 > > since MPLS over ip over ethernet... > > and since ip over ethernet (layer 3 over layer 2)... >=20 > Let MPLS be Layer N. >=20 > By the above, N > 3. >=20 > You can also carry Ethernet over MPLS, >=20 > Hence, 2 > N. >=20 > Therefore, 2 > 3. QED. >=20 > Hope that helps :-) >=20 > Kireeti. > ------- >=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@ietf.org Mon Nov 15 07:28:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20445; Mon, 15 Nov 2004 07:28:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTg09-0005n1-PO; Mon, 15 Nov 2004 07:30:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTfuj-00013F-Sc; Mon, 15 Nov 2004 07:24:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTfuV-00010y-Bt for mpls@megatron.ietf.org; Mon, 15 Nov 2004 07:24:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20222 for ; Mon, 15 Nov 2004 07:24:42 -0500 (EST) From: neil.2.harrison@bt.com Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTfwU-0005im-R4 for mpls@ietf.org; Mon, 15 Nov 2004 07:26:47 -0500 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Mon, 15 Nov 2004 12:25:16 +0000 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 15 Nov 2004 12:25:16 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.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] what routing protocols have what to do with QoS? Date: Mon, 15 Nov 2004 12:25:15 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A353890A9F14A5@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: [mpls] what routing protocols have what to do with QoS? Thread-Index: AcTJ1ohx7httBx09TMOBvrIvhoFydgBL1pIg To: , X-OriginalArrivalTime: 15 Nov 2004 12:25:16.0424 (UTC) FILETIME=[29C91080:01C4CB0E] X-Spam-Score: 0.3 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Yakov, >=20 > Just to help more, here are few points from one of my=20 > presentations on (G)MPLS: >=20 > (G)MPLS is not a Network Layer on its own, as it does not=20 > have routing and addressing on its own - it uses IP=20 > addressing + IP routing (with > extensions) NH=3D> You talk of addressing here Yakov and yes we can use IP (v4 or = v6) structured addresses all over the place....does not mean to say they belong to an IP layer network however. For example, I can use IP v4 structured addressing for an SDH VC4 access point and an SDH VC12 access point (or the access points in any other layer network for that matter)......but I for sure cannot connect these together as they belong to different layer networks. {A layer network is characterised by the set of addressable access points which can be connected together.} Addressing is bound to access points. So even if folks use the same addressing format they come from difference spaces. Further, and as folks have discovered with GMPLS, or more accurately due to the co-cs mode, the traffic data-plane network (co-cs) must be disjoint from the control (or management) data-plane network (which in all probability uses the cl-ps mode). These 2 (at least) networks in the same technology (say SDH) have quite different addressing requirements. >=20 > (G)MPLS is not a Link Layer because MPLS works over various=20 > Link Layer technologies (e.g., SONET, Ethernet, ATM, etc.) NH=3D> (The control-plane of) GMPLS looks like it does because of the co-cs mode. The co-cs mode forces certain things on the network design: - there are no QoS classes in the co-cs mode - the control/management protocols must be run OOB wrt the traffic in the co-cs mode....rather an attractive consequence for many reasons, esp security. - the connectivity requirements of the co mode cannot be violated, ie no mp2p allowed.....this also means the defects are different to either the cl-ps or co-ps modes - the traffic data-plane must retain a fixed/known hierarchy in the co-cs mode. Now a word on MPLS is important here. The 'shim' of MPLS creates a digital wrapper behaviour in the data-plane of the co-ps mode, ie there is no fixed/known hierarchy. This is really neat in some respects (esp OAM) but it does create some issues when we want to run an MPLS network belonging to one operator over an MPLS network belonging to another operator and retain full commercial/functional isolation. This is not a problem in GMPLS.....but its not because this was an a priori design criteria of GMPLS, its a forced imposition of the co-cs mode. So from a data-plane viewpoint GMPLS and MPLS are not at all alike. >=20 > (G)MPLS is not a Layer in the OSIRM (OSI Reference Model)=20 > sense as it does not have a single format for transport of=20 > the data from the layer above (e.g., (G)MPLS uses "shim" on=20 > SONET, VCI/VPI on ATM, time slot on TDM, lambda on OXC, etc...). NH=3D> The OSIRM is not a reflection of reality. It has, however, led = to a great deal of confusion since folks think there is only ever 1 'network layer'. There are lots of network layers (or more accurately layer networks), and the only thing that roughly classifies them in any sensible way is whether technology X belongs to the cl-ps mode, the co-ps mode or the co-cs mode....and its is the differences in the modal behaviours that are the important bits. IMO functional convergence within a mode makes a great deal of sense, but not across them (esp when we need to take the commercial operating requirements of carriers into account). regards, Neil _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Nov 16 10:35:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10424; Tue, 16 Nov 2004 10:35:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU5OR-0008J2-2J; Tue, 16 Nov 2004 10:37:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU594-0001k3-CR; Tue, 16 Nov 2004 10:21:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU4wq-0005Mb-QY for mpls@megatron.ietf.org; Tue, 16 Nov 2004 10:08:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05842 for ; Tue, 16 Nov 2004 10:08:47 -0500 (EST) Received: from web60903.mail.yahoo.com ([216.155.196.79]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CU4z3-0007ca-0n for mpls@ietf.org; Tue, 16 Nov 2004 10:11:06 -0500 Received: (qmail 8298 invoked by uid 60001); 16 Nov 2004 15:08:12 -0000 Message-ID: <20041116150812.8296.qmail@web60903.mail.yahoo.com> Received: from [202.144.106.188] by web60903.mail.yahoo.com via HTTP; Tue, 16 Nov 2004 15:08:12 GMT Date: Tue, 16 Nov 2004 15:08:12 +0000 (GMT) From: Spice Sylvia Subject: Re: [mpls] what routing protocols have what to do with QoS? To: mpls@ietf.org In-Reply-To: <6.0.1.1.2.20041111221812.0216de50@mail.stealth.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.1 (+) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 8bit 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 8bit Hi SP, If you need it I could send you a small stack which tunnels anything in HTTP. It is automagically bidirectional :) (ofcourse one side has to initiate the connection) and it also traverses any proxy (including content filters) --- SP wrote: > What layer is MPLS? > > since MPLS over ip over ethernet... > and since ip over ethernet (layer 3 over layer 2)... > > > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > ___________________________________________________________ Win a castle for NYE with your mates and Yahoo! Messenger http://uk.messenger.yahoo.com _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Nov 16 17:05:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25670; Tue, 16 Nov 2004 17:05:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUBUR-00037y-TC; Tue, 16 Nov 2004 17:07:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUAi1-0001Cm-8O; Tue, 16 Nov 2004 16:17:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUAdn-0007W6-EU; Tue, 16 Nov 2004 16:13:31 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14685; Tue, 16 Nov 2004 16:13:29 -0500 (EST) Message-Id: <200411162113.QAA14685@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 16 Nov 2004 16:13:29 -0500 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-oam-frmwk-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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --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 : A Framework for MPLS Operations and Management (OAM) Author(s) : D. Allan, T. Nadeau Filename : draft-ietf-mpls-oam-frmwk-00.txt Pages : 10 Date : 2004-11-16 This document is a framework for how data plane OAM functions can be applied to operations and maintenance procedures. The document is structured to outline how OAM functionality can be used to assist in fault management, configuration, accounting, performance management and security, commonly known by the acronym FCAPS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-oam-frmwk-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-oam-frmwk-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-oam-frmwk-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: <2004-11-16113051.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-oam-frmwk-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-oam-frmwk-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-16113051.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@ietf.org Tue Nov 16 17:07:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26390; Tue, 16 Nov 2004 17:07:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUBVu-0003HW-Sn; Tue, 16 Nov 2004 17:09:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUAi5-0001IR-3n; Tue, 16 Nov 2004 16:17:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUAdr-0007Xo-FT; Tue, 16 Nov 2004 16:13:35 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14698; Tue, 16 Nov 2004 16:13:33 -0500 (EST) Message-Id: <200411162113.QAA14698@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 16 Nov 2004 16:13:33 -0500 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-rsvp-te-p2mp-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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 --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-00.txt Pages : 45 Date : 2004-11-16 This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the setup of 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-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-rsvp-te-p2mp-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-rsvp-te-p2mp-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: <2004-11-16113057.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-rsvp-te-p2mp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-rsvp-te-p2mp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-16113057.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@ietf.org Tue Nov 16 17:10:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27448; Tue, 16 Nov 2004 17:10:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUBZX-0003YH-8e; Tue, 16 Nov 2004 17:13:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUAi8-0001JW-NP; Tue, 16 Nov 2004 16:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUAdu-0007ZE-Rc; Tue, 16 Nov 2004 16:13:38 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14706; Tue, 16 Nov 2004 16:13:37 -0500 (EST) Message-Id: <200411162113.QAA14706@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 16 Nov 2004 16:13:37 -0500 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-bundle-05.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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --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 : Link Bundling in MPLS Traffic Engineering Author(s) : K. Kompella, et al. Filename : draft-ietf-mpls-bundle-05.txt Pages : 11 Date : 2004-11-16 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 defined in [RFC3471]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-bundle-05.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-bundle-05.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-bundle-05.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: <2004-11-16113102.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-bundle-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-bundle-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-16113102.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@ietf.org Wed Nov 17 06:37:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15772; Wed, 17 Nov 2004 06:37:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUO9z-0006bd-1O; Wed, 17 Nov 2004 06:39:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUO50-0004Z9-Bh; Wed, 17 Nov 2004 06:34:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUO4B-0004PL-2O for mpls@megatron.ietf.org; Wed, 17 Nov 2004 06:33:39 -0500 Received: from apollo.serverbox.net (apollo.serverbox.net [207.58.128.75]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA15491 for ; Wed, 17 Nov 2004 06:33:35 -0500 (EST) Received: (qmail 14692 invoked from network); 17 Nov 2004 11:33:35 -0000 Received: from unknown (HELO PC.opalsoft.net) (201.243.149.192) by apollo.serverbox.net with SMTP; 17 Nov 2004 11:33:35 -0000 Message-Id: <6.1.2.0.0.20041117072427.028839b0@opalsoft.net> X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 17 Nov 2004 07:35:47 -0400 To: Mpls list From: Leonardo Balliache Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [mpls] Label number mapping 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Hi, all. Perhaps I'm missing something but I've got a question about mpls. Should there be some previous agreement between lsr about label numbers to be mapped and flooded? If so, where the specs talk about this? Have a look to the following scenario; let's suppose we are using unsolicited ordered control: a ------ x ------ y ------- b 1.- x and y are mpls lsr. 2.- x is egress for a then it maps label 1 to fec a, install it for forwarding and advertise this map to y. 3.- y is egress for b then it maps label 1 to fec b, install it for forwarding and advertise this map to x. 4.- x tries to install mapping 1-b received from y. 5.- y tries to install mapping 1-a received from x. 6.- Then both lsr could have the same label "1" mapped to two different fecs: a and b. Is this possible? Is there something I haven't understand yet? Best regards, Leonardo Balliache _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Nov 17 14:26:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02154; Wed, 17 Nov 2004 14:26:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUVUY-0001Ar-Bc; Wed, 17 Nov 2004 14:29:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUVKZ-0004UN-DB; Wed, 17 Nov 2004 14:19:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUVF4-0003ts-BV for mpls@megatron.ietf.org; Wed, 17 Nov 2004 14:13:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00654 for ; Wed, 17 Nov 2004 14:13:20 -0500 (EST) Received: from pop-a065c32.pas.sa.earthlink.net ([207.217.121.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUVHU-0000q4-CC for mpls@ietf.org; Wed, 17 Nov 2004 14:15:55 -0500 Received: from user-2ivfiku.dialup.mindspring.com ([165.247.202.158] helo=earthlink.net) by pop-a065c32.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1CUVEu-0006Uj-00 for mpls@ietf.org; Wed, 17 Nov 2004 11:13:12 -0800 Message-ID: <419BA1C8.D7192627@earthlink.net> Date: Wed, 17 Nov 2004 11:08:56 -0800 From: Erblichs X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 3.4 (+++) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Subject: [mpls] draft--rsvp-lsp-fastreroute-07.txt : LRT 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 3.4 (+++) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Hi group, Sorry for the LATE comments... A . Abstract Nit.. "in 10s of milliseconds" First, is 90ms the best case for a local re-route? This seems somewhat long and I missed the reasoning why it isn't closer to 1 ms.. Is the timeframe the amount of time that a LSR detects a link-failure? If the link-failure is via a IGP OSPF protocol (hello protocol), then its on the order of secs. If the two timeframes differ dramaticlly, should the more fine graular timeframe be communicated and the adj questioned? Else what would be the result of this level of time schizophrenia? B. 4 . Local Repair technique : 4.1 One-to-one backup First.. How do you know if the condition is link-local or effecting the entire node? If it is a link-local condition, R3's backup could be R3-R8-R4. Yes??? FYI: If it isn't a link-local issue, then are all the the LSPs that transit the effected link aware of the node issue? Should they all revert to their backups?? C. 4.1 One-to-one backup This may be extending this somewhat but.. Why wouldn't/couldn't R1-R6-R7-R8-R9-R5 be a another primary established LSP, that is parallelling the R1->R5 protected LSP? Would it save anything if the merge was always at R5 once we go thru a Rx backup? D. 8.2 Handling Failures I am trying to determine whether to separate short-term link failures and whether their is/ should be any recorvery for these types of failures.. I am reading that this section assumes temporary failures due to the phrase "once the local link has recovered". Is this correct? Or should it be "If the local link has recovered..." "may not accept Path messages" Is this phrase telling us that the reliability is a consideration and that switching between protected and backup LSPs is not wanted? However, now I have read that we had detected a link failure with or without sending data thru a backup, and now might NOT accept the original protected LSP? Why wouldn't we want to accept Path messages? E. 8.2 Handling Failures "Path and Resv state MUST NOT be cleared" Why not? "and PathTear and ResvErr messages MUST NOT be sent immediately" Why wait and how long to wait? ------- Enough for me.. Mitchell Erblich _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Nov 17 14:36:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03454; Wed, 17 Nov 2004 14:36:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUVeK-0001OZ-Ob; Wed, 17 Nov 2004 14:39:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUVVr-00077k-H0; Wed, 17 Nov 2004 14:30:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUVMl-0004wO-OP for mpls@megatron.ietf.org; Wed, 17 Nov 2004 14:21:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01396 for ; Wed, 17 Nov 2004 14:21:18 -0500 (EST) Received: from pop-a065c32.pas.sa.earthlink.net ([207.217.121.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUVPE-000108-Pf for mpls@ietf.org; Wed, 17 Nov 2004 14:23:53 -0500 Received: from user-2ivfiku.dialup.mindspring.com ([165.247.202.158] helo=earthlink.net) by pop-a065c32.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1CUVMj-00029Z-00 for mpls@ietf.org; Wed, 17 Nov 2004 11:21:17 -0800 Message-ID: <419BA39F.9E8CCC8D@earthlink.net> Date: Wed, 17 Nov 2004 11:16:47 -0800 From: Erblichs X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@ietf.org References: <419BA1C8.D7192627@earthlink.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 3.4 (+++) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 7bit Subject: [mpls] Re: draft--rsvp-lsp-fastreroute-07.txt : LRT 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 3.4 (+++) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 7bit Sorry, Forgot about another item.. RFC3029 is Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols Thus,,, ZZ. 15. Normative References [RSVP] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP) -- version 1 functional specification," RFC2205, September 1997. [RSVP-TE] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP tunnels", RFC3029, December 2001. Is wrong... Mitchell Erblich ---------------------------- Erblichs wrote: > > Hi group, > > Sorry for the LATE comments... > > A . Abstract Nit.. > "in 10s of milliseconds" > > First, is 90ms the best case for a local > re-route? This seems somewhat long and I missed > the reasoning why it isn't closer to 1 ms.. > > Is the timeframe the amount of time that a LSR > detects a link-failure? If the link-failure is > via a IGP OSPF protocol (hello protocol), then its > on the order of secs. > > If the two timeframes differ dramaticlly, should > the more fine graular timeframe be communicated > and the adj questioned? Else what would be the > result of this level of time schizophrenia? > > B. 4 . Local Repair technique : 4.1 One-to-one backup > > First.. How do you know if the condition is link-local > or effecting the entire node? If it is a link-local > condition, R3's backup could be R3-R8-R4. Yes??? > FYI: If it isn't a link-local issue, then > are all the the LSPs that transit the effected > link aware of the node issue? Should they all > revert to their backups?? > > C. 4.1 One-to-one backup > > This may be extending this somewhat but.. > > Why wouldn't/couldn't R1-R6-R7-R8-R9-R5 be a another > primary established LSP, that is parallelling the R1->R5 > protected LSP? > > Would it save anything if the merge was always at R5 > once we go thru a Rx backup? > > D. 8.2 Handling Failures > > I am trying to determine whether to separate short-term > link failures and whether their is/ should be any > recorvery for these types of failures.. > > I am reading that this section assumes temporary > failures due to the phrase "once the local link has > recovered". Is this correct? > > Or should it be "If the local link has recovered..." > > "may not accept Path messages" Is this phrase telling > us that the reliability is a consideration and that > switching between protected and backup LSPs is not > wanted? > > However, now I have read that we had detected a > link failure with or without sending data thru > a backup, and now might NOT accept the original > protected LSP? Why wouldn't we want to accept Path > messages? > > > E. 8.2 Handling Failures > > "Path and Resv state MUST NOT be cleared" > > Why not? > > "and PathTear and ResvErr messages MUST NOT be > sent immediately" > > Why wait and how long to wait? > > ------- > > Enough for me.. > > Mitchell Erblich _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Nov 18 02:04:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10950; Thu, 18 Nov 2004 02:04:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUgNh-0001dw-IY; Thu, 18 Nov 2004 02:07:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUgCt-0005XN-Nw; Thu, 18 Nov 2004 01:55:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUgAB-0004vD-5g for mpls@megatron.ietf.org; Thu, 18 Nov 2004 01:53:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06967 for ; Thu, 18 Nov 2004 01:53:01 -0500 (EST) Received: from [61.144.161.54] (helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUgBj-0001NB-WF for mpls@ietf.org; Thu, 18 Nov 2004 01:55:42 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I7D00DKW3VC21@szxga02-in.huawei.com> for mpls@ietf.org; Thu, 18 Nov 2004 14:40:24 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar3 2004)) with ESMTP id <0I7D0001I3VC9W@szxga02-in.huawei.com> formpls@ietf.org; Thu, 18 Nov 2004 14:40:24 +0800 (CST) Received: from l04955 ([10.110.67.7]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar3 2004)) with ESMTPA id <0I7D00A053VCZO@szxml02-in.huawei.com> formpls@ietf.org; Thu, 18 Nov 2004 14:40:24 +0800 (CST) Date: Thu, 18 Nov 2004 14:42:42 +0800 From: lidefeng <77cronux.leed0621@huawei.com> Subject: Some questions:Re: [mpls] I-DACTION:draft-ietf-mpls-rsvp-te-p2mp-00.txt To: mpls@ietf.org Message-id: <00c601c4cd39$ce238200$07436e0a@l04955> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-imss-version: 2.007 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com References: <200411162113.QAA14698@ietf.org> X-Spam-Score: 0.9 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7BIT 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7BIT In section 3.4 of draft-ietf-mpls-rsvp-te-p2mp-00.txt, it says that "All LSRs need to process the ERO corresponding to the first P2P sub-LSP. A LSR needs to process a P2P sub-LSP descriptor for a subsequent P2P sub-LSP only if the first hop in the corresponding SERO is a local address of that LSR. The branch LSR that is the first hop of a SERO propagates the corresponding P2P sub-LSP downstream." Does it mean that an LSR received the Path message with one ERO and several SEROs, if all the SEROs don't include this particular LSR, this particular need't process all these SEROs? For example, In the case of the p2mp tree of figure 1 in draft-ietf-mpls-rsvp-te-p2mp-00.txt, LSR H encode the P2P sub-LSP explicit routes in the Path message sent to LSR I: P2P sub-LSP-Q: ERO = {I, M, Q}, P2P_SUB_LSP Object-Q, P2P sub-LSP-R: SERO = {Q, R}, P2P_SUB_LSP Object-R, then, LSR I need only process "P2P sub-LSP-Q: ERO = {I, M, Q}, P2P_SUB_LSP Object-Q,", needn't process "P2P sub-LSP-R: SERO = {Q, R}, P2P_SUB_LSP Object-R,"? if it is right, what is the justification to carry the SERO? And what does "The branch LSR that is the first hop of a SERO propagates the corresponding P2P sub-LSP downstream." mean? it means that LSR Q propagates the corresponding P2P sub-LSP downstream when LSR I receives the Path message sented by LSR H? and it is clear that at this time LSR Q doesn't receive the Path message yet, how can it propogate the P2P sub-LSP downstream? Or this sentence means something else? Regards Defeng Li ----- Original Message ----- From: To: Cc: Sent: Wednesday, November 17, 2004 5:13 AM Subject: [mpls] I-D ACTION:draft-ietf-mpls-rsvp-te-p2mp-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. > > Title : Extensions to RSVP-TE for Point to Multipoint TE LSPs > Author(s) : R. Aggarwal, et al. > Filename : draft-ietf-mpls-rsvp-te-p2mp-00.txt > Pages : 45 > Date : 2004-11-16 > > This document describes extensions to Resource Reservation Protocol - > Traffic Engineering (RSVP-TE) for the setup of 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-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-rsvp-te-p2mp-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-rsvp-te-p2mp-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. > -------------------------------------------------------------------------------- > _______________________________________________ > 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@ietf.org Thu Nov 18 03:07:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28380; Thu, 18 Nov 2004 03:07:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUhMu-00030V-8w; Thu, 18 Nov 2004 03:10:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUhI3-0005PH-50; Thu, 18 Nov 2004 03:05:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUhGw-00059N-Bq for mpls@megatron.ietf.org; Thu, 18 Nov 2004 03:04:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27920 for ; Thu, 18 Nov 2004 03:04:04 -0500 (EST) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUhJU-0002uj-RT for mpls@ietf.org; Thu, 18 Nov 2004 03:06:46 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id iAI83vd5020870; Thu, 18 Nov 2004 17:03:57 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id iAI83ukF021069; Thu, 18 Nov 2004 17:03:56 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id iAI83u9N021066; Thu, 18 Nov 2004 17:03:56 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id iAI83t00021898; Thu, 18 Nov 2004 17:03:55 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id iAI83t3w021893; Thu, 18 Nov 2004 17:03:55 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id iAI83tLJ002973; Thu, 18 Nov 2004 17:03:55 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id iAI83sDi005477; Thu, 18 Nov 2004 17:03:54 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (imc0.m.ecl.ntt.co.jp [129.60.5.141]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id iAI83siD005474; Thu, 18 Nov 2004 17:03:54 +0900 (JST) Received: from win-yasukawa.lab.ntt.co.jp by imc.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id RAA19209; Thu, 18 Nov 2004 17:03:54 +0900 (JST) Message-Id: <5.0.2.5.2.20041118164551.07259260@imc.m.ecl.ntt.co.jp> X-Sender: sy003@imc.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-J Date: Thu, 18 Nov 2004 17:17:09 +0900 To: lidefeng <77cronux.leed0621@huawei.com>, mpls@ietf.org From: Seisho Yasukawa Subject: Re: Some questions:Re:[mpls] I-DACTION:draft-ietf-mpls-rsvp-te-p2mp-00.txt In-Reply-To: <00c601c4cd39$ce238200$07436e0a@l04955> References: <200411162113.QAA14698@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Hi, Thank you for your comments. Please find my comments and answers belows. At 14:42 04/11/18 +0800, lidefeng wrote: >In section 3.4 of draft-ietf-mpls-rsvp-te-p2mp-00.txt, it says that "All >LSRs need to process the ERO corresponding to the first P2P sub-LSP. A >LSR needs to process a P2P sub-LSP descriptor for a subsequent P2P >sub-LSP only if the first hop in the corresponding SERO is a local address >of that LSR. The branch LSR that is the first hop of a SERO propagates the >corresponding P2P sub-LSP downstream." > >Does it mean that an LSR received the Path message with one ERO and >several SEROs, if all the SEROs don't include this particular LSR, this >particular need't process all these SEROs? No. Please see below marked **. We describe detail SEROs operation in section 6.2. " 6.2. Multiple P2P Sub-LSPs in one Path message [snip] All LSRs need to process, when it is present, the ERO corresponding to the first P2P sub-LSP. If one or more SEROs are present an ERO must be present. The first P2P sub-LSP is propagated in a Path message by each LSR along the explicit route specified by the ERO. A LSR needs to process a P2P sub-LSP descriptor for a subsequent P2P sub-LSP only if the first hop in the corresponding SERO is a local address of that LSR. *** If this is not the case the P2P sub-LSP descriptor is included in the Path message sent to LSR that is the next hop to reach the first hop in the SERO. This next hop is determined by using the ERO or other SEROs that encode the path to the SERO's first hop. If this is the case and the LSR is also the egress the P2P sub-LSP descriptor is not propagated downstream. If this is the case and the LSR is not the egress the P2P sub-LSP descriptor is included in a Path message sent to the next-hop determined from the SERO. Hence a branch LSR only propagates the relevant P2P sub-LSP descriptors on each downstream link. A P2P sub-LSP descriptor that is propagated on a downstream link only contains those P2P sub-LSPs that are routed using that link. This processing may result in a subsequent P2P sub-LSP in an incoming Path message to become the first P2P sub-LSP in an outgoing Path message. " >For example, In the case of the p2mp tree of figure 1 in >draft-ietf-mpls-rsvp-te-p2mp-00.txt, LSR H encode the P2P sub-LSP explicit >routes in the Path message sent to LSR I: > P2P sub-LSP-Q: ERO = {I, M, Q}, P2P_SUB_LSP Object-Q, > P2P sub-LSP-R: SERO = {Q, R}, P2P_SUB_LSP Object-R, > >then, LSR I need only process "P2P sub-LSP-Q: ERO = {I, M, Q}, >P2P_SUB_LSP Object-Q,", needn't process "P2P sub-LSP-R: SERO = {Q, R}, >P2P_SUB_LSP Object-R,"? if it is right, what is the justification to carry >the SERO? Please see above. >And what does "The branch LSR that is the first hop of a SERO propagates >the corresponding P2P sub-LSP downstream." mean? This is also described in above section. Actually a branch LSR is branch point(s) of the P2MP LSP. So it always guarantees existence of SERO(s) in our scheme. Therefore, in our scheme, branch node must 1) convert SERO(s) to ERO(s) 2) divide received SEROs into multiple SEROs which correspond to multiple downstream portion of sub P2MP LSPs. Note there are several schemes to divide SEROs information easily and we are now discussing these schemes. Hope above explanation would help your understanding. Regards, Seisho >it means that LSR Q propagates the corresponding P2P sub-LSP downstream >when LSR I receives the Path message sented by LSR H? and it is clear that >at this time LSR Q doesn't receive the Path message yet, how can it >propogate the P2P sub-LSP downstream? Or this sentence means something else? > >Regards > >Defeng Li > > > > >----- Original Message ----- >From: >To: >Cc: >Sent: Wednesday, November 17, 2004 5:13 AM >Subject: [mpls] I-D ACTION:draft-ietf-mpls-rsvp-te-p2mp-00.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Multiprotocol Label Switching > Working Group of the IETF. > > > > Title : Extensions to RSVP-TE for Point to Multipoint TE LSPs > > Author(s) : R. Aggarwal, et al. > > Filename : draft-ietf-mpls-rsvp-te-p2mp-00.txt > > Pages : 45 > > Date : 2004-11-16 > > > > This document describes extensions to Resource Reservation Protocol - > > Traffic Engineering (RSVP-TE) for the setup of 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-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-rsvp-te-p2mp-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-rsvp-te-p2mp-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. > > > > >-------------------------------------------------------------------------------- > > > > _______________________________________________ > > 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@ietf.org Thu Nov 18 17:18:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24673; Thu, 18 Nov 2004 17:18:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUue3-0000e2-Pj; Thu, 18 Nov 2004 17:20:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUuU0-0000YQ-C7; Thu, 18 Nov 2004 17:10:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUuGq-0003uT-7g for mpls@megatron.ietf.org; Thu, 18 Nov 2004 16:56:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22175 for ; Thu, 18 Nov 2004 16:56:49 -0500 (EST) Received: from father.pmc-sierra.com ([216.241.224.13] helo=father.pmc-sierra.bc.ca) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CUuJM-0008QQ-Um for mpls@ietf.org; Thu, 18 Nov 2004 16:59:40 -0500 Received: (qmail 19148 invoked by uid 101); 18 Nov 2004 21:56:04 -0000 Received: from unknown (HELO ogmios.pmc-sierra.bc.ca) (216.241.226.59) by father.pmc-sierra.com with SMTP; 18 Nov 2004 21:56:04 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogmios.pmc-sierra.bc.ca (8.12.9/8.12.7) with ESMTP id iAILu33R023662; Thu, 18 Nov 2004 13:56:04 -0800 Received: by bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id ; Thu, 18 Nov 2004 13:56:03 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE0115D2CA@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> From: Shahram Davari To: "'Leonardo Balliache'" , Mpls list Subject: RE: [mpls] Label number mapping Date: Thu, 18 Nov 2004 13:56:02 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 This is possible and very common. There is no need for any agreement or coordination. -Shahram > -----Original Message----- > From: mpls-bounces@lists.ietf.org > [mailto:mpls-bounces@lists.ietf.org]On > Behalf Of Leonardo Balliache > Sent: Wednesday, November 17, 2004 6:36 AM > To: Mpls list > Subject: [mpls] Label number mapping > > > Hi, all. > > Perhaps I'm missing something but I've got a question about mpls. > > Should there be some previous agreement between lsr about > label numbers to > be mapped and flooded? > If so, where the specs talk about this? > > Have a look to the following scenario; let's suppose we are using > unsolicited ordered control: > > a ------ x ------ y ------- b > > 1.- x and y are mpls lsr. > 2.- x is egress for a then it maps label 1 to fec a, install it for > forwarding and advertise this map to y. > 3.- y is egress for b then it maps label 1 to fec b, install it for > forwarding and advertise this map to x. > 4.- x tries to install mapping 1-b received from y. > 5.- y tries to install mapping 1-a received from x. > 6.- Then both lsr could have the same label "1" mapped to two > different > fecs: a and b. > > Is this possible? Is there something I haven't understand yet? > > Best regards, > > Leonardo Balliache > > > _______________________________________________ > 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@ietf.org Fri Nov 19 16:09:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20293; Fri, 19 Nov 2004 16:09:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVG3X-0000YT-UA; Fri, 19 Nov 2004 16:12:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVFQh-0006AJ-Mf; Fri, 19 Nov 2004 15:32:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVFD2-0003f8-4T; Fri, 19 Nov 2004 15:18:20 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09526; Fri, 19 Nov 2004 15:18:18 -0500 (EST) Message-Id: <200411192018.PAA09526@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 19 Nov 2004 15:18:18 -0500 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-oam-frmwk-01.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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --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 : A Framework for MPLS Operations and Management (OAM) Author(s) : D. Allan, T. Nadeau Filename : draft-ietf-mpls-oam-frmwk-01.txt Pages : 10 Date : 2004-11-19 This document is a framework for how data plane OAM functions can be applied to operations and maintenance procedures. The document is structured to outline how OAM functionality can be used to assist in fault management, configuration, accounting, performance management and security, commonly known by the acronym FCAPS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-oam-frmwk-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-oam-frmwk-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-oam-frmwk-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-19153257.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-oam-frmwk-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-oam-frmwk-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-19153257.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@ietf.org Sat Nov 20 12:42:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11187; Sat, 20 Nov 2004 12:42:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVZIe-0001le-In; Sat, 20 Nov 2004 12:45:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVYyX-0001Bl-7H; Sat, 20 Nov 2004 12:24:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVYsW-0007q2-0t for mpls@megatron.ietf.org; Sat, 20 Nov 2004 12:18:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09156 for ; Sat, 20 Nov 2004 12:18:24 -0500 (EST) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVYvQ-0001CL-OS for mpls@ietf.org; Sat, 20 Nov 2004 12:21:39 -0500 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by astro.systems.pipex.net (Postfix) with ESMTP id C1E2FE0003B4; Sat, 20 Nov 2004 17:17:40 +0000 (GMT) Received: from Puppy ([217.158.132.195] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 20 Nov 2004 17:17:39 +0000 Message-ID: <072401c4cf24$f2b161e0$749c9ed9@Puppy> From: "Adrian Farrel" To: , "Yakov Rekhter" , "'Kireeti Kompella'" Date: Sat, 20 Nov 2004 15:44:03 -0000 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: 20 Nov 2004 17:17:40.0441 (UTC) FILETIME=[D6E65C90:01C4CF24] X-Spam-Score: 2.9 (++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: ccamp@ops.ietf.org, mpls@ietf.org Subject: [mpls] New version of Bundling Draft 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Hi, Thank you for the new version of this draft. I assume that the changes are to address the issues raised at the MPLS WG meeting in Washington. Since the draft was already through WG and IETF last call, I wonder if you would be kind enough to summarize the issues you were addressing and what changes you made to the draft. Thanks, Adrian PS. A few nits. "Status of this Memo" and "Abstract" should not be numbered. "Specification of Requirements" is not now usually numbered. Abstract must not contain citations except through full naming. Notwithstanding RFC3471 section 4, I think you would be wise to enhance your use of "downstream data channel" etc. with some text like "i.e., from initiator to terminator" Section 4.2 Once a bundled link is determined to be alive, it can be advertised --->formatting Section 4.3 Although SHOULD NOT be used, when used, the type 5 TLV MUST NOT be "Although it SHOULD NOT" the first TLV in an IF_ID RSVP_HOP object or IF_ID TLV. Section 5.9 The Resource Classes for a bundled link are the same as those of the component link s. ---> formatting Section 8.1 [GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS Extensions in Support of Generalized MPLS", draft-ietf-ibis-gmpls- extensions-11.txt (work in progress) "ibis"? _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Nov 22 10:05:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05182; Mon, 22 Nov 2004 10:05:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWFoT-0000Kr-6h; Mon, 22 Nov 2004 10:09:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWFhd-0007zm-Lk; Mon, 22 Nov 2004 10:02:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWFcO-000663-BU for mpls@megatron.ietf.org; Mon, 22 Nov 2004 09:56:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04153 for ; Mon, 22 Nov 2004 09:56:38 -0500 (EST) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWFfr-0008Bq-CP for mpls@ietf.org; Mon, 22 Nov 2004 10:00:15 -0500 Received: from movaz-hw.movaz.com (movaz-hw.atlanta.movaz.com [172.16.8.183]) by jera.movaz.com (Postfix) with ESMTP id 13F4EFE1; Mon, 22 Nov 2004 09:56:08 -0500 (EST) Received: from lb.movaz.com (localhost [127.0.0.1]) by movaz-hw.movaz.com (Postfix) with ESMTP id 93965AFA3; Mon, 22 Nov 2004 09:56:04 -0500 (EST) Message-Id: <6.1.2.0.2.20041122095526.04564c00@mo-ex1> X-Sender: lb@mo-ex1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 22 Nov 2004 09:55:52 -0500 To: "Adrian Farrel" From: Lou Berger In-Reply-To: <072401c4cf24$f2b161e0$749c9ed9@Puppy> References: <072401c4cf24$f2b161e0$749c9ed9@Puppy> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ccamp@ops.ietf.org, "Berger, Lou" , mpls@ietf.org Subject: [mpls] Re: New version of Bundling Draft 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Adrian, Loa has asked for the same thing. We should have it out this week. Lou At 10:44 AM 11/20/2004, Adrian Farrel wrote: >Hi, > >Thank you for the new version of this draft. I assume that the changes are >to address the >issues raised at the MPLS WG meeting in Washington. > >Since the draft was already through WG and IETF last call, I wonder if you >would be kind >enough to summarize the issues you were addressing and what changes you >made to the draft. > >Thanks, >Adrian _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Nov 22 14:46:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07678; Mon, 22 Nov 2004 14:46:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWKCP-0000zs-Mb; Mon, 22 Nov 2004 14:50:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWK6g-0006kt-1i; Mon, 22 Nov 2004 14:44:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWK1y-0005sD-PU for mpls@megatron.ietf.org; Mon, 22 Nov 2004 14:39:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06775 for ; Mon, 22 Nov 2004 14:39:21 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWK5U-0008Q5-Dq for mpls@ietf.org; Mon, 22 Nov 2004 14:43:00 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id iAMJcoBm029502; Mon, 22 Nov 2004 11:38:50 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id iAMJcoe91197; Mon, 22 Nov 2004 11:38:50 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200411221938.iAMJcoe91197@merlot.juniper.net> To: "Adrian Farrel" Subject: [mpls] New version of Bundling Draft MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <94734.1101152330.1@juniper.net> Date: Mon, 22 Nov 2004 11:38:50 -0800 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ccamp@ops.ietf.org, mpls@ietf.org, lberger@movaz.com 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Adrian, > Thank you for the new version of this draft. I assume that the > changes are to address the issues raised at the MPLS WG meeting in > Washington. > > Since the draft was already through WG and IETF last call, I wonder > if you would be kind enough to summarize the issues you were > addressing and what changes you made to the draft. Here is the summary: draft-ietf-mpls-bundle-05.txt has been updated to reflect the comments made in the MPLS WG and on the list. The issues raised are: 1. Scope of component identifiers is open to interpretation (i.e., node vs link) 2. No way to specify different upstream and downstream components then using TLV types 1, 2 and 3 3. Ambiguity of contents of the IP address field in TLV types 3, 4, 5 4. Lack of IPv6 support for types 3, 4, and 5. 5. Ambiguity of when to use types 4 and 5 and when to use type 3. 6. No coverage of ERO and RRO implications These issues have been addressed in the following ways: Issue 1: The -05 document states that all component link TLV types have Node/IP scope Issue 2: -05 Tightly defines support for different components in each direction (for bidirectional LSPs, and for all TLV types) Issue 3: Format of the Value field for types 3, 4 and 5 now has the identical format as the contents of the C-Type 1 LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477]. Issue 4: Based on the previous change, support of IPv6 unnumbered components is now tied to, and the same as, the support of IPv6 unnumber TE links. Issue 5: -05 allows, but recommend against use of types 4 and 5 Issue 6: EROs, RROs remain out of scope of bundling document Current planned changes are: - Fix nits found by Adrian and Loa - Insert a Table of Contents - Section numbering will remain unchanged so as not to break any potentially existing references to the draft Yakov. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Nov 22 16:21:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20049; Mon, 22 Nov 2004 16:21:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWLgP-0006H0-Kz; Mon, 22 Nov 2004 16:25:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWL3A-0004tx-Qh; Mon, 22 Nov 2004 15:44:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWKxO-0001jn-Ja; Mon, 22 Nov 2004 15:38:42 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13055; Mon, 22 Nov 2004 15:38:41 -0500 (EST) Message-Id: <200411222038.PAA13055@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 22 Nov 2004 15:38:40 -0500 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-rfc3036bis-01.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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b --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-01.txt Pages : 162 Date : 2004-11-22 The architecture for Multi Protocol Label Switching (MPLS) is described in RFC 3031. 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-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-rfc3036bis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-rfc3036bis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-22160453.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-rfc3036bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-rfc3036bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-22160453.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@ietf.org Wed Nov 24 05:53:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08690; Wed, 24 Nov 2004 05:53:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWuqU-0003Cp-3l; Wed, 24 Nov 2004 05:57:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWujH-0005yJ-IA; Wed, 24 Nov 2004 05:50:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWuhB-0005HU-3g for mpls@megatron.ietf.org; Wed, 24 Nov 2004 05:48:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08207 for ; Wed, 24 Nov 2004 05:48:18 -0500 (EST) Received: from natint3.juniper.net ([66.129.224.36] helo=kummer.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWul1-00031m-PN for mpls@ietf.org; Wed, 24 Nov 2004 05:52:20 -0500 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id iAOAlnXg013762 for ; Wed, 24 Nov 2004 02:47:49 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id iAOAlnqX013759 for ; Wed, 24 Nov 2004 02:47:49 -0800 (PST) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Wed, 24 Nov 2004 02:47:49 -0800 (PST) From: Kireeti Kompella To: mpls@ietf.org Subject: Re: [mpls] I-D ACTION:draft-ietf-mpls-rfc3036bis-01.txt In-Reply-To: <200411222038.PAA13055@ietf.org> Message-ID: <20041124015259.Y13504@kummer.juniper.net> References: <200411222038.PAA13055@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Hi All, On Mon, 22 Nov 2004 Internet-Drafts@ietf.org wrote: > 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-01.txt > Pages : 162 > Date : 2004-11-22 Let me quote Thomas Narten on the use of "IETF consensus" (and to avoid quoting out of context, I quote at length at the end; you can look up the whole email on the ietf list): Thomas said: 'As one of the authors of RFC 2434 "Guidelines for Writing an IANA Considerations Section in RFCs", I have long regretted defining the term "IETF Consensus" as it is in that document.' I would *strongly* recommend against using "IETF consensus" in the LDP-bis Draft Standard document. Here's my take on the IANA considerations section: a) The first range should be allocated as Standards Track. Furthermore, stuff like "Message types in this range are part of the LDP base protocol." should be removed -- those not defined in this document are clearly not part of the base protocol. b) The Vendor-private space uses a vendor ID as administered by the IEEE. This is sub-optimal. There is a vendor ID (more accurately, enterprise ID, but just about every vendor has one) space administered by IANA; moreover, this is the ID of choice for other vendor-private spaces (cf. RFC 3936, and draft-kompella-ospf-iana-...) This was not my first choice, but rather the result of much discussion. Given that, if no one is using the LDP vendor private space today (and those who are are willing to change their implementation), it would be better to standardize on a common notion of "vendor ID". c) For the Experimental space, ideally one would cite RFC 3692 -- and recommend the procedures thereof. d) There is no reason to exhaust the entire space at this stage. For example, for the Message type space, one could use 0x0000 - 0x1fff for Standards Action, 0x3e00 to 0x3eff for Vendor private, and 0x3f00 - 0x3fff for Experimental. The rest can (and should, imo) be set aside, with the caveat that values from the reserved space cannot be allocated until there is a Standards Track or BCP RFC that defines the allocation policy for that range. There is no danger of 8000 Standards Action code points being used up in a hurry, given the glacial pace of Standards Track RFCs. On the other hand, the notions of Vendor Private and Experimental are fairly new, and who knows what other new types will come up that for which we might need an allocation range? e) I would *strongly* recommend against having a First-Come-First-Served range for the FEC Type name space. It is too small to frivolously waste, and FCFS is a dangerous policy [keep in mind 'teeth' and the (G)MPLS change process]. Kireeti. ------- Date: Wed, 29 Jan 2003 20:20:26 -0500 From: Thomas Narten To: RJ Atkinson Cc: Bob Braden , ietf@ietf.org, kireeti@juniper.net, iesg@ietf.org Subject: "IETF consensus" in IANA considerations [was Re: Last Call: CR-LDP Extensions for ASON to Informational ] RJ Atkinson writes: > On Thursday, Jan 23, 2003, at 17:54 America/Montreal, Bob Braden wrote: > > I interpret "IETF consensus" as meaning that at least a Last > > Call was conducted. To use any other interpretation seems to me to > > be dishonest. I guess I am agreeing with Kireeti. > [IAB hat off] > I agree with the above. IESG approval is not identical to IETF > consensus. If it were, the IETF community would not be giving such > vocal feedback about concerns with the IESG at the last 2 meetings > and on the ietf-problems mailing list, IMHO. As one of the authors of RFC 2434 "Guidelines for Writing an IANA Considerations Section in RFCs", I have long regretted defining the term "IETF Consensus" as it is in that document. 2434 says: > IETF Consensus - New values are assigned through the IETF > consensus process. Specifically, new assignments are made via > RFCs approved by the IESG. Typically, the IESG will seek > input on prospective assignments from appropriate persons > (e.g., a relevant Working Group if one exists). > > Examples: SMTP extensions [SMTP-EXT], BGP Subsequent Address > Family Identifiers [BGP4-EXT]. The intent of the above wording was to provide a way for documents to request that IANA only assign code points when there exists a document that gets published as an RFC. The wording above specifically does not say "Standards Track" RFC and was intented to include informational and experimental documents, whether from a WG or not. There is an alternate definition - "Standards Action" - that can be cited if IANA assignments are only to be made for Standards Track documents. I think intent of the above definition is fine. But naming the term "IETF Consensus" is obviously problematical and confusing, as there are many Info and Experimental RFCs for which there is nothing close to IETF consensus on, and no one would claim so. So, let's be clear that in the context of most of the discussion on this thread, folks seem to be applying their own definition of what "IETF Consensus" means when in fact the 2434 definition is what should be used, as is cited in the relevant IANA considerations section. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Nov 24 09:59:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00073; Wed, 24 Nov 2004 09:59:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWygH-0003KS-33; Wed, 24 Nov 2004 10:03:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWyUY-0001yD-NJ; Wed, 24 Nov 2004 09:51:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWySE-00019K-DQ for mpls@megatron.ietf.org; Wed, 24 Nov 2004 09:49:11 -0500 Received: from tbdns.testbed.local ([80.86.78.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29154 for ; Wed, 24 Nov 2004 09:49:07 -0500 (EST) Received: from [172.16.2.213] (gw.imc.kth.se [193.10.152.67]) (authenticated bits=0) by tbdns.testbed.local (8.12.8/8.12.8) with ESMTP id iAOEltjp008356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Nov 2004 15:47:56 +0100 Message-ID: <41A49F24.9060308@pi.se> Date: Wed, 24 Nov 2004 15:48:04 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: multipart/mixed; boundary="------------080004030503080907000404" Cc: Bill Fenner Subject: [mpls] preliminary minutes from MPLS meeting in DC 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 96e0f8497f38c15fbfc8f6f315bcdecb This is a multi-part message in MIME format. --------------080004030503080907000404 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit All, please find the preliminary minutes from the DC meeting included. Please send your comments to me. /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 --------------080004030503080907000404 Content-Type: text/plain; name="mpls_minutes.txt" Content-Disposition: inline; filename="mpls_minutes.txt" Content-Transfer-Encoding: 7bit MPLS WG Agenda for the Washington Meeting November 2004, 9.00 - 11.30 1. Agenda bashing Agenda accepted as proposed. Scribes: Markus and Dimitri 2. Working group status (20 min) - liaison from MPLS & Frame Relay Alliance on RFC 3036 The MPLS working group has recieved a comunication from the MPLS & Frame Relay Alliance (MFA) on RFC 3036 as it is being progressed to draft standard. It was pointed out that IETF and/or its working groups do not enter liaision relationships with any other orgtanizations than Standards Development organizations. However, this will not stop us from having an open and trustful communication with indurial forums like MFA. The technical issue brought up in the communication will be discussed in this meeting, and based on that discussion a response to MFA will be sent. Note: This response were sent November 11 and will be found at http://www.cell-relay.com/mhonarc/mpls/current/msg00028.html - new RFCs / IESG reviews two drafts "draft-ietf-mpls-explicit-null-01.txt" and draft-ietf-mpls-rsvpte-attributes-04.txt have been in AD evaluation a long time, don't know why? Alex: they will be IETF last called pretty soon A number of docs has been moved to rfc ed queue: congrats to authors/editors. Since the dependencies on other documents are not that heavy they will go out as RFC soon The mpls bundle draft (draft-ietf-mpls-bundle-04) has been pulled from rfc queue, and taken back to wg for a (hopefully) quick respin, the reasons for this were discussed by Zafar at this meeting. A problem here is that several other documents depends on the bundle draft. - wg drafts This draft is stuck waiting for the lsp-ping draft to progress These two draft did miss the the cut-off date to be published as working group documents, the working groups chairs have sent a mail to the mailing list saying that for "all practical purposes the two draft should be treated as working group documents. "Graceful Restart Mechanism for BGP with MPLS" needs re-spin RRO Node-ID subobject: Jean-Philippe told that an update has been submitted Zafar Ali: Issues with link bundling draft After discussion among draft contributors, wg co-chairs and ADs it was decided decided that some issues with draft needed to be fixed. To tht end the draft was pulled from rfc queue. The scope of this presentation is to outline the issues, focusing on required functionality 1. scoping of component link id: node vs. bundled te link scope 2. equivalents of type 4/5 tlvs for ipv4 and ipv6 if_id_rsvp_hop and if_id error_spec objects 3. recording (and explicit controol) of component interface id Zafar described all three issues in more detail. Next step: would like wg to close on issues, then discuss solution space Adrian ("ccamp co-chair hat on"): Good to do this work in mpls, but it's blocking huge number of ccamp drafts in the rfc queue Loa: Just pulled the draft yesterday, don't know yet how long it will take to fix it Lou: Will submit update on draft as soon as drafts are accepted again George: authors should just circulate updated draft and solicit input Kireeti: No rewriting planned, only address specific issues and not open up the whole thing Yakov: Focus only on changes, not rest of document, wg chairs should structure discussion appropriately Lou: Don't add new things, don't reopen old issues, new functionality needs new draft Loa: The issues will be dealt with as wg last-call, limited to the issues outlined in Zafars slides slides: www.tla-group.com/~mpls/bundling.ppt 3. LDP to Draft Standards Ina Minei Ina: Since the last IETF work has been done into two areas 1. produced first draft of the revised specification - editorial - areas not covered in the document: securing hellos, LDP MTU signaling - shutting down adjacencies - clarifications: corner cases not spelled out correctly in the original spec - errors/clarifications/changes in the pseudo-code (split horizon when doing ordered label control) 2. started the operator survey - deadline for reply after the ietf Next steps - feedback from the changes made in the document - re-submit a version Kireeti Kompella: We need to update the IANA section, will propose text to Ina to go into this part of the document. Slides: www.tla-group.com/~mpls/3036bis.ppt Liaison from MPLS & Frame Relay Alliance on RFC 3036 Andy Malis Andy presented a liaison from MPLS & Frame Relay Alliance regarding the LDP Host Address FEC. He described what the HA FEC is in comparison to the Address Prefix FEC. Ina's original email proposed to remove host addr fec due to non-use, changes to the Address Prefix FEC with a /32 prefix were alos proposed Andy summarized the liaison and stated that while the MFA could use the Address Prefix FEC with a /32 prefix, the MFA prefer to keep HA FEC as is due to implementation plans. Slides: www.tla-group.com/~mpls/mfa-communication.ppt Discussion on Host Address FEC Eric Rosen RFC3036 defines FEC element types used to bind labels to address prefixes in routing table the RFC define two FECs (Address Prefix (AP) and Host Address (HA)), other FEC element types will be defined by other protocols in early versiions of the LDP specification only AP FEC existed, the HA FEC were included because it was assumed that an LSR must be able to distinguish between locally delivered vs. forwarded packets (constraints of particular ATM based implementation). The HA FEC has not been used so far, the LDP specification is written so it is easy to remove it when we progress to Draft Standard. The MFA laim they use the HA FEC in their specification, a closer reading of the documents show that they are not using the FEC axactly as specified in RFC3036, in particular it violates section 3.5.7.1 in the LDP specification. The conclusion is that a new FEC has been specified and a new FEC type is needed. Slides: not yet George: Does anybody object to keep the same number for new FEC? Andy: Keeping the same FEC type value is fine. But given it's all there in the doc, why take it out? Kireeti: A Draft Standard means that an implementation has existed for some time. New fec does not belong in ds std. George: Reusing the FEC type value implies that we first remove it from the LDP specification. Alex: Based on the discussion here, moving it to separate document is best idea Loa: As we don't have an implementation of the HA FEC, we can't move the LDP specification to Draft Standard. Move the new FEC into new doc and we will "reassign" same number. Andy: To reassign number requires wg draft accordig to iana allocation process (ietf consensus). Alex: Doesn't think proposed standard is required, but will need to check this. 4. P2MP TE (25 min) Requirements for Point to Multipoint Traffic Engineered MPLS LSPs Sheisho Yasukawa Sheisho stressed that the scope of the requirement specification is p2mp traffic enginered LSPs only, how the p2mp tree is co,puted is outside the scope of the requirment specification. Earlier revision -02 were working group last called, and revision -03 included updates accoring the last call comments. Revision -04 introduced new text to include requirements and clarification originating from the for all solution team issues. Thre are till some open issues: - variation of lsp parameters on different lsp branches? - can a transit (probably branch) re-optimize a sub-tree? - what should be the behavior if the tree "re-merges"? - can short-term data duplication be tolerated? - limits and design targets A new version is planned shortly and should be sent to working group last call. Slides: not yet Eric: Because of the way some of the requirements and the motivation for the requirements are stated the requirement document becomes more controversial than the solution document. It could be discussed if we need this requirment document at all. Igor: Do we need to includ a requirmentfor leaf-initiated add/drop George: I'm opposed to it. Complete solution needs more work elsewhere. If such requirements exists, they need to be captured somewhere else. Rahul: The solution assumes that all leaves are known. Application use will be defined elsewhere. Yakov: The requirement document should state that some issues are outside the scope of the requirment document upfront. This needs to made very clear. Seisho: Will update the document according to the discussion of the scope of the document. Solution Extensions to RSVP-TE for Point to Multipoint TE LSPs Dimtri, Rahul, Seisho The extensions to RSVP-TE for traffic engineered p2mp LSPs has progressed since the meeting in San Diego and a merged solutions document has been created. This document will be published as a working groupd ID after this meeting. The state management issue has been solved by means of . Outstanding issues are: a) style usage b) p2mp sender_template obj and filter_spec obj encoding specifics c) review re-merge/cross-over conditions d) re-optimization e) sub-ero compression re-organisation f) stitching mechanism detail Next steps: revision -01 will be submitted after meeting as wg i-d; for revision -02 the organization of the document will be reviewed and a terminology section included. Slides: www.tla-group.com/~mpls/p2mp-solution.ppt 5. MPLS OAM (20) Tom Nadeau and Dave Allan Tom: The first version of the document wer publsihed for the San Diego meeting and accepted as a working droup document. Will be published after this meeting. The document provides an overview of the FCAPS functionality and the required data plane tools. Authors asks for working group input. Slides: Not yet 6. P2MP LSP Ping (10 min) Detecting Data Plane Failures in Point-to-Multipoint MPLS TrafficEngineering - Extensions to LSP Ping Adrian Farrel This document extends the techniques described in [LSP-PING] in order that they may be applied to P2MP MPLS TE LSPs. This document stresses the reuse of existing LSP Ping mechanisms as such reuse simplifies operations of the network. Since Traffic Engineered P2MP LSPs are at lest as vulnerable to data plane failures a mechanism to verufy livesness of the data plane is needed. The P2MP tree brings new requirements for verifying data plane liveness. On obvious candidate to be used to create a tool for this is "LSP ping". The draft does not change the LSP ping as it exist, but describes extension to the LSP ping techniques so that they may be applied to P2MP MPLS TE LSPs Several issues needs to be discussed and questions need to be answered, e.g.: - is this the right approach, what are alternatives? - how to handle scaling - additional requirements? - what should happen to this draft? There is no consensus yet on this approach, we'll discuss on the mailing list until next meeting to see if we can make it a working group document. Slides: not yet 7. LDP/IGP Synchronization (10 min) Markus Jork In networks depending on edge-to-edge establishment of MPLS forwarding paths via LDP, blackholing of traffic can occur in situations where the IGP is operational on a link and thus the link is used for IP forwarding but LDP is not operational on that link for whatever reason. This document describes a mechanism to avoid traffic loss due to this condition without introducing any protocol changes. This means that along the IP shortest path from one PE router to the other, all the links need to have operational LDP sessions and the necessary label binding must have been exchanged over those sessions. Reasons for the a missing LDP session could e.g. be a configuration error. The draft need to cover interaction with TE tunnels better and it need clarify that it is applicable to targeted LDP. The discussions focused on sorting out the concepts and the scope of the docuemnt. The differences between IGP and LDP convergence were discussed. It was concluded that we need to discuss both content and the purpose of this document if we are to accept it as a working group document. Slides: www.tla-group.com/~mpls/ldp-igp-sync.ppt 8. Encapsulation of MPLS over (10 min) Layer 2 Tunneling Protocol Version 3 Mark Townsley The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of payload types over IP networks. This document defines how to carry an MPLS label or label stack and its payload over L2TPv3. Yakov Rekhter: there is no reason to accept this as a WG document, - because we have enogh methods to transport MPLS over an IP core Eric Rosen: This is really a no brainer - there is nothing specific here to do this and if this is just to make people being interested in the topic I don't see the reason to prefer one method or the other. Peter Lothberg: Speaking for isp using l2tp. Useful to add mpls into it as its just another l2. Jeff Young: Support in making this a standard of this to interoperate. Loa: Rename the draft-townsley-mpls-l2tpv3 to indicate it is intended to be mpls work item, take the discussion on the mailing list and come back with a resolution for the next meeting. Slides: www.tla-group.com/~mpls/mpls-over-l2tpv3.ppt 9. Meeting closes --------------080004030503080907000404 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --------------080004030503080907000404-- From mpls-bounces@ietf.org Wed Nov 24 10:56:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05638; Wed, 24 Nov 2004 10:56:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWzZ4-0000dJ-Ey; Wed, 24 Nov 2004 11:00:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWzMe-0004pm-J2; Wed, 24 Nov 2004 10:47:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWzLg-0004Tz-Sr for mpls@megatron.ietf.org; Wed, 24 Nov 2004 10:46:29 -0500 Received: from tbdns.testbed.local ([80.86.78.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04960 for ; Wed, 24 Nov 2004 10:46:25 -0500 (EST) Received: from [172.16.2.213] (gw.imc.kth.se [193.10.152.67]) (authenticated bits=0) by tbdns.testbed.local (8.12.8/8.12.8) with ESMTP id iAOFjEjp008371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Nov 2004 16:45:15 +0100 Message-ID: <41A4AC93.6040607@pi.se> Date: Wed, 24 Nov 2004 16:45:23 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Bill Fenner , ccamp@ops.ietf.org Subject: [mpls] MPLS wg last call on re-spun bundling draft 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Working group, this is to initiate a 2 weeks working group last call on The CCAMP working is copied on this MPLS working group last, since there are interdependencies between specifications from both working groups. Pleae use the MPLS mailing list for comments, cross-publishing is not necessary. Background: This draft was reviewed by the IESG and approved for publication. During implementation there were some issues found and it was decided to pull the draft from the RFC Editors queue. This wg last call is limited to these issues and how they been addressed only. The list of issues and how the authors has addresed has been sent to the mailing list(s). That text is also included in this mail. For the record please note that I've asked the authors to update some ID-nits, those are not part of the wg last call. But has been included just to make it easier to progress the document through IESG review. This working group last call ends on EOB December 10 PST. /Loa ------- issues and how they been addressed ------------- Here is the summary: draft-ietf-mpls-bundle-05.txt has been updated to reflect the comments made in the MPLS WG and on the list. The issues raised are: 1. Scope of component identifiers is open to interpretation (i.e., node vs link) 2. No way to specify different upstream and downstream components then using TLV types 1, 2 and 3 3. Ambiguity of contents of the IP address field in TLV types 3, 4, 5 4. Lack of IPv6 support for types 3, 4, and 5. 5. Ambiguity of when to use types 4 and 5 and when to use type 3. 6. No coverage of ERO and RRO implications These issues have been addressed in the following ways: Issue 1: The -05 document states that all component link TLV types have Node/IP scope Issue 2: -05 Tightly defines support for different components in each direction (for bidirectional LSPs, and for all TLV types) Issue 3: Format of the Value field for types 3, 4 and 5 now has the identical format as the contents of the C-Type 1 LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477]. Issue 4: Based on the previous change, support of IPv6 unnumbered components is now tied to, and the same as, the support of IPv6 unnumber TE links. Issue 5: -05 allows, but recommend against use of types 4 and 5 Issue 6: EROs, RROs remain out of scope of bundling document Current planned changes are: - Fix nits found by Adrian and Loa - Insert a Table of Contents - Section numbering will remain unchanged so as not to break any potentially existing references to the draft Yakov. -------------------- end of included text -------------------- 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@ietf.org Mon Nov 29 08:25:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18383; Mon, 29 Nov 2004 08:25:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYlcE-0000xF-9E; Mon, 29 Nov 2004 08:30:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYlKV-0001pc-F8; Mon, 29 Nov 2004 08:12:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYlHK-00012N-ED for mpls@megatron.ietf.org; Mon, 29 Nov 2004 08:09:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16797 for ; Mon, 29 Nov 2004 08:09:17 -0500 (EST) Received: from oceanus.uk.clara.net ([80.168.70.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYlME-0000Vi-Gc for mpls@ietf.org; Mon, 29 Nov 2004 08:14:22 -0500 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1CYlHG-000Gbw-9G; Mon, 29 Nov 2004 13:09:14 +0000 From: "Adrian Farrel" To: mpls@ietf.org Subject: Re: [mpls] MPLS wg last call on re-spun bundling draft Date: Mon, 29 Nov 2004 13:09:14 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Remote_Addr: 156.106.204.142 Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Hi, Editorial comments... The document is indicated as updating RFC3471. Does it also update RFC3477? See section 2... This section is equally applicable to the case of unnumbered component links (see [LINK-BUNDLE]). Ditto 3480 Section 4.3 Duplicate paragraph... With RSVP the choice of the component link is indicated by the sender of the Path message by including the IF_ID RSVP_HOP object in the Path message, as described in section 8 of [RFC3473]. With CR-LDP the choice of the component link is indicated by the sender of the REQUEST message by including the IF_ID TLV in the REQUEST message, as described in section 8 of [RFC3472]. FWIW gmpls-routing is now at a later revision. Yakov wrote... > - Section numbering will remain unchanged so as not to break > any potentially existing references to the draft Your choice. The RFC Ed will fix this anyway as it is a strict rule. Thus references will be broken if they use numbers (which they shouldn't pre RFC) instead of names (which they should). Technical comments... Yakov wrote... > 1. Scope of component identifiers is open to interpretation (i.e., node > vs link) > > Issue 1: The -05 document states that all component link TLV types > have Node/IP scope I think this is still ambiguous in the current revision. It would not hurt to be exceptionally scrupulous about this definition. Section 4... Furthermore we restrict the identifiers that can be used to identify component links such that they have node scope. This does not appear to allow IP scope. Section 4.1... Component link identifiers MUST have node wide scope and MUST be unique across both TE and component link identifiers. Ditto Yakov wrote... > 4. Lack of IPv6 support for types 3, 4, and 5. > > Issue 4: Based on the previous change, support of IPv6 unnumbered > components is now tied to, and the same as, the support of > IPv6 unnumber TE links. That's OK, but may be a tad ambiguous to some readers. What is an IPv6 unnumbered TE link? It appears to me that there is no distinction between IPv6 and IPv4 unnumbered links. They are identified by a router ID (4 bytes) and a link ID (4 bytes). There is nothing related to IPv4 or IPv6 there. Not sure that you need to make any changes to the text, however (except that the IESG may not understand this point and so might bounce the draft asking where the IPv6 support is :-) Yakov wrote... > 5. Ambiguity of when to use types 4 and 5 and when to use type 3. > > Issue 5: -05 allows, but recommend against use of types 4 and 5 Wouldn't it be nice if the TLVs were under IANA control? Then you could deprecate 4 and 5. Yakov wrote... > 6. No coverage of ERO and RRO implications > > Issue 6: EROs, RROs remain out of scope of bundling document Good. I support this. But do you propose to clarify PathErr/Notify reporting? If you report the component link in a PathErr/Notify the ingress may not be able to grok the context (especially if the component link is numbered). Would you like to state that the PathErr/Notify MUST use to bundle ID? (I guess the same applies to ResvErr.) I am concerned about the assumed symmetry in bidirecitonal cases. I know we have agreed that a bidirectional LSP will always use the same TE link in both directions, but we are clearly allowing different component links to be used in each direction. OK. But what if the TE link is a bundle in one direction and a single link in the other direction? I think we can handle this just fine, but maybe we should say so? Thanks, Adrian _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Nov 29 08:32:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19149; Mon, 29 Nov 2004 08:32:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYlj7-000172-3n; Mon, 29 Nov 2004 08:38:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYlXR-0004SK-92; Mon, 29 Nov 2004 08:25:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYlOj-0002eb-IE for mpls@megatron.ietf.org; Mon, 29 Nov 2004 08:16:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17517 for ; Mon, 29 Nov 2004 08:16:56 -0500 (EST) Received: from oceanus.uk.clara.net ([80.168.70.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYlTd-0000hM-Qq for mpls@ietf.org; Mon, 29 Nov 2004 08:22:02 -0500 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1CYlOi-000HR4-5F; Mon, 29 Nov 2004 13:16:56 +0000 From: "Adrian Farrel" To: mpls@ietf.org Date: Mon, 29 Nov 2004 13:16:55 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Remote_Addr: 156.106.204.142 Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Subject: [mpls] Further updates reference for Bundling draft X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Hi, Looking at section 4 of RFC3946, I htink you are updating some of this text, too. Adrian _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Nov 29 10:06:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27896; Mon, 29 Nov 2004 10:06:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYnBv-0003ZZ-Qz; Mon, 29 Nov 2004 10:11:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYmsE-0005AE-Ty; Mon, 29 Nov 2004 09:51:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYmlv-0003UU-Kh for mpls@megatron.ietf.org; Mon, 29 Nov 2004 09:44:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25662 for ; Mon, 29 Nov 2004 09:44:58 -0500 (EST) Received: from hs22.order-vault.net ([65.18.133.138]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYmqp-0002w9-Qd for mpls@ietf.org; Mon, 29 Nov 2004 09:50:05 -0500 Received: from lb.labn.net (labn.net [65.18.134.4]) (authenticated (0 bits)) by hs22.order-vault.net (8.11.6/8.11.6) with ESMTP id iATEi0Q19253; Mon, 29 Nov 2004 09:44:02 -0500 Message-Id: <6.1.2.0.2.20041129094314.04370de8@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 29 Nov 2004 09:44:15 -0500 To: adrian@olddog.co.uk From: Lou Berger Subject: Re: [mpls] Further updates reference for Bundling draft In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 At 08:16 AM 11/29/2004, Adrian Farrel wrote: >Hi, >Looking at section 4 of RFC3946, I htink you are updating some of this >text, too. >Adrian Adrian, Can you be more precise? For some reason I think you blew the reference... 4. Acknowledgments Valuable comments and input were received from the CCAMP mailing list where outstanding discussions took place. Mannie & Papadimitriou Standards Track [Page 15] RFC 3946 GMPLS Extensions for SONET/SDH Control October 2004 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Nov 29 10:29:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01404; Mon, 29 Nov 2004 10:29:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYnXl-0004Bu-Gt; Mon, 29 Nov 2004 10:34:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYnQH-0001OK-Nh; Mon, 29 Nov 2004 10:26:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYnFo-0005yI-9y for mpls@megatron.ietf.org; Mon, 29 Nov 2004 10:15:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29384 for ; Mon, 29 Nov 2004 10:15:50 -0500 (EST) Received: from hs22.order-vault.net ([65.18.133.138]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYnKj-0003oY-MF for mpls@ietf.org; Mon, 29 Nov 2004 10:20:58 -0500 Received: from lb.labn.net (labn.net [65.18.134.4]) (authenticated (0 bits)) by hs22.order-vault.net (8.11.6/8.11.6) with ESMTP id iATFF4P00541; Mon, 29 Nov 2004 10:15:04 -0500 Message-Id: <6.1.2.0.2.20041129092014.03e7aec0@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 29 Nov 2004 10:03:46 -0500 To: adrian@olddog.co.uk From: Lou Berger Subject: Re: [mpls] MPLS wg last call on re-spun bundling draft In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 At 08:09 AM 11/29/2004, Adrian Farrel wrote: >Hi, >Editorial comments... >The document is indicated as updating RFC3471. >Does it also update RFC3477? See section 2... > This section is equally applicable to the case of unnumbered > component links (see [LINK-BUNDLE]). Don't think so. Where do you see the update? >Ditto 3480 >Section 4.3 Duplicate paragraph... > With RSVP the choice of the component link is indicated by the sender > of the Path message by including the IF_ID RSVP_HOP object in the > Path message, as described in section 8 of [RFC3473]. With CR-LDP > the choice of the component link is indicated by the sender of the > REQUEST message by including the IF_ID TLV in the REQUEST message, as > described in section 8 of [RFC3472]. wow, that's cool. Thanks. >FWIW >gmpls-routing is now at a later revision. >Yakov wrote... >>- Section numbering will remain unchanged so as not to break any >>potentially existing references to the draft >Your choice. >The RFC Ed will fix this anyway as it is a strict rule. >Thus references will be broken if they use numbers (which they shouldn't >pre RFC) instead of names (which they should). > >Technical comments... >Yakov wrote... >>1. Scope of component identifiers is open to interpretation (i.e., node >>vs link) >>Issue 1: The -05 document states that all component link TLV types >> have Node/IP scope > >I think this is still ambiguous in the current revision. >It would not hurt to be exceptionally scrupulous about this definition. >Section 4... > Furthermore we restrict the identifiers that can be used to identify > component links such that they have node scope. >This does not appear to allow IP scope. >Section 4.1... > Component link identifiers MUST have node wide scope and MUST be > unique across both TE and component link identifiers. >Ditto okay, Here's what the next rev will say: section 4: Furthermore we restrict the identifiers that can be used to identify component links such that they are unique for a given node. section 4.1: Component link identifiers MUST be unique across both TE and component link identifiers on a particular node. This means that unnumbered identifiers have node wide scope, and that numbered identifiers have the same scope as IP addresses. >Yakov wrote... >>4. Lack of IPv6 support for types 3, 4, and 5. >>Issue 4: Based on the previous change, support of IPv6 unnumbered >> components is now tied to, and the same as, the support >> of IPv6 unnumber TE links. > >That's OK, but may be a tad ambiguous to some readers. >What is an IPv6 unnumbered TE link? >It appears to me that there is no distinction between IPv6 and IPv4 >unnumbered links. They are identified by a router ID (4 bytes) and a link >ID (4 bytes). There is nothing related to IPv4 or IPv6 there. >Not sure that you need to make any changes to the text, however (except >that the IESG may not understand this point and so might bounce the draft >asking where the IPv6 support is :-) >Yakov wrote... >>5. Ambiguity of when to use types 4 and 5 and when to use type 3. >>Issue 5: -05 allows, but recommend against use of types 4 and 5 >Wouldn't it be nice if the TLVs were under IANA control? They are. See http://www.iana.org/assignments/gmpls-sig-parameters >Then you could deprecate 4 and 5. Good point. This should go in an IANA considerations section. >Yakov wrote... >>6. No coverage of ERO and RRO implications >>Issue 6: EROs, RROs remain out of scope of bundling document >Good. I support this. >But do you propose to clarify PathErr/Notify reporting? >If you report the component link in a PathErr/Notify the ingress may not >be able to grok the context (especially if the component link is numbered). >Would you like to state that the PathErr/Notify MUST use to bundle ID? Not sure there is a real issue here. Components will either have IP or node scope. In the former case, the address should be meaning full. In the later case, the node ID should be meaning full and the TE link can be identified in the Error Address field. I guess we can add some clarifying text... >(I guess the same applies to ResvErr.) The information is already carried in the HOP object of a ResvErr. >I am concerned about the assumed symmetry in bidirecitonal cases. I know >we have agreed that a bidirectional LSP will always use the same TE link >in both directions, but we are clearly allowing different component links >to be used in each direction. OK. But what if the TE link is a bundle in >one direction and a single link in the other direction? I think we can >handle this just fine, but maybe we should say so? I don't have a strong opinion here. What specifically are you suggesting? Thanks for the comments, Lou >Thanks, >Adrian > >_______________________________________________ >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@ietf.org Mon Nov 29 10:43:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02628; Mon, 29 Nov 2004 10:43:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYnlF-0004Ue-26; Mon, 29 Nov 2004 10:48:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYnRv-00028R-RE; Mon, 29 Nov 2004 10:28:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYnOU-0000h2-Mx for mpls@megatron.ietf.org; Mon, 29 Nov 2004 10:24:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00829 for ; Mon, 29 Nov 2004 10:24:47 -0500 (EST) Received: from oceanus.uk.clara.net ([80.168.70.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYnTO-00043n-5t for mpls@ietf.org; Mon, 29 Nov 2004 10:29:55 -0500 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1CYnOQ-0004up-Qb; Mon, 29 Nov 2004 15:24:46 +0000 From: "Adrian Farrel" To: mpls@ietf.org Subject: Re: [mpls] Further updates reference for Bundling draft Date: Mon, 29 Nov 2004 15:24:46 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Remote_Addr: 156.106.204.142 Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: lb@movaz.com X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit > >Looking at section 4 of RFC3946, I htink you are updating some of this > >text, too. > > Can you be more precise? For some reason I think you blew the > reference... Pooh! I meant RFC3945. Guess I got excited by all those new CCAMP RFCs. Adrian _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Nov 29 10:53:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03586; Mon, 29 Nov 2004 10:53:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYnvC-0004k6-Dr; Mon, 29 Nov 2004 10:58:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYnkQ-00063w-Sv; Mon, 29 Nov 2004 10:47:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYnVM-0003D6-7s for mpls@megatron.ietf.org; Mon, 29 Nov 2004 10:31:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01608 for ; Mon, 29 Nov 2004 10:31:54 -0500 (EST) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYnaG-0004EK-ME for mpls@ietf.org; Mon, 29 Nov 2004 10:37:01 -0500 Received: from movaz-hw.movaz.com (movaz-hw.atlanta.movaz.com [172.16.8.183]) by jera.movaz.com (Postfix) with ESMTP id 13A94FE1; Mon, 29 Nov 2004 10:31:22 -0500 (EST) Received: from lb.movaz.com (localhost [127.0.0.1]) by movaz-hw.movaz.com (Postfix) with ESMTP id DD98EAFB3; Mon, 29 Nov 2004 10:31:17 -0500 (EST) Message-Id: <6.1.2.0.2.20041129103025.04526ec0@mo-ex1> X-Sender: lb@mo-ex1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 29 Nov 2004 10:31:17 -0500 To: From: Lou Berger Subject: Re: [mpls] Further updates reference for Bundling draft In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: mpls@ietf.org, "Berger, Lou" 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a At 10:24 AM 11/29/2004, Adrian Farrel wrote: > > >Looking at section 4 of RFC3946, I htink you are updating some of this > > >text, too. > > > > Can you be more precise? For some reason I think you blew the > > reference... > >Pooh! > >I meant RFC3945. >Guess I got excited by all those new CCAMP RFCs. > >Adrian Adrian, Good, now we're down to a sensible section and document! So what do you see is being modified by the bundling draft? Thanks, Lou _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Nov 29 11:31:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06502; Mon, 29 Nov 2004 11:31:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYoVX-0005aG-To; Mon, 29 Nov 2004 11:36:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYoKz-0004ma-8W; Mon, 29 Nov 2004 11:25:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYoDs-0003UI-Gl for mpls@megatron.ietf.org; Mon, 29 Nov 2004 11:17:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05539 for ; Mon, 29 Nov 2004 11:17:54 -0500 (EST) Received: from oceanus.uk.clara.net ([80.168.70.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYoIo-0005I0-Aw for mpls@ietf.org; Mon, 29 Nov 2004 11:23:02 -0500 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1CYoDk-000Ajp-KE; Mon, 29 Nov 2004 16:17:48 +0000 From: "Adrian Farrel" To: lb@movaz.com Subject: Re: [mpls] Further updates reference for Bundling draft Date: Mon, 29 Nov 2004 16:17:48 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Remote_Addr: 156.106.204.142 Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit > > > >Looking at section 4 of RFC3946, I think you are updating some of > > > >this text, too. > >I meant RFC3945. > >Guess I got excited by all those new CCAMP RFCs. > > Good, now we're down to a sensible section and document! So what do you > see is being modified by the bundling draft? Well, I admit you have to read as far as the second paragraph... The concept of link bundling is essential in certain networks employing the GMPLS control plane as is defined in [BUNDLE]. A typical example is an optical meshed network where adjacent optical cross-connects (LSRs) are connected by several hundreds of parallel wavelengths. In this network, consider the application of link state routing protocols, like OSPF or IS-IS, with suitable extensions for resource discovery and dynamic route computation. Each wavelength must be advertised separately to be used, except if link bundling is used. When a pair of LSRs is connected by multiple links, it is possible to advertise several (or all) of these links as a single link into OSPF and/or IS-IS. This process is called link bundling, or just bundling. The resulting logical link is called a bundled link as its physical links are called component links (and are identified by interface indexes). ## - Component links are not identified (externally) as interface indexes ## but using the new identification rules in your revised text The result is that a combination of three identifiers ((bundled) link identifier, component link identifier, label) is sufficient to unambiguously identify the appropriate resources used by an LSP. ## - The listed triplet may be "sufficient" but it is now more than ## necessary. And then again in section 4.3.3 With this mechanism, each component link that is unnumbered is assigned a unique Interface Identifier (32 bits value). The upstream node indicates the choice of the component link by including a new IF_ID RSVP_HOP object/IF_ID TLV in the Path/Label Request message (see [RFC3473]/[RFC3472], respectively). ## - We have now specified the definition/scope of "unique" and h Nothing here is a big deal. just making an observation. Cheers, Adrian _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Nov 29 12:28:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11411; Mon, 29 Nov 2004 12:28:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYpOw-0006rD-Fk; Mon, 29 Nov 2004 12:33:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYpCd-0000S2-P3; Mon, 29 Nov 2004 12:20:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYour-0002im-CM for mpls@megatron.ietf.org; Mon, 29 Nov 2004 12:02:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08835 for ; Mon, 29 Nov 2004 12:02:19 -0500 (EST) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYozm-0006EK-J7 for mpls@ietf.org; Mon, 29 Nov 2004 12:07:28 -0500 Received: from movaz-hw.movaz.com (movaz-hw.atlanta.movaz.com [172.16.8.183]) by jera.movaz.com (Postfix) with ESMTP id 5571C172F; Mon, 29 Nov 2004 12:01:48 -0500 (EST) Received: from lb.movaz.com (localhost [127.0.0.1]) by movaz-hw.movaz.com (Postfix) with ESMTP id 8CCCCAF9B; Mon, 29 Nov 2004 12:01:45 -0500 (EST) Message-Id: <6.1.2.0.2.20041129115757.046e1ec0@mo-ex1> X-Sender: lb@mo-ex1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 29 Nov 2004 12:01:44 -0500 To: From: Lou Berger Subject: Re: [mpls] Further updates reference for Bundling draft In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 At 11:17 AM 11/29/2004, Adrian Farrel wrote: >Nothing here is a big deal. just making an observation. > >Cheers, >Adrian okay, I now understand your comment. I think most, if not all of the comments you make hold true with the old version of the bundle draft as well. (Hence my confusion). Also I think your comments apply more to implementation and doesn't alter the architecture. As you say, isn't much of a big deal, so I think we should just leave as is... Lou _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Nov 29 12:32:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12271; Mon, 29 Nov 2004 12:32:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYpT6-0006yg-O7; Mon, 29 Nov 2004 12:37:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYpDm-0000yv-Vw; Mon, 29 Nov 2004 12:21:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYp9p-0007Zo-SH for mpls@megatron.ietf.org; Mon, 29 Nov 2004 12:17:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10168 for ; Mon, 29 Nov 2004 12:17:47 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYpEQ-0006aq-8B for mpls@ietf.org; Mon, 29 Nov 2004 12:22:56 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 29 Nov 2004 12:16:57 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iATHGsgl011517; Mon, 29 Nov 2004 12:16:54 -0500 (EST) Message-Id: <200411291716.iATHGsgl011517@rtp-core-1.cisco.com> To: Kireeti Kompella Subject: Re: [mpls] I-D ACTION:draft-ietf-mpls-rfc3036bis-01.txt In-reply-to: Your message of Wed, 24 Nov 2004 02:47:49 -0800. <20041124015259.Y13504@kummer.juniper.net> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Mon, 29 Nov 2004 12:16:54 -0500 From: Eric Rosen X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Kireeti> Here's my take on the IANA considerations section: I really don't see why any changes need to be made to this section. Kireeti> I would *strongly* recommend against having a First-Come-First- Kireeti> Served range for the FEC Type name space. I would even more *strongly* object to any change being made here. (Well, we could make the experimental space smaller and the FCFS space larger, I wouldn't object to that.) Moving from PS to DS is not supposed to be an open door for this kind of mischief. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls