From owner-mpls@UU.NET Tue Oct 1 07:39:11 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09564 for ; Tue, 1 Oct 2002 07:39:11 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnirm03798 for ; Tue, 1 Oct 2002 11:41:07 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnirm03110; Tue, 1 Oct 2002 11:40:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQnirm21467 for mpls-outgoing; Tue, 1 Oct 2002 11:40:23 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnirm21462 for ; Tue, 1 Oct 2002 11:40:16 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnirm02029 for ; Tue, 1 Oct 2002 11:40:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnirm02206 for ; Tue, 1 Oct 2002 11:40:05 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnirm02179 for ; Tue, 1 Oct 2002 11:40:05 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA10419 for ; Tue, 1 Oct 2002 07:40:05 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g91Be4u29712 for mpls@uu.net; Tue, 1 Oct 2002 07:40:04 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnirm21428 for ; Tue, 1 Oct 2002 11:38:36 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnirm29534 for ; Tue, 1 Oct 2002 11:38:17 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnirm05393 for ; Tue, 1 Oct 2002 11:38:17 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQnirm05384 for ; Tue, 1 Oct 2002 11:38:17 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09336; Tue, 1 Oct 2002 07:36:18 -0400 (EDT) Message-Id: <200210011136.HAA09336@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-ldp-ft-06.txt Date: Tue, 01 Oct 2002 07:36:17 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --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 : Fault Tolerance for the Label Distribution Protocol (LDP) Author(s) : A. Farrel Filename : draft-ietf-mpls-ldp-ft-06.txt Pages : 53 Date : 2002-9-30 Multiprotocol Label Switching (MPLS) systems will be used in core networks where system downtime must be kept to an absolute minimum. Many MPLS Label Switching Routers (LSRs) may, therefore, exploit Fault Tolerant (FT) hardware or software to provide high availability of the core networks. The details of how FT is achieved for the various components of an FT LSR, including Label Distribution Protocol (LDP), the switching hardware and TCP, are implementation specific. This document identifies issues in the LDP specification in RFC 3036 'LDP Specification' that make it difficult to implement an FT LSR using the current LDP protocols, and proposes enhancements to the LDP specification to ease such FT LSR implementations. The issues and extensions described here are equally applicable to RFC 3212, 'Constraint-Based LSP Setup Using LDP' (CR-LDP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-ft-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-ldp-ft-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-ldp-ft-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-9-30144708.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ldp-ft-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ldp-ft-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-30144708.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Oct 1 08:14:14 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11161 for ; Tue, 1 Oct 2002 08:14:13 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnirp07484 for ; Tue, 1 Oct 2002 12:16:08 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnirp06840; Tue, 1 Oct 2002 12:15:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQnirp10853 for mpls-outgoing; Tue, 1 Oct 2002 12:15:39 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnirp10848 for ; Tue, 1 Oct 2002 12:15:37 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnirp20868 for ; Tue, 1 Oct 2002 12:15:21 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnirp06427 for ; Tue, 1 Oct 2002 12:15:21 GMT Received: from blooper.utfors.se by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQnirp06418 for ; Tue, 1 Oct 2002 12:15:20 GMT Received: from utfors.se (nat-sto.utfors.se [212.73.0.237]) by blooper.utfors.se (8.12.6/8.12.6) with ESMTP id g91CFJtA006915 for ; Tue, 1 Oct 2002 14:15:19 +0200 (MEST) Message-ID: <3D9991D7.7090105@utfors.se> Date: Tue, 01 Oct 2002 14:15:19 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: MPLS wg Subject: Correction: wg lst call on ft/restart drafts References: <3D97FD64.1030707@utfors.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Loa Andersson wrote: > All, > > this is to initiate a wg last call on the following drafts. > > draft-ietf-mpls-bgp-mpls-restart-01.txt > draft-ietf-mpls-ldp-restart-03.txt > draft-ietf-mpls-ldp-ft-05.txt this should be draft-ietf-mpls-ldp-ft-06.txt sorry aout the mistake /Loa > > > All draft has been through wg last call and been updated according > to the comments in the last call. The normal way of doing this would > be to restrict the comments in this last call to the changes only, > however in this case I would like to invite comments on the > drafts as a group, since there has been a need to coordinate them. > > Further information on this is found in: > > > > This document is not yet up for a last call, but, as a first step, > we propose it to become a working group document. Comments on the > draft will be viewed in this context. > > The last call will end October 13th 12.00 PM GMT > > > /Loa -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se From owner-mpls@UU.NET Wed Oct 2 05:38:53 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13335 for ; Wed, 2 Oct 2002 05:38:52 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQniuw01601 for ; Wed, 2 Oct 2002 09:40:47 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQniuw00992; Wed, 2 Oct 2002 09:40:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQniuw23745 for mpls-outgoing; Wed, 2 Oct 2002 09:39:52 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQniuw23739 for ; Wed, 2 Oct 2002 09:39:44 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQniuw04570 for ; Wed, 2 Oct 2002 09:36:14 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQniuw02154 for ; Wed, 2 Oct 2002 09:36:13 GMT Received: from n13.sp.op.dlr.de by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: n13.sp.op.dlr.de [129.247.25.4]) id QQniuw02145 for ; Wed, 2 Oct 2002 09:36:12 GMT Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) by n13.sp.op.dlr.de (8.11.6/8.11.6) with ESMTP id g929aBi47090 for ; Wed, 2 Oct 2002 11:36:11 +0200 Received: from MOBDN238 (mobdn238 [129.247.173.238]) by zeus.nt.op.dlr.de (8.9.3+Sun/8.9.1) with ESMTP id LAA26253 for ; Wed, 2 Oct 2002 11:36:11 +0200 (MET DST) From: "Riccardo" To: Subject: problem with MPLS Traffic Engineering over ATM Date: Wed, 2 Oct 2002 11:35:51 +0200 Message-ID: <001001c269f7$18f71600$eeadf781@MOBDN238> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I'm working here in Germany to prepare for my degree. I'm studing Mpls and exactly how MPLS could be used in a Satellite Networks. I've just started my work reading Bruce Davie's Mpls book and some RFC, but I've a problem (maybe trivial). I've read that both LDP, CR-LDP and RSVP uses IP to be transported (do not?).How could these protocols be implemented in an ATM Network where Ip is not used? If you have some material or hint that could help me please reply this e-mail. Thanks for everything and excuse me for the intrusion. ------------------------------------------ Riccardo Menichelli German Aerospace Center (DLR) Institute of Communications and Navigation phone: +49 8153 28-2819 fax: +49 8153 28-2844 email: riccardo@zeus.nt.op.dlr.de http://www.dlr.de/KN/KN-DN/ ------------------------------------------ From owner-mpls@UU.NET Thu Oct 3 00:16:00 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16625 for ; Thu, 3 Oct 2002 00:16:00 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnixt21859 for ; Thu, 3 Oct 2002 04:17:54 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnixt21464; Thu, 3 Oct 2002 04:17:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQnixt24886 for mpls-outgoing; Thu, 3 Oct 2002 04:17:25 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnixt24881 for ; Thu, 3 Oct 2002 04:17:21 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnixs16602 for ; Thu, 3 Oct 2002 04:14:53 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnixs21932 for ; Thu, 3 Oct 2002 04:14:53 GMT Received: from wiprom2mx1.wipro.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQnixs21920 for ; Thu, 3 Oct 2002 04:14:51 GMT Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g934El221602 for ; Thu, 3 Oct 2002 09:44:48 +0530 (IST) Received: from soflt.ipneg.wipro.com ([10.117.3.193]) by kmglmail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id H3E14H00.K9C for ; Thu, 3 Oct 2002 09:44:41 +0530 Date: Thu, 3 Oct 2002 09:43:29 +0530 (IST) From: "chetan kumar s" X-X-Sender: Reply-To: To: Subject: ERO processing Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, While processing ERO object, there seems to discrepancy in the statements made in CR-LDP (RFC 3212) and RSVPTE (3209) to process initial ERO. CR-LDP considers 'L' bit and RSVPTE do not consider 'L' bit. What is the rationale behind this, I would say RSVPTE also should consider L bit. There were couple of mails on this in the mailing list but there were no fitting answers. Can the authors pls clarify.. RCF 3212: 1. The node receiving the Label Request Message must first evaluate the first ER-Hop. If the L bit is not set in the first ER-Hop and if the node is not part of the abstract node described by the first ER-Hop, it has received the message in error, and should return a "Bad Initial ER-Hop Error" status. RCF 3209: 1) The node receiving the RSVP message MUST first evaluate the first subobject. If the node is not part of the abstract node described by the first subobject, it has received the message in error and SHOULD return a "Bad initial subobject" error. Thanks Chetan S -- ------------ Thinking is progress, non thinking is destruction of individual, organization and nation -Abdul Kalam From owner-mpls@UU.NET Thu Oct 3 02:00:29 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18845 for ; Thu, 3 Oct 2002 02:00:29 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQniya17334 for ; Thu, 3 Oct 2002 06:02:26 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQniya16662; Thu, 3 Oct 2002 06:02:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQniya27172 for mpls-outgoing; Thu, 3 Oct 2002 06:01:44 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQniya27134 for ; Thu, 3 Oct 2002 06:01:42 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQniya09942 for ; Thu, 3 Oct 2002 06:01:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQniya24967 for ; Thu, 3 Oct 2002 06:01:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQniya24950 for ; Thu, 3 Oct 2002 06:01:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id CAA10856 for ; Thu, 3 Oct 2002 02:01:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g93612N27977 for mpls@uu.net; Thu, 3 Oct 2002 02:01:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnixz17881 for ; Thu, 3 Oct 2002 05:59:42 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnixz09833 for ; Thu, 3 Oct 2002 05:59:25 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnixz23668 for ; Thu, 3 Oct 2002 05:59:24 GMT Received: from ganesh.ctd.hctech.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQnixz23653 for ; Thu, 3 Oct 2002 05:59:23 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id <4BF3XB1C>; Thu, 3 Oct 2002 11:34:45 +0530 Message-ID: <55E277B99171E041ABF5F4B1C6DDCA069AB951@haritha.hclt.com> From: "Vijayanand C - CTD, Chennai." To: mpls@UU.NET Subject: FW: I-D ACTION:draft-vijay-mpls-rsvpte-lspsubobject-00.txt Date: Thu, 3 Oct 2002 10:51:16 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C26A9C.B2D45EE0" Sender: owner-mpls@UU.NET Precedence: bulk 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_000_01C26A9C.B2D45EE0 Content-Type: text/plain; charset="iso-8859-1" Hello all, I invite your comments on the following draft. Thanks and Regards, Vijay -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, October 02, 2002 4:50 PM Subject: I-D ACTION:draft-vijay-mpls-rsvpte-lspsubobject-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LSP Subobject for RSVP-TE Author(s) : C. Vijayanand Filename : draft-vijay-mpls-rsvpte-lspsubobject-00.txt Pages : 8 Date : 2002-10-1 This document describes the use of RSVP-TE[RSVP-TE] to establish hierarchical tunnels using a LSP sub-object in the ERO. This document proposes extensions to existing RSVP-TE for establishing hierarchical tunnels in RSVP-TE using a LSP subobject in the Explicit route object of RSVP-TE path message. LSP subobject can be used to uniquely identify the outer tunnel to be used for tunneling. This is useful in situations where the outer tunnel is not an FA-LSP and the knowledge of outer tunnel is available to the administrator. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vijay-mpls-rsvpte-lspsubobject-00. txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-vijay-mpls-rsvpte-lspsubobject-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-vijay-mpls-rsvpte-lspsubobject-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_000_01C26A9C.B2D45EE0 Content-Type: message/rfc822 To: Subject: Date: Wed, 2 Oct 2002 17:18:23 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C26A9C.B2D45EE0" ------_=_NextPart_002_01C26A9C.B2D45EE0 Content-Type: text/plain ------_=_NextPart_002_01C26A9C.B2D45EE0 Content-Type: application/octet-stream; name="ATT89242.txt" Content-Disposition: attachment; filename="ATT89242.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-1141119.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-vijay-mpls-rsvpte-lspsubobject-00.txt ------_=_NextPart_002_01C26A9C.B2D45EE0 Content-Type: message/external-body; site="internet-drafts"; dir="draft-vijay-mpls-rsvpte-lspsubobject-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C26A9C.B2D45EE0-- ------_=_NextPart_000_01C26A9C.B2D45EE0-- From owner-mpls@UU.NET Thu Oct 3 13:09:53 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25273 for ; Thu, 3 Oct 2002 13:09:52 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnizs13141 for ; Thu, 3 Oct 2002 17:11:49 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnizs12684; Thu, 3 Oct 2002 17:11:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQnizs23054 for mpls-outgoing; Thu, 3 Oct 2002 17:11:09 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnizs22961 for ; Thu, 3 Oct 2002 17:11:01 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnizs03345 for ; Thu, 3 Oct 2002 17:09:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnizs11396 for ; Thu, 3 Oct 2002 17:09:03 GMT Received: from blount.mail.mindspring.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: blount.mail.mindspring.net [207.69.200.226]) id QQnizs11392 for ; Thu, 3 Oct 2002 17:09:03 GMT Received: from user-uinjms2.dsl.mindspring.com ([165.121.219.130] helo=METANOIA) by blount.mail.mindspring.net with smtp (Exim 3.33 #1) id 17x9Sy-0007Z3-00; Thu, 03 Oct 2002 13:08:48 -0400 Reply-To: From: "Vishal Sharma" To: "Anna Charny" Cc: Subject: RE: More comments on the Backup-Computation draft Date: Thu, 3 Oct 2002 13:09:13 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <4.3.2.7.2.20020912121153.025c0bb8@pilgrim.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Anna, Sorry for the long delay in responding. I agree with most of your thoughts below. Please see comments in-line. -Vishal > -----Original Message----- > From: Anna Charny [mailto:acharny@cisco.com] > Sent: Thursday, September 12, 2002 12:33 PM > To: v.sharma@ieee.org > Cc: mpls@UU.NET > Subject: Re: More comments on the Backup-Computation draft > > > Hi Vishal, > > Thanks a lot for the comments. Please see in-line... > > At 01:33 PM 9/11/2002 -0400, Vishal Sharma wrote: > >Hi Anna, > > > >As a continuation of my previous email, here are a few more comments > >on the draft. Some are editorial, some technical. > > > >-Vishal > > > >i) The draft mentions at various points "See Section 11". I think > >what is meant is probably Section 10. > > yes, you are right - thanks for noticing. Will correct > > >ii) References [lakshman] pp. 7 and [MPLS_DIFF] pp. 23 seem to > >be missing. > > Yes, we also noticed that - will add the references > > >iii) The definition of MP on pp. 4 says "in case of one-to-one > >backup, this is where multiple detours converge." Not sure why > >this has to be? > > I am not sure I understand your concern? It must be some wording issue > here that I am missing. What would you say instead? As I think about it, I think I understand what you were trying to say. The thought, I think, was that if one-to-one backup is used for several (or all) links on an LSP, it might be expected that multiple detours would merge at a given MP. If that is so, perhaps a clearer wording would help here. > >iv) In Section 6.2, when discussing the distributed computation > >model, the last line on pp. 13 states "But again IGP-TE extensions > >is a benefit, not a requirement for this solution to work." If IGP-TE > >extensions are not used, is the assumption that the backup bandwidth > >pool for all links is explicitly configured at every node? > >(since an explicitly defined backup bandwidth pool is one of the > >key pieces of this [distributed] model). > > > We probably should clarify exactly what we mean here - I agree > that the way > we say may be misleading. > Let me try to explain what we really wanted to say - see if it > makes sense. > What we really meant was that there is a *limited* set of circumstances > where the distributed model could work without IGP extensions. For > example, if the desire is to have strict bandwidth protection for the > entire reservable bandwidth on a link (sort of a SONET replacement > strategy), the max reservable bandwidth is configured to be strictly less > than link speed on enough links, then the backup pool can be explicitly > computed from the link speed and max reservable bandwidth. Note > that this > does not really prevent configuring max reservable banwidth to > exceed link > capacity on *some* links. Strictly speaking you need to have non-zero > backup pool on just enough links to be able to protect the traffic. Just > exactly what is enough is very dependent on topology, of course. Agreed! > That said, if no IGP extensions are defined for the backup pool, one is > stuck with having some sort of network-wide policy that would allow > deriving what the amount of backup bandwidth is that is available for the > computation implicitly from the already available parameters. You are > quite right that for distributed model to support more flexible > protection > strategies, the IGP extension defining the value of the backup pool is > necessary. Yes, for your model, that is what I thought would be necessary. (There are other shared models, where the sharing is not necessarily as good as what might be possible in your approach, where new IGP extensions could be avoided, but that is the subject of another discussion.) > >v) Section 7, pp. 17, para 3, mentions that "the first case [a downstream > >router fails but a link does not] is typically identifiable by means of > >RSVP Hellos or some fast IGP Hellos mechanism". How so? If I > don't receive > >Hellos, I know I cannot reach my neighbor, but cannot say anything about > >whether > >my neighbor or our intervening link is down. Yes? > > You are quite right that if you do not receive a Hello, then just by that > fact you cannot tell whether it is a link or a node. But the > case that we > describe above and that we believe IS identifiable, is when you know two > things: > > 1) the link is UP > 2) there are no Hellos > > Then you do know it is the node that failed. The case where we > cannot tell > (and that is what requires additional currently undefined mechanisms) is > when the link is DOWN. Then of course there are no Hellos as > well, and you > cannot say whether it is the link or the node. Agreed. > >vi) Section 12 states that the PCS being stateless is the preferred > >approach. > >How so? > >It seems that for the centralized computation model (with zero b/w > >reservations > >for backup LSPs) to work, the PCS must keep state on which primary and > >backup > >LSPs are placed where, on how much b/w each uses, and on the residual > >bandwidth > >of each network link. > > We meant to say that it is for the distributed approach that it is > preferable to have a stateless PCS. We should make sure it is clear from > the text. You are quite right that in the centralized model (or > at least in > some implementations of the centralized model), the server cannot be > stateless. Note however that a centralized model COULD be stateless as > well if what it is backing up is the bandwidth pools rather than > the actual > amount of used primary bandwidth. But, even in the bandwidth pools case, would the PCS not have (or want to) keep track of which primary LSPs can be backed on to which secondary LSPs (to communicate this to the respective head ends), so that, upon failure, the HE's know exactly what to backup where (that is, which traffic to direct where), and can set up their tables accordingly. -Vishal From owner-mpls@UU.NET Thu Oct 3 13:34:03 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26795 for ; Thu, 3 Oct 2002 13:34:03 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnizu03774 for ; Thu, 3 Oct 2002 17:35:58 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnizu03042; Thu, 3 Oct 2002 17:35:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQnizu24592 for mpls-outgoing; Thu, 3 Oct 2002 17:34:26 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnizu24587 for ; Thu, 3 Oct 2002 17:34:26 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnizu29572 for ; Thu, 3 Oct 2002 17:33:38 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnizu26019 for ; Thu, 3 Oct 2002 17:33:37 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnizu26002 for ; Thu, 3 Oct 2002 17:33:37 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA13816 for ; Thu, 3 Oct 2002 13:33:36 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g93HXaW01208 for mpls@uu.net; Thu, 3 Oct 2002 13:33:36 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnizt24333 for ; Thu, 3 Oct 2002 17:29:24 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnizt06901 for ; Thu, 3 Oct 2002 17:27:57 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnizt20734 for ; Thu, 3 Oct 2002 17:27:57 GMT Received: from momus.sc.intel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: momus.sc.intel.com [143.183.152.8]) id QQnizt16801 for ; Thu, 3 Oct 2002 17:25:07 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by momus.sc.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.46 2002/09/23 20:41:22 dmccart Exp $) with SMTP id g93HOJ625792 for ; Thu, 3 Oct 2002 17:24:39 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002100310255109582 for ; Thu, 03 Oct 2002 10:25:51 -0700 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Oct 2002 10:24:19 -0700 Message-ID: From: "Feng, Mark" To: mpls@UU.NET Subject: RE: ERO processing Date: Thu, 3 Oct 2002 10:24:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I believe the processing are the same. I think you should read the few sections before the quoted paragraph in the RSVP spec. Hope this helps. - Mark > -----Original Message----- > From: chetan kumar s [mailto:chetan.kumar@wipro.com] > Sent: Wednesday, October 02, 2002 9:13 PM > To: mpls@UU.NET > Subject: ERO processing > > > Hi, > > While processing ERO object, there seems to discrepancy in the > statements made in CR-LDP (RFC 3212) and RSVPTE (3209) to > process initial > ERO. CR-LDP considers 'L' bit and RSVPTE do not consider 'L' > bit. What is > the rationale behind this, I would say RSVPTE also should > consider L bit. > There were couple of mails on this in the mailing list but > there were no > fitting answers. Can the authors pls clarify.. > > > RCF 3212: > > 1. The node receiving the Label Request Message must first > evaluate the first ER-Hop. If the L bit is not set in the > first ER-Hop and if the node is not part of the abstract node > described by the first ER-Hop, it has received the message in > error, and should return a "Bad Initial ER-Hop Error" status. > > RCF 3209: > > 1) The node receiving the RSVP message MUST first evaluate the first > subobject. If the node is not part of the abstract > node described > by the first subobject, it has received the message in error and > SHOULD return a "Bad initial subobject" error. > > > Thanks > Chetan S > > -- > ------------ > Thinking is progress, non thinking is destruction of > individual, organization > and nation > > -Abdul Kalam > From owner-mpls@UU.NET Thu Oct 3 14:10:49 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28639 for ; Thu, 3 Oct 2002 14:10:49 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnizw08116 for ; Thu, 3 Oct 2002 18:12:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnizw07460; Thu, 3 Oct 2002 18:12:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQnizw13987 for mpls-outgoing; Thu, 3 Oct 2002 18:12:04 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnizw13982 for ; Thu, 3 Oct 2002 18:12:01 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnizw24595 for ; Thu, 3 Oct 2002 18:11:43 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnizw26218 for ; Thu, 3 Oct 2002 18:11:43 GMT Received: from mtiwmhc12.worldnet.att.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mtiwmhc12.worldnet.att.net [204.127.131.116]) id QQnizw26134 for ; Thu, 3 Oct 2002 18:11:33 GMT Received: from 6640bbc3r131 ([12.81.1.221]) by mtiwmhc12.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with SMTP id <20021003181052.DYDB12219.mtiwmhc12.worldnet.att.net@6640bbc3r131>; Thu, 3 Oct 2002 18:10:52 +0000 Message-ID: <014c01c26b08$58f72ee0$dd01510c@6640bbc3r131> From: "Brijesh Kumar" To: "Riccardo" , References: <001001c269f7$18f71600$eeadf781@MOBDN238> Subject: Re: problem with MPLS Traffic Engineering over ATM Date: Thu, 3 Oct 2002 11:08:32 -0700 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.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ricardo, The only way to run MPLS control protocols on old ATM switches is by adding a new card that can run IP control plane for MPLS, and upgrading the rest of the software. IP control plane can also run externally on a linux platform as long as it has someway of interfacing with the ATM switch and its software. In any case, you need software upgrade. Vendors, including Cisco, are using one of these two options. Cheers, --brijesh ----- Original Message ----- From: "Riccardo" To: Sent: Wednesday, October 02, 2002 2:35 AM Subject: problem with MPLS Traffic Engineering over ATM > I'm working here in Germany to prepare for my degree. I'm studing Mpls > and exactly how MPLS could be used in a Satellite Networks. I've just > started my work reading Bruce Davie's Mpls book and some RFC, but I've a > problem (maybe trivial). > > I've read that both LDP, CR-LDP and RSVP uses IP to be transported (do > not?).How could these protocols be implemented in an ATM Network where > Ip is not used? > > If you have some material or hint that could help me please reply this > e-mail. > Thanks for everything and excuse me for the intrusion. > ------------------------------------------ > Riccardo Menichelli > German Aerospace Center (DLR) > Institute of Communications and Navigation > > phone: +49 8153 28-2819 > fax: +49 8153 28-2844 > email: riccardo@zeus.nt.op.dlr.de > > http://www.dlr.de/KN/KN-DN/ > ------------------------------------------ > > > From owner-mpls@UU.NET Fri Oct 4 05:57:29 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27284 for ; Fri, 4 Oct 2002 05:57:29 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjch06005 for ; Fri, 4 Oct 2002 09:59:27 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnjch05268; Fri, 4 Oct 2002 09:59:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQnjch26495 for mpls-outgoing; Fri, 4 Oct 2002 09:58:46 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnjch26490 for ; Fri, 4 Oct 2002 09:58:37 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnjch15229 for ; Fri, 4 Oct 2002 09:56:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjch09004 for ; Fri, 4 Oct 2002 09:56:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnjch08976 for ; Fri, 4 Oct 2002 09:56:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id FAA21296 for ; Fri, 4 Oct 2002 05:56:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g949u2Z17833 for mpls@uu.net; Fri, 4 Oct 2002 05:56:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnjch26268 for ; Fri, 4 Oct 2002 09:55:37 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnjch24986 for ; Fri, 4 Oct 2002 09:54:52 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjch02520 for ; Fri, 4 Oct 2002 09:54:51 GMT Received: from ganesh.ctd.hctech.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQnjch02516 for ; Fri, 4 Oct 2002 09:54:49 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id <4F5VZJV0>; Fri, 4 Oct 2002 15:31:24 +0530 Message-ID: <55E277B99171E041ABF5F4B1C6DDCA069CCA09@haritha.hclt.com> From: "Vijayanand C - CTD, Chennai." To: pwe3@ietf.org, mpls@UU.NET Cc: luca@level3.net Subject: question in draft-ietf-pwe3-control-protocol-00.txt Date: Fri, 4 Oct 2002 15:26:05 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk In the draft "draft-ietf-pwe3-control-protocol-00.txt", the control bit handling procedures have been elaborated in section 5.2. If an optional TLV is used to signal the configuration of C bit in the local nodes( Ingress and Eggress) at the time of targetted session establishment, both the nodes would know the C bit preferablity of the other and could avoid sending messages with wrong C bit which introduces complexity to the protocol. The optional TLV can be carried in the Initialisation message of LDP or in the keepalive messages. Regards, Vijay From owner-mpls@UU.NET Fri Oct 4 09:44:48 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03761 for ; Fri, 4 Oct 2002 09:44:48 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjcx20194 for ; Fri, 4 Oct 2002 13:46:46 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnjcx19685; Fri, 4 Oct 2002 13:46:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQnjcx18488 for mpls-outgoing; Fri, 4 Oct 2002 13:46:04 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnjcx18400 for ; Fri, 4 Oct 2002 13:45:50 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnjcx15648 for ; Fri, 4 Oct 2002 13:45:11 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjcx11303 for ; Fri, 4 Oct 2002 13:45:10 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQnjcx11287 for ; Fri, 4 Oct 2002 13:45:10 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA15570; Fri, 4 Oct 2002 09:44:57 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA08489; Fri, 4 Oct 2002 09:44:58 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 4 Oct 2002 09:44:49 -0400 Message-ID: <39469E08BD83D411A3D900204840EC5541FDE6@vie-msgusr-01.dc.fore.com> From: "Kumar, Srivatsa" To: "'Vijayanand C - CTD, Chennai.'" , pwe3@ietf.org, mpls@UU.NET Cc: luca@level3.net Subject: RE: [PWE3] question in draft-ietf-pwe3-control-protocol-00.txt Date: Fri, 4 Oct 2002 09:44:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Vijay, The C bit is used for the control word. Now the SAME targeted session between the the Ingress and Egress is used to signal various different VC types (like ATM AAL5 VCC/ Ethernet VLAN/HDLC/ PPP etc). Some of these would require control word and some of them might not. So the appropriate place for the C bit cannot be in the Session initialization. (unless of course you are creating seperate sessions for each VC type) Vatsa -----Original Message----- From: Vijayanand C - CTD, Chennai. [mailto:vijayc@ctd.hcltech.com] Sent: Friday, October 04, 2002 5:56 AM To: pwe3@ietf.org; mpls@uu.net Cc: luca@level3.net Subject: [PWE3] question in draft-ietf-pwe3-control-protocol-00.txt In the draft "draft-ietf-pwe3-control-protocol-00.txt", the control bit handling procedures have been elaborated in section 5.2. If an optional TLV is used to signal the configuration of C bit in the local nodes( Ingress and Eggress) at the time of targetted session establishment, both the nodes would know the C bit preferablity of the other and could avoid sending messages with wrong C bit which introduces complexity to the protocol. The optional TLV can be carried in the Initialisation message of LDP or in the keepalive messages. Regards, Vijay _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From owner-mpls@UU.NET Mon Oct 7 02:16:24 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08508 for ; Mon, 7 Oct 2002 02:16:23 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjmv02353 for ; Mon, 7 Oct 2002 06:18:24 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnjmv01991; Mon, 7 Oct 2002 06:18:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQnjmv03960 for mpls-outgoing; Mon, 7 Oct 2002 06:18:00 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnjmv03955 for ; Mon, 7 Oct 2002 06:17:51 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnjmv01198 for ; Mon, 7 Oct 2002 06:17:17 GMT From: daipayan_kar-choudhuri@agilent.com Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjmv01502 for ; Mon, 7 Oct 2002 06:17:16 GMT Received: from msgbas1.sgp.agilent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: msgbas1x.net.asiapac.agilent.com [192.25.42.26]) id QQnjmv01498 for ; Mon, 7 Oct 2002 06:17:15 GMT Received: from msgrel1.sgp.agilent.com (msgrel1.sgp.agilent.com [141.183.101.233]) by msgbas1.sgp.agilent.com (Postfix) with ESMTP id 856AE23F for ; Mon, 7 Oct 2002 14:17:14 +0800 (SGP) Received: from apbrg1.sgp.agilent.com (apbrg1.sgp.agilent.com [141.183.6.40]) by msgrel1.sgp.agilent.com (Postfix) with SMTP id 907BC523 for ; Mon, 7 Oct 2002 14:17:07 +0800 (SGP) Received: from 141.183.6.40 by apbrg1.sgp.agilent.com (InterScan E-Mail VirusWall NT); Mon, 07 Oct 2002 14:17:13 +0800 Received: by apbrg1.sgp.agilent.com with Internet Mail Service (5.5.2653.19) id <4H4HD8CK>; Mon, 7 Oct 2002 14:17:13 +0800 Message-ID: <89D04169635E024E8FD2174A852D788B82D3BA@apmail16.ind.agilent.com> To: mpls@UU.NET Subject: Martini Label Withdraw/Release Date: Mon, 7 Oct 2002 14:17:37 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, According to section 5.3 of draft-martini-l2circuit-trans-mpls-10.txt "The interface parameters field MUST NOT be present in any LDP VC label withdrawal message or release message " If a Label Release/withdraw Message containing interface parameter is sent to PE LSR what will be the expected behavior of the PE LSR. Will it generate notification message or will silently discard the message ? Regards, Daipayan From owner-mpls@UU.NET Mon Oct 7 02:44:09 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09057 for ; Mon, 7 Oct 2002 02:44:09 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjmx06536 for ; Mon, 7 Oct 2002 06:46:08 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnjmx05753; Mon, 7 Oct 2002 06:45:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQnjmx05655 for mpls-outgoing; Mon, 7 Oct 2002 06:45:21 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnjmx05648 for ; Mon, 7 Oct 2002 06:45:17 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnjmw23333 for ; Mon, 7 Oct 2002 06:44:15 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjmw05289 for ; Mon, 7 Oct 2002 06:44:15 GMT Received: from blooper.utfors.se by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQnjmw05283 for ; Mon, 7 Oct 2002 06:44:14 GMT Received: from utfors.se (nat-sto.utfors.se [212.73.0.237]) by blooper.utfors.se (8.12.6/8.12.6) with ESMTP id g976hvtA007621 for ; Mon, 7 Oct 2002 08:43:57 +0200 (MEST) Message-ID: <3DA12D2D.7040705@utfors.se> Date: Mon, 07 Oct 2002 08:43:57 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MPLS wg Subject: Atlanta cut off dates Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit All, the cut off dates for IDs for the Atlanta meeting are Initial drafts (00.txt): October 28 final cut off (for updates): November 4th For further information see the included mail that was sent to the "ietf announce" list September 30. /Loa ----------- included mail --------------------------- NOTE: There are two (2) Internet-Draft Cutoff dates October 28th: Cutoff for Initial Submissions (new documents) All initial submissions(-00) must be submitted by Monday, October 28th, at 09:00 ET. Initial submissions received after this time will NOT be made available in the Internet-Drafts directory, and will have to be resubmitted. As before, all initial submissions (-00.txt) with a filename beginning with a draft-ietf MUST be approved by the appropriate WG Chair prior to processing and announcing. WG Chair approval must be received by Monday, October 28th. Please do NOT wait until the last minute to submit. Be advised: NO placeholders. Updates to initial submissions received the week of October 28th will NOT be accepted. November 4th: FINAL Internet-Draft Cutoff All revised Internet-Draft submissions must be submitted by Monday, November 4th, 2002 at 09:00 ET. Internet-Drafts received after this time will NOT be announced NOR made available in the Internet-Drafts Directories. We will begin accepting Internet-Draft submissions the week of the meeting, though announcements will NOT be sent until the IETF meeting is over. Thank you for your understanding and cooperation. Please do not hesitate to contact us if you have any questions or concenrs. FYI: These and other significant dates can be found at http://www.ietf.org/meetings/cutoff_dates_55.html -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se From owner-mpls@UU.NET Mon Oct 7 16:09:38 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03710 for ; Mon, 7 Oct 2002 16:09:38 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjoy00289 for ; Mon, 7 Oct 2002 20:11:39 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnjoy29624; Mon, 7 Oct 2002 20:11:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQnjoy22514 for mpls-outgoing; Mon, 7 Oct 2002 20:10:43 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnjoy22472 for ; Mon, 7 Oct 2002 20:10:38 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnjoy23564 for ; Mon, 7 Oct 2002 20:10:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjoy03032 for ; Mon, 7 Oct 2002 20:10:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnjoy03009 for ; Mon, 7 Oct 2002 20:10:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA07715 for ; Mon, 7 Oct 2002 16:10:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g97KA2D18180 for mpls@uu.net; Mon, 7 Oct 2002 16:10:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnjoy22161 for ; Mon, 7 Oct 2002 20:09:13 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnjoy14101 for ; Mon, 7 Oct 2002 20:07:57 GMT Received: from motgate2.mot.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: motgate2.mot.com [136.182.1.10]) id QQnjow07595 for ; Mon, 7 Oct 2002 19:35:55 GMT Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id MAA16474 for ; Mon, 7 Oct 2002 12:08:19 -0700 (MST)] Received: [from ma19exm01.e2.bcs.mot.com (ma19exm01.e2.bcs.mot.com [10.14.8.10]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id MAA10213 for ; Mon, 7 Oct 2002 12:08:15 -0700 (MST)] Received: by ma19exm01.e2.bcs.mot.com with Internet Mail Service (5.5.2654.52) id ; Mon, 7 Oct 2002 15:08:15 -0400 Message-ID: <62173B970AE0A044AED8723C3BCF238139C947@ma19exm01.e2.bcs.mot.com> From: Shah Miral-MGIA0588 To: "'mpls@uu.net'" Subject: Any RFC that explains the MIB for RSVP-TE Date: Mon, 7 Oct 2002 15:08:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > Hi, > > I have been rummaging thru the RFC's and thru the interenet drafts to > find out if there was any standardised RFC for the RSVP-TE MIBS.. But i am > not able to find any.. Any suggestions on if there is any inforamtion on > MIBS for RSVP-TE and if there is, then where can i find it..? > > Regrds, > > Miral.. > From owner-mpls@UU.NET Mon Oct 7 19:22:06 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09577 for ; Mon, 7 Oct 2002 19:22:06 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjpl19986 for ; Mon, 7 Oct 2002 23:24:07 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnjpl19195; Mon, 7 Oct 2002 23:23:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQnjpl25988 for mpls-outgoing; Mon, 7 Oct 2002 23:22:34 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnjpl25983 for ; Mon, 7 Oct 2002 23:22:31 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnjpl08225 for ; Mon, 7 Oct 2002 23:21:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjpl17268 for ; Mon, 7 Oct 2002 23:21:02 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnjpl17260 for ; Mon, 7 Oct 2002 23:21:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA21336 for ; Mon, 7 Oct 2002 19:21:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g97NL2L27894 for mpls@uu.net; Mon, 7 Oct 2002 19:21:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnjpl25783 for ; Mon, 7 Oct 2002 23:20:07 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnjpl04541 for ; Mon, 7 Oct 2002 23:19:18 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjpl16235 for ; Mon, 7 Oct 2002 23:19:18 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQnjpl16228 for ; Mon, 7 Oct 2002 23:19:17 GMT Received: from toque.cisco.com (IDENT:mirapoint@toque.cisco.com [161.44.201.11]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g97NJGIm006632 for ; Mon, 7 Oct 2002 16:19:17 -0700 (PDT) Received: from ANCAZ-W2K.cisco.com (che-vpn2-33.cisco.com [10.86.244.33]) by toque.cisco.com (Mirapoint) with ESMTP id AAN04516; Mon, 7 Oct 2002 19:11:49 -0400 (EDT) Message-Id: <4.3.2.7.2.20021007185301.03512828@toque.cisco.com> X-Sender: ancaz@toque.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 07 Oct 2002 19:19:12 -0400 To: "'mpls@uu.net'" From: Anca Zamfir Subject: Clarification on RSVP Restart Procedure Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have a couple of questions regarding the RSVP restart procedure: In draft-ietf-mpls-generalized-rsvp-te-07.txt, section 9.5.2. "Procedures for the Restarting node", one of its paragraph reads: "In the special case where a restarting node also has a resta(r)ting downstream neighbor, a Recovery_Label object should be used instead of a Suggested_Label object." This implies that the restarting node - N1 is able to detect that its downstream neighbor - N2 has also restarted, that is N1, N2 is the restarting order. For the LSPs established from N2 to N1, since N2 cannot detect that N1 has restarted, N2 will send Path messages using the Suggested Label. In this case N1 will not be able to differentiate the case where this message is a new Path message sent with Suggested Label or a Path message for an old LSP for which recovery happens. Is N1 expected to handle the two cases in the same way? If yes, why was the Recovery Label "invented" and why wasn't the Suggested Label considered good for the RSVP restart procedure? Thanks, Anca From owner-mpls@UU.NET Mon Oct 7 20:07:29 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10533 for ; Mon, 7 Oct 2002 20:07:29 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjpo24651 for ; Tue, 8 Oct 2002 00:09:32 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnjpo24020; Tue, 8 Oct 2002 00:09:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQnjpo15100 for mpls-outgoing; Tue, 8 Oct 2002 00:08:43 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnjpo15091 for ; Tue, 8 Oct 2002 00:08:40 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnjpo05537 for ; Tue, 8 Oct 2002 00:08:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjpo22809 for ; Tue, 8 Oct 2002 00:08:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnjpo22790 for ; Tue, 8 Oct 2002 00:08:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA23800 for ; Mon, 7 Oct 2002 20:08:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g98082b01314 for mpls@uu.net; Mon, 7 Oct 2002 20:08:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnjpo14741 for ; Tue, 8 Oct 2002 00:06:45 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnjpo20043 for ; Tue, 8 Oct 2002 00:06:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjpo21553 for ; Tue, 8 Oct 2002 00:06:02 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnjpo21540 for ; Tue, 8 Oct 2002 00:06:02 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g98065bo006748; Mon, 7 Oct 2002 20:06:05 -0400 (EDT) Received: from tnadeau-w2k.cisco.com (che-vpn1-49.cisco.com [10.86.240.49]) by bucket.cisco.com (Mirapoint) with ESMTP id ABX42823; Mon, 7 Oct 2002 20:05:58 -0400 (EDT) Message-Id: <4.3.2.7.2.20021007200508.01e67a28@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 07 Oct 2002 20:05:55 -0400 To: Shah Miral-MGIA0588 From: "Thomas D. Nadeau" Subject: Re: Any RFC that explains the MIB for RSVP-TE Cc: "'mpls@uu.net'" In-Reply-To: <62173B970AE0A044AED8723C3BCF238139C947@ma19exm01.e2.bcs.mo t.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Take a look at: http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-mib-08.txt --Tom > > Hi, > > > > I have been rummaging thru the RFC's and thru the interenet drafts to > > find out if there was any standardised RFC for the RSVP-TE MIBS.. But i am > > not able to find any.. Any suggestions on if there is any inforamtion on > > MIBS for RSVP-TE and if there is, then where can i find it..? > > > > Regrds, > > > > Miral.. > > Success is relative; the more success, the more relatives. -Anonymous From owner-mpls@UU.NET Tue Oct 8 00:03:46 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17816 for ; Tue, 8 Oct 2002 00:03:46 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjqe27465 for ; Tue, 8 Oct 2002 04:05:48 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnjqe26934; Tue, 8 Oct 2002 04:05:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQnjqe07483 for mpls-outgoing; Tue, 8 Oct 2002 04:05:06 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnjqe07477 for ; Tue, 8 Oct 2002 04:05:02 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnjqe02040 for ; Tue, 8 Oct 2002 04:04:17 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjqe10715 for ; Tue, 8 Oct 2002 04:04:16 GMT Received: from wiprom2mx1.wipro.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQnjqe10710 for ; Tue, 8 Oct 2002 04:04:14 GMT Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g9844B209416 for ; Tue, 8 Oct 2002 09:34:11 +0530 (IST) Received: from soflt.ipneg.wipro.com ([10.117.3.193]) by kmglmail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id H3N9YU00.F0F; Tue, 8 Oct 2002 09:34:06 +0530 Date: Tue, 8 Oct 2002 09:32:34 +0530 (IST) From: "chetan kumar s" X-X-Sender: Reply-To: To: cc: , Subject: ERO processing.. Asking again.. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, While processing ERO object, there seems to discrepancy in the statements made in CR-LDP (RFC 3212) and RSVPTE (3209) to process initial ERO. CR-LDP considers 'L' bit and RSVPTE do not consider 'L' bit. What is the rationale behind this, I would say RSVPTE also should consider L bit. There were couple of mails on this in the mailing list but there were no fitting answers. Can the authors pls clarify.. RCF 3212: 1. The node receiving the Label Request Message must first evaluate the first ER-Hop. If the L bit is not set in the first ER-Hop and if the node is not part of the abstract node described by the first ER-Hop, it has received the message in error, and should return a "Bad Initial ER-Hop Error" status. RCF 3209: 1) The node receiving the RSVP message MUST first evaluate the first subobject. If the node is not part of the abstract node described by the first subobject, it has received the message in error and SHOULD return a "Bad initial subobject" error. Thanks Chetan S From owner-mpls@UU.NET Tue Oct 8 00:28:55 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19200 for ; Tue, 8 Oct 2002 00:28:55 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjqg19602 for ; Tue, 8 Oct 2002 04:30:57 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnjqg18810; Tue, 8 Oct 2002 04:30:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQnjqg10122 for mpls-outgoing; Tue, 8 Oct 2002 04:30:08 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnjqf10087 for ; Tue, 8 Oct 2002 04:29:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnjqf16132 for ; Tue, 8 Oct 2002 04:29:50 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjqf24677 for ; Tue, 8 Oct 2002 04:29:49 GMT Received: from gateway.ipinfusion.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.ipinfusion.com [65.223.109.2]) id QQnjqf24673 for ; Tue, 8 Oct 2002 04:29:49 GMT Received: from ipinfusion.com (linksys.ipinfusion.com [10.10.0.231] (may be forged)) by gateway.ipinfusion.com (8.11.6/8.11.6) with ESMTP id g981vDh02979 for ; Mon, 7 Oct 2002 18:57:14 -0700 Message-ID: <3DA23B91.6020704@ipinfusion.com> Date: Mon, 07 Oct 2002 18:57:37 -0700 From: Haseeb Budhani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: mpls@UU.NET Subject: Question about http://www.ietf.org/internet-drafts/draft-ietf-mpls-tc-mib-03.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I am having trouble understanding how the MplsLSPID for IPv4 end-points ends up being 6 octets in this draft. Any help will be appreciated. -- Haseeb Budhani. IPInfusion Inc. From owner-mpls@UU.NET Tue Oct 8 04:36:29 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03537 for ; Tue, 8 Oct 2002 04:36:28 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjqw26032 for ; Tue, 8 Oct 2002 08:38:31 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnjqw25691; Tue, 8 Oct 2002 08:38:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQnjqw03102 for mpls-outgoing; Tue, 8 Oct 2002 08:37:49 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnjqw03097 for ; Tue, 8 Oct 2002 08:37:37 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnjqw21070 for ; Tue, 8 Oct 2002 08:37:18 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjqw06613 for ; Tue, 8 Oct 2002 08:37:17 GMT Received: from mailgw.local.ipunplugged.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 217.134.88.213.host.tele1europe.se [213.88.134.217]) id QQnjqw06589 for ; Tue, 8 Oct 2002 08:37:13 GMT Received: from ipunplugged.com (echo.local.ipunplugged.com [192.168.4.74]) by mailgw.local.ipunplugged.com (8.12.3/8.12.3) with ESMTP id g988aU24004084; Tue, 8 Oct 2002 10:36:31 +0200 Message-ID: <3DA29871.7040601@ipunplugged.com> Date: Tue, 08 Oct 2002 10:33:53 +0200 From: =?ISO-8859-1?Q?Hans_Sj=F6strand?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Haseeb Budhani CC: mpls@UU.NET Subject: Re: Question about http://www.ietf.org/internet-drafts/draft-ietf-mpls-tc-mib-03.txt References: <3DA23B91.6020704@ipinfusion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.4.1(snapshot 20020919) (mailgw) Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit The updated version of the MPLS-TC-MIB clarifies this. MplsLSPID ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A unique identifier within an MPLS network that is assigned to each LSP. This is assigned at the head end of the LSP and can be used by all LSRs to identify this LSP. This value is piggybacked by the signaling protocol when this LSP is signaled within the network. This identifier can then be used at each LSR to identify which labels are being swapped to other labels for this LSP. This object can also be used to disambiguate LSPs that share the same RSVP sessions between the same source and destination. For LSPs established using CR-LDP, the LSPID is composed of the ingress LSR Router ID (or any of its own IPv4 addresses) and a locally unique CR-LSP ID to that LSR. The first two bytes carry the CR-LSPID, and the remaining 4 bytes carry the Router ID. The LSPID is useful in network management, in CR-LSP repair, and in using an already established CR-LSP as a hop in an ER-TLV. For LSPs signaled using RSVP-TE, the LSP ID is defined as a 16-bit (2 byte) identifier used in the SENDER_TEMPLATE and the FILTER_SPEC that can be changed to allow a sender to share resources with itself. The length of this object should only be 2 or 6 bytes. If the length of this octet string is 2 bytes, then it must identify an RSVP-TE LSPID, or it is 6 bytes, it must contain a CR-LDP LSPID." REFERENCE "See [RFC3209] for RSVP-TE LSPID and [RFC3212] for LSPID in CR-LDP." SYNTAX OCTET STRING (SIZE (2|6)) A new draft is expected to be out within a few days. It's being revised in the IESG review process together with the other mibs being reviewed (LSP, TE, FTN, LDP). Regards /// Hasse Haseeb Budhani wrote: > I am having trouble understanding how the MplsLSPID for IPv4 end-points > ends up being 6 octets in this draft. > > Any help will be appreciated. > From owner-mpls@UU.NET Tue Oct 8 07:18:18 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06523 for ; Tue, 8 Oct 2002 07:18:18 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjrh13572 for ; Tue, 8 Oct 2002 11:20:21 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnjrh13094; Tue, 8 Oct 2002 11:20:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQnjrh04060 for mpls-outgoing; Tue, 8 Oct 2002 11:19:52 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnjrh04055 for ; Tue, 8 Oct 2002 11:19:38 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnjrh07385 for ; Tue, 8 Oct 2002 11:19:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjrh12202 for ; Tue, 8 Oct 2002 11:19:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnjrh12195 for ; Tue, 8 Oct 2002 11:19:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA24842 for ; Tue, 8 Oct 2002 07:19:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g98BJ2g03331 for mpls@uu.net; Tue, 8 Oct 2002 07:19:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnjrh04019 for ; Tue, 8 Oct 2002 11:18:05 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnjrh23590 for ; Tue, 8 Oct 2002 11:16:41 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjrh11053 for ; Tue, 8 Oct 2002 11:16:40 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQnjrh11048 for ; Tue, 8 Oct 2002 11:16:40 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06300; Tue, 8 Oct 2002 07:14:24 -0400 (EDT) Message-Id: <200210081114.HAA06300@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-crldp-unnum-08.txt Date: Tue, 08 Oct 2002 07:14:24 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --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 : Signalling Unnumbered Links in CR-LDP Author(s) : K. Kompella, Y. Rekhter, A. Kullberg Filename : draft-ietf-mpls-crldp-unnum-08.txt Pages : 7 Date : 2002-10-7 Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) doesn't provide support for unnumbered links. This document defines procedures and extensions to Constraint-Routing Label Distribution Protocol (CR-LDP), one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-crldp-unnum-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-crldp-unnum-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-crldp-unnum-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-7141322.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-crldp-unnum-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-crldp-unnum-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-7141322.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Oct 8 10:33:42 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15363 for ; Tue, 8 Oct 2002 10:33:42 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjru28287 for ; Tue, 8 Oct 2002 14:35:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnjru27507; Tue, 8 Oct 2002 14:35:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQnjru06881 for mpls-outgoing; Tue, 8 Oct 2002 14:35:01 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnjru06864 for ; Tue, 8 Oct 2002 14:34:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnjru10895 for ; Tue, 8 Oct 2002 14:33:54 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjru26470 for ; Tue, 8 Oct 2002 14:33:54 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnjru26466 for ; Tue, 8 Oct 2002 14:33:53 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA06721 for ; Tue, 8 Oct 2002 10:33:53 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g98EXrM13131 for mpls@uu.net; Tue, 8 Oct 2002 10:33:53 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnjpf16406 for ; Mon, 7 Oct 2002 21:49:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnjpf06482 for ; Mon, 7 Oct 2002 21:47:43 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjpf22931 for ; Mon, 7 Oct 2002 21:47:43 GMT Received: from petasus.ch.intel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: petasus.ch.intel.com [143.182.124.5]) id QQnjpf22919 for ; Mon, 7 Oct 2002 21:47:42 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.46 2002/09/23 20:41:22 dmccart Exp $) with SMTP id g97LnA225973 for ; Mon, 7 Oct 2002 21:49:10 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002100714413108455 ; Mon, 07 Oct 2002 14:41:31 -0700 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Oct 2002 14:43:10 -0700 Message-ID: From: "Sharma, Prem" To: "'Shah Miral-MGIA0588'" , "'mpls@uu.net'" Subject: RE: Any RFC that explains the MIB for RSVP-TE Date: Mon, 7 Oct 2002 14:43:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Miral, There is no separate MIB as such for RSVP-TE. The same LSR, TE and FTN MIBs are applicable for RSVP-TE based MPLS-enabled node too. These MIBs are supposedly agnostic to mpls signalling protocol in operation. For pure RSVP protocol though, there is RFC 2206 for RSVP MIB. -Prem -----Original Message----- From: Shah Miral-MGIA0588 [mailto:miralshah@motorola.com] Sent: Monday, October 07, 2002 12:08 PM To: 'mpls@uu.net' Subject: Any RFC that explains the MIB for RSVP-TE > Hi, > > I have been rummaging thru the RFC's and thru the interenet drafts to > find out if there was any standardised RFC for the RSVP-TE MIBS.. But i am > not able to find any.. Any suggestions on if there is any inforamtion on > MIBS for RSVP-TE and if there is, then where can i find it..? > > Regrds, > > Miral.. > From owner-mpls@UU.NET Tue Oct 8 14:48:13 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25926 for ; Tue, 8 Oct 2002 14:48:13 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjrt17281 for ; Tue, 8 Oct 2002 14:28:07 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnjrt16325; Tue, 8 Oct 2002 14:27:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQnjrt06497 for mpls-outgoing; Tue, 8 Oct 2002 14:27:21 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnjrt06492 for ; Tue, 8 Oct 2002 14:27:20 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnjrt24958 for ; Tue, 8 Oct 2002 14:26:18 GMT From: iodemo@isocore.com Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjrt15195 for ; Tue, 8 Oct 2002 14:26:18 GMT Received: from mail.san.yahoo.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.san.yahoo.com [209.132.1.30]) id QQnjrt15186 for ; Tue, 8 Oct 2002 14:26:18 GMT Received: from [207.172.11.147] by mail.san.yahoo.com with HTTP; Tue, 8 Oct 2002 07:29:49 -0700 Date: Tue, 8 Oct 2002 10:29:49 -0400 Message-ID: <3D9BDC66000048F7@mta05.san.yahoo.com> Subject: 3rd MPLS Public InterOp Demo and MPLS 2002 Update To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA25926 The 3rd MPLS Public Inter-Op Demo will be held in McLean, Virginia following the MPLS 2002 International Conference (http://www.mpls2002.com) in Washington, D.C. The scope of the demo includes a Core implementing Fast Reroute, and PE/CE boxes running L2/L3 VPNs. Participating vendors include Avici Systems, Cisco Systems, CoSine Communications, Extreme Networks, Foundry Networks, Ixia, Juniper Networks, Lucent Technologies, Marconi, NetTest, Redback Networks, Spirent Communications, and others. Registered attendees of the MPLS 2002 International Conference who would like to attend the InterOp Demo should send an e-mail to iodemo@isocore.com. Space is limited and invitations will be issued on a first come first serve basis. The original block of hotel rooms at the Omni Shoreham hotel, that was being offered at special rates for the MPLS 2002 International conference, has been filled. A few additional rooms are being made available at the same rate through October 10th. From owner-mpls@UU.NET Tue Oct 8 18:02:12 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02168 for ; Tue, 8 Oct 2002 18:02:11 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjsy16072 for ; Tue, 8 Oct 2002 22:04:09 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnjsy15428; Tue, 8 Oct 2002 22:03:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQnjsy03335 for mpls-outgoing; Tue, 8 Oct 2002 22:02:58 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnjsy03286 for ; Tue, 8 Oct 2002 22:02:47 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnjsy00404 for ; Tue, 8 Oct 2002 22:02:16 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjsy13544 for ; Tue, 8 Oct 2002 22:02:15 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnjsy13499 for ; Tue, 8 Oct 2002 22:02:13 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA14730 for ; Tue, 8 Oct 2002 18:02:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g98M22105482 for mpls@uu.net; Tue, 8 Oct 2002 18:02:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnjsy01727 for ; Tue, 8 Oct 2002 22:00:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnjsx22868 for ; Tue, 8 Oct 2002 21:59:42 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjsx11770 for ; Tue, 8 Oct 2002 21:59:42 GMT Received: from hawk.CrescentNetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hawk.crescentnetworks.com [66.105.92.144]) id QQnjsx11761 for ; Tue, 8 Oct 2002 21:59:41 GMT Received: from CrescentNetworks.com (jcucchiara.in.crescentnets.com [192.168.29.132]) by hawk.CrescentNetworks.com (8.9.3/8.9.3) with ESMTP id RAA20683; Tue, 8 Oct 2002 17:24:04 -0400 (EDT) Message-ID: <3DA34CFE.B344D8BA@CrescentNetworks.com> Date: Tue, 08 Oct 2002 17:24:14 -0400 From: Joan Cucchiara X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Loa Andersson CC: MPLS wg , George Swallow , Bert Wijnen , Scott Bradner Subject: Mpls MIB status - Open MIB review meeting - November 16th References: <3D8F1D2F.6060401@utfors.se> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hello Folks, Mpls MIB co-authors have been asked about the status of the MPLS MIBs for the Open MIB review meeting in Atlanta. 4 mibs will be submitted to the IETF repository on Friday, Oct 11th and should be available from the IETF repository Friday afternoon US Eastern time. These are: MPLS-TC-MIB, MPLS-LSR-MIB, MPLS-LDP-MIB and MPLS-FTN-MIB. These MIBs have updates based on IESG review comments. An updated MPLS-TE-MIB will follow at a later date. Thanks, -Joan Loa Andersson wrote: > > All, > > At the MPLS Working Group meeting in Yokohama Bert Wijnen presented > the experiences from the MIB doctor reviews of the MPLS MIBs. It is > our feeling that there still is some way to go before we have the > consensus on MIBs and the MIB structure we need. > > The WG chairs and the AD for O&M Bert Wijnen has decided to call a > MIB meeting meeting in Atlanta with participation from the main MIB > MPLS authors, MIB implementors and people from the MIB Doctors team. > > At the meeting the individual MIBs will be reviewed to some extent, > but the main focus on this meeting should be on that the MPLS MIBs as > a group has an internal logic and consistency. > > We therefore suggest an open meeting on the Saturday before the next > IETF meeting (November 16th) in Atlanta. > > There will a further mail with venue and other meeting information > sent out shortly. There will also be mail requesting some information > on MIB implementation and deployment. > > /Loa, George and Bert > > -- > Loa Andersson > Chief Architect, > Utfors Research, Architecture and Future Lab (URAX) > Utfors AB > Råsundavägen 12 > Box 525, 169 29 Solna > Office +46 8 5270 2000 > Office direct +46 8 5270 5038 > Mobile +46 70 848 5038 > Email loa.andersson@utfors.se > WWW www.utfors.se From owner-mpls@UU.NET Wed Oct 9 16:03:34 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02106 for ; Wed, 9 Oct 2002 16:03:34 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjwi29449 for ; Wed, 9 Oct 2002 20:05:35 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnjwi27527; Wed, 9 Oct 2002 20:04:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQnjwi11176 for mpls-outgoing; Wed, 9 Oct 2002 20:04:22 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnjwi11151 for ; Wed, 9 Oct 2002 20:04:13 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnjwi09415 for ; Wed, 9 Oct 2002 20:03:54 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjwi27404 for ; Wed, 9 Oct 2002 20:03:54 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f52.law14.hotmail.com [64.4.21.52]) id QQnjwi27382 for ; Wed, 9 Oct 2002 20:03:53 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 9 Oct 2002 13:03:33 -0700 Received: from 206.54.51.125 by lw14fd.law14.hotmail.msn.com with HTTP; Wed, 09 Oct 2002 20:03:32 GMT X-Originating-IP: [206.54.51.125] From: "Hitesh Kulkarni" To: mpls@UU.NET Subject: what's the status of draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt Date: Wed, 09 Oct 2002 13:03:32 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Oct 2002 20:03:33.0291 (UTC) FILETIME=[F1F1FFB0:01C26FCE] Sender: owner-mpls@UU.NET Precedence: bulk Expiry date says July 2002.. Has it gone through the last call already or it has been discontinued ?? Thanks _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From owner-mpls@UU.NET Wed Oct 9 16:12:43 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02739 for ; Wed, 9 Oct 2002 16:12:43 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjwi13732 for ; Wed, 9 Oct 2002 20:14:45 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnjwi12526; Wed, 9 Oct 2002 20:14:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQnjwi13331 for mpls-outgoing; Wed, 9 Oct 2002 20:13:46 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnjwi13325 for ; Wed, 9 Oct 2002 20:13:29 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnjwi03066 for ; Wed, 9 Oct 2002 20:12:22 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjwi10444 for ; Wed, 9 Oct 2002 20:12:21 GMT Received: from mlsrv1.avici.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host128.avici.com [208.246.215.128] (may be forged)) id QQnjwi10437 for ; Wed, 9 Oct 2002 20:12:21 GMT Received: from aatlas-lt.avici.com ([10.6.101.151]) by mlsrv1.avici.com (8.11.0/8.11.0) with ESMTP id g99KCJV22885; Wed, 9 Oct 2002 16:12:19 -0400 (EDT) Message-Id: <5.1.0.14.2.20021009161244.01f913f0@mailhost.avici.com> X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 09 Oct 2002 16:12:59 -0400 To: "Hitesh Kulkarni" From: Alia Atlas Subject: Re: what's the status of draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt Cc: mpls@UU.NET In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk A revised version is in progress and should be out soon. Alia At 01:03 PM 10/9/2002 -0700, Hitesh Kulkarni wrote: >Expiry date says July 2002.. Has it gone through the last call already or >it has been discontinued ?? Thanks > > > >_________________________________________________________________ >Join the world's largest e-mail service with MSN Hotmail. >http://www.hotmail.com > From owner-mpls@UU.NET Wed Oct 9 16:17:40 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03010 for ; Wed, 9 Oct 2002 16:17:39 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjwj10667 for ; Wed, 9 Oct 2002 20:19:41 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnjwj08705; Wed, 9 Oct 2002 20:18:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQnjwj13833 for mpls-outgoing; Wed, 9 Oct 2002 20:17:23 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnjwj13822 for ; Wed, 9 Oct 2002 20:17:20 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnjwj01366 for ; Wed, 9 Oct 2002 20:15:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjwj09087 for ; Wed, 9 Oct 2002 20:15:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnjwj09081 for ; Wed, 9 Oct 2002 20:15:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA02275 for ; Wed, 9 Oct 2002 16:15:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g99KF1X05226 for mpls@uu.net; Wed, 9 Oct 2002 16:15:01 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnjwi13326 for ; Wed, 9 Oct 2002 20:13:29 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnjwi02421 for ; Wed, 9 Oct 2002 20:12:08 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjwi07013 for ; Wed, 9 Oct 2002 20:12:08 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: europe.cisco.com [144.254.52.73]) id QQnjwi07009 for ; Wed, 9 Oct 2002 20:12:07 GMT Received: from JVASSEUR-W2K.cisco.com (ams-clip-vpn-dhcp54.cisco.com [10.50.0.53]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id WAA28496; Wed, 9 Oct 2002 22:12:04 +0200 (MET DST) Message-Id: <4.3.2.7.2.20021009161117.044ae2c0@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Oct 2002 16:12:01 -0400 To: "Hitesh Kulkarni" From: Jean Philippe Vasseur Subject: Re: what's the status of draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt Cc: mpls@UU.NET In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, We're currently working on the rev-01 which will be posted for IETF-55. JP. At 13:03 09/10/2002 -0700, Hitesh Kulkarni wrote: >Expiry date says July 2002.. Has it gone through the last call already or >it has been discontinued ?? Thanks > > > >_________________________________________________________________ >Join the world's largest e-mail service with MSN Hotmail. >http://www.hotmail.com From owner-mpls@UU.NET Wed Oct 9 16:18:15 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03051 for ; Wed, 9 Oct 2002 16:18:15 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjwj14293 for ; Wed, 9 Oct 2002 20:20:19 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnjwj13203; Wed, 9 Oct 2002 20:19:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQnjwj13920 for mpls-outgoing; Wed, 9 Oct 2002 20:19:24 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnjwj13912 for ; Wed, 9 Oct 2002 20:19:06 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnjwj19552 for ; Wed, 9 Oct 2002 20:18:32 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjwj22080 for ; Wed, 9 Oct 2002 20:18:32 GMT Received: from pimout1-ext.prodigy.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pimout1-ext.prodigy.net [207.115.63.77]) id QQnjwj22070 for ; Wed, 9 Oct 2002 20:18:32 GMT Received: from cs.columbia.edu (adsl-64-175-244-154.dsl.sntc01.pacbell.net [64.175.244.154]) by pimout1-ext.prodigy.net (8.12.3 da nor stuldap/8.12.3) with ESMTP id g99KIPLE357968; Wed, 9 Oct 2002 16:18:26 -0400 Message-ID: <3DA48F11.1030708@cs.columbia.edu> Date: Wed, 09 Oct 2002 13:18:25 -0700 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hitesh Kulkarni CC: mpls@UU.NET Subject: Re: what's the status of draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt References: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit A new version is in the process to spin out. There is no big changes. Sorry! - Ping Hitesh Kulkarni wrote: > Expiry date says July 2002.. Has it gone through the last call already > or it has been discontinued ?? Thanks > > > > _________________________________________________________________ > Join the world’s largest e-mail service with MSN Hotmail. > http://www.hotmail.com > From owner-mpls@UU.NET Wed Oct 9 18:50:30 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06946 for ; Wed, 9 Oct 2002 18:50:30 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjwt27060 for ; Wed, 9 Oct 2002 22:52:31 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnjwt26046; Wed, 9 Oct 2002 22:51:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQnjwt27818 for mpls-outgoing; Wed, 9 Oct 2002 22:51:40 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnjwt27813 for ; Wed, 9 Oct 2002 22:51:35 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnjwt27199 for ; Wed, 9 Oct 2002 22:51:01 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjwt27484 for ; Wed, 9 Oct 2002 22:51:00 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnjwt27480 for ; Wed, 9 Oct 2002 22:51:00 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA13088 for ; Wed, 9 Oct 2002 18:50:59 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g99MoxI13776 for mpls@uu.net; Wed, 9 Oct 2002 18:50:59 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnjwb02787 for ; Wed, 9 Oct 2002 18:28:30 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnjwb09866 for ; Wed, 9 Oct 2002 18:27:32 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjwb23663 for ; Wed, 9 Oct 2002 18:27:32 GMT Received: from web13105.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web13105.mail.yahoo.com [216.136.174.150]) id QQnjwb23639 for ; Wed, 9 Oct 2002 18:27:31 GMT Message-ID: <20021009182731.60431.qmail@web13105.mail.yahoo.com> Received: from [65.241.132.122] by web13105.mail.yahoo.com via HTTP; Wed, 09 Oct 2002 11:27:31 PDT Date: Wed, 9 Oct 2002 11:27:31 -0700 (PDT) From: Gopalkrishna Panicker Subject: LSP Preemption To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, As a part of path admission control a router upon receipt of a path message decides if it has sufficient resources to accommodate this session. This decision may involve bumping other low priority sessions. >From reading the archives I gather this bumping is actually done when the corresponding Resv message arrives. I assume this is when the appropriate PathErr/ResvErr is sent. My question is, in a intermediate or transit router do we delete the old reservation (of the bumped lsp) at the time we send the error message. How does one recover should this error message be lost ? Another related question, are reservations torn down when we recv a Resv Err/Path error message or should we wait for the path/resv tear to do this. RFC 2209 suggests the later. Cheers, Gopal __________________________________________________ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com From owner-mpls@UU.NET Thu Oct 10 07:21:25 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28611 for ; Thu, 10 Oct 2002 07:21:25 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjyr11884 for ; Thu, 10 Oct 2002 11:23:30 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnjyr11080; Thu, 10 Oct 2002 11:23:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQnjyr10527 for mpls-outgoing; Thu, 10 Oct 2002 11:22:41 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnjyr10521 for ; Thu, 10 Oct 2002 11:22:33 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnjyr17506 for ; Thu, 10 Oct 2002 11:22:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjyr09842 for ; Thu, 10 Oct 2002 11:22:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnjyr09830 for ; Thu, 10 Oct 2002 11:22:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA15826 for ; Thu, 10 Oct 2002 07:22:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9ABM2G17243 for mpls@uu.net; Thu, 10 Oct 2002 07:22:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnjyr10492 for ; Thu, 10 Oct 2002 11:21:09 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnjyr06188 for ; Thu, 10 Oct 2002 11:20:17 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjyr08813 for ; Thu, 10 Oct 2002 11:20:16 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQnjyr08809 for ; Thu, 10 Oct 2002 11:20:16 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28483; Thu, 10 Oct 2002 07:18:09 -0400 (EDT) Message-Id: <200210101118.HAA28483@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-lsp-ping-01.txt Date: Thu, 10 Oct 2002 07:18:09 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Detecting MPLS Data Plane Liveness Author(s) : K. Kompella et al. Filename : draft-ietf-mpls-lsp-ping-01.txt Pages : 22 Date : 2002-10-9 This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS 'echo request' and 'echo reply' for the purposes of fault detection and isolation; and mechanisms for reliably sending the echo reply. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-lsp-ping-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-lsp-ping-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: <2002-10-9145104.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lsp-ping-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lsp-ping-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-9145104.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Oct 10 11:13:57 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07320 for ; Thu, 10 Oct 2002 11:13:57 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjzh20113 for ; Thu, 10 Oct 2002 15:16:02 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnjzh19254; Thu, 10 Oct 2002 15:15:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQnjzh01957 for mpls-outgoing; Thu, 10 Oct 2002 15:15:17 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnjzh01952 for ; Thu, 10 Oct 2002 15:15:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnjzg00024 for ; Thu, 10 Oct 2002 15:14:44 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnjzg18228 for ; Thu, 10 Oct 2002 15:14:44 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQnjzg18218 for ; Thu, 10 Oct 2002 15:14:44 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA18385 for ; Thu, 10 Oct 2002 11:14:40 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA22654 for ; Thu, 10 Oct 2002 11:14:27 -0400 (EDT) Message-ID: <3DA5994A.7020207@marconi.com> Date: Thu, 10 Oct 2002 11:14:18 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: IETF MPLS List Subject: Re: LSP Preemption References: <20021009182731.60431.qmail@web13105.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Gopalkrishna Panicker wrote: > > As a part of path admission control a router upon > receipt of a path message decides if it has > sufficient resources to accommodate this session. > This decision may involve bumping other low priority > sessions. This should only be done during Path processing if the Path processing is going to allocate resources for the connection. Otherwise, you may block legitimate traffic. There is noting in any RSVP spec which requires the size of the reservation in the Resv's FLOWSPEC to match the size requested in the Path's TSPEC. The FLOWSPEC may be smaller than requested. And in the case of multicast or multiple LSPs sharing resources with SE style, various merging rules may make the actual reservation larger or smaller than requested. Furthermore, there's a time delay between receiving Path and Resv messages. Your local state (including resource availability) can change during that time. > From reading the archives I gather this bumping is > actually done when the corresponding Resv message > arrives. I assume this is when the appropriate > PathErr/ResvErr is sent. That would be correct. You do admission control when you actually try to create your forwarding-plane connections, and not before. If your implementation creates its connections during Path processing, then you do admission control during Path processing. If you create your connections during Resv processing, then you do your admission control during Resv processing. > My question is, in a intermediate or transit router > do we delete the old reservation (of the bumped lsp) > at the time we send the error message. How does one > recover should this error message be lost ? The RFC is very clear about this. When a connection is preempted, you tear down its resources (the definition of preemption). PathErr and ResvErr messages should be sent. If this results in tearing Resv state (which is almost certainly will), then you should also send out a ResvTear. If it results in tearing Path state (which I don't think is reasonable, but is a possibility), then you should send out a PathTear as well. The reasons are simple. The PathErr and ResvErr inform the edge routers that the connection has been preempted. This will let them choose a different size reservation or choose a different route to run the LSP through. The ResvTear is sent out to inform the upstream nodes that the reservation is no longer present. There's no point to them reserving resources if the traffic will get dropped further downstream anyway. Additionally, that Resv state will time out anyway, since a node won't ever refresh deleted state. The tear message speeds up the inevitable here. Similar for the PathTear. If your Path state is no longer present, then the downstream nodes will stop receiving their refreshes. The state will time out eventually. The PathTear message speeds up the process so they don't waste resources on useless state. > Another related question, are reservations torn down > when we recv a Resv Err/Path error message or should > we wait for the path/resv tear to do this. RFC 2209 > suggests the later. Error messages should never cause state to be torn. They serve only to inform the edges of an error condition. It is up to the edge to decide what to do about the error (which may well be to tear the LSP and try to reestablish with different parameters.) The only real exception here is an admission control ResvErr in a multicast scenario. In that case, the FLOWSPEC in an outbound Resv message may be produced from the FLOWSPECs of several inbound Resv messages - a ResvErr indicating admission control in this case is handled by blockading the largest reservations and re-merging the remaining ones, according to the (rather complex) rules of RFC 2205 and 2209. But this is really not applicable to RSVP-TE, since admission control causes PathErr generation instead of ResvErr. (See section 4.7.3 of RFC 3209) -- David From owner-mpls@UU.NET Thu Oct 10 17:02:40 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24143 for ; Thu, 10 Oct 2002 17:02:40 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkae07618 for ; Thu, 10 Oct 2002 21:04:35 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkae06756; Thu, 10 Oct 2002 21:04:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkae27706 for mpls-outgoing; Thu, 10 Oct 2002 21:03:49 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnkae27459 for ; Thu, 10 Oct 2002 21:03:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkae28071 for ; Thu, 10 Oct 2002 21:03:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkae26672 for ; Thu, 10 Oct 2002 21:03:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnkae26651 for ; Thu, 10 Oct 2002 21:03:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA01336 for ; Thu, 10 Oct 2002 17:03:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9AL31621796 for mpls@uu.net; Thu, 10 Oct 2002 17:03:01 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnkae23615 for ; Thu, 10 Oct 2002 21:01:52 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnkae04923 for ; Thu, 10 Oct 2002 21:01:09 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkae03734 for ; Thu, 10 Oct 2002 21:01:08 GMT Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQnkae03719 for ; Thu, 10 Oct 2002 21:01:07 GMT Received: (qmail 2294 invoked by uid 104); 10 Oct 2002 21:01:07 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4228. . Clean. Processed in 1.23584 secs); 10 Oct 2002 21:01:07 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 10 Oct 2002 21:01:05 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g9AL0sQ28355; Thu, 10 Oct 2002 14:01:00 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Thu, 10 Oct 2002 14:00:54 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB039C5@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Ping Pan'" , Hitesh Kulkarni Cc: mpls@UU.NET Subject: RE: what's the status of draft-ietf-mpls-rsvp-lsp-fastreroute-00. txt Date: Thu, 10 Oct 2002 14:00:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="windows-1252" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA24143 Ping, Have you considered removing the path-specific method from this draft? A number of people expressed their concern regarding the path-specific method, and did not get any satisfactory response from you. Also I gave a number of other comments that you seemed to agree with some of them. have you corrected those items too? Thanks, -Shahram > -----Original Message----- > From: Ping Pan [mailto:pingpan@cs.columbia.edu] > Sent: Wednesday, October 09, 2002 4:18 PM > To: Hitesh Kulkarni > Cc: mpls@UU.NET > Subject: Re: what's the status of > draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt > > > A new version is in the process to spin out. There is no big changes. > > Sorry! > > - Ping > > Hitesh Kulkarni wrote: > > Expiry date says July 2002.. Has it gone through the last > call already > > or it has been discontinued ?? Thanks > > > > > > > > _________________________________________________________________ > > Join the world’s largest e-mail service with MSN Hotmail. > > http://www.hotmail.com > > > > From owner-mpls@UU.NET Thu Oct 10 17:11:44 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24317 for ; Thu, 10 Oct 2002 17:11:44 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkae08649 for ; Thu, 10 Oct 2002 21:13:49 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkae07628; Thu, 10 Oct 2002 21:13:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkae06312 for mpls-outgoing; Thu, 10 Oct 2002 21:12:54 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnkae06286 for ; Thu, 10 Oct 2002 21:12:48 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnkae15575 for ; Thu, 10 Oct 2002 21:11:33 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkae25971 for ; Thu, 10 Oct 2002 21:11:33 GMT Received: from sbcsmtp2.sbc.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sbcsmtp2.sbc.com [209.184.203.4]) id QQnkae25779 for ; Thu, 10 Oct 2002 21:11:22 GMT Received: from sbc.com (localhost [127.0.0.1]) by sbcsmtp2.sbc.com (8.12.5/8.12.5) with ESMTP id g9AL4eSe010221; Thu, 10 Oct 2002 16:04:41 -0500 (CDT) Received: from msgdalhub02.ITServices.sbc.com (msgdalhub02.sbc.com [155.179.128.121]) by sbcsmtp2.sbc.com (8.12.5/8.12.5) with ESMTP id g9AL4OZr010103; Thu, 10 Oct 2002 16:04:37 -0500 (CDT) Received: by msgdalhub02.ITServices.sbc.com with Internet Mail Service (5.5.2655.15) id ; Thu, 10 Oct 2002 16:09:29 -0500 Message-ID: <65A06DE70C4E3544AB006E2CCD4BA8530552365C@txsna09msgusr01.ITServices.sbc.com> From: "VILLARREAL, STEVE (SBC-MSI)" To: Shahram Davari , "'Ping Pan'" , Hitesh Kulkarni Cc: mpls@UU.NET Subject: RE: what's the status of draft-ietf-mpls-rsvp-lsp-fastreroute-00. txt Date: Thu, 10 Oct 2002 16:09:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.15) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Is there someone who can give a good comparison between PNNI and MPLS ? From owner-mpls@UU.NET Thu Oct 10 17:39:11 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24953 for ; Thu, 10 Oct 2002 17:39:11 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkag07972 for ; Thu, 10 Oct 2002 21:41:15 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkag06511; Thu, 10 Oct 2002 21:40:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkag09566 for mpls-outgoing; Thu, 10 Oct 2002 21:39:50 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnkag09559 for ; Thu, 10 Oct 2002 21:39:42 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkag16429 for ; Thu, 10 Oct 2002 21:39:25 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkag05378 for ; Thu, 10 Oct 2002 21:39:25 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnkag05360 for ; Thu, 10 Oct 2002 21:39:25 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA03876 for ; Thu, 10 Oct 2002 17:39:24 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9ALdO725309 for mpls@uu.net; Thu, 10 Oct 2002 17:39:24 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnkag09542 for ; Thu, 10 Oct 2002 21:38:43 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnkag14031 for ; Thu, 10 Oct 2002 21:38:35 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkag11284 for ; Thu, 10 Oct 2002 21:38:35 GMT Received: from c2.ciena.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.118.32.25]) id QQnkag11279 for ; Thu, 10 Oct 2002 21:38:35 GMT Received: by c2.ciena.com (8.8.8+Sun/SMI-SVR4-8.0) id RAA24354; Thu, 10 Oct 2002 17:38:34 -0400 (EDT) Received: from wntcsdexg01.csd.ciena.com(10.128.2.158) by c2.ciena.com via smap (V2.0) id xma024309; Thu, 10 Oct 02 17:38:19 -0400 Received: by wntcsdexg01.csd.ciena.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Oct 2002 14:38:17 -0700 Received: from ciena.com (ppan [10.128.20.74]) by wntcsdexg02.csd.ciena.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PF7Z5KLP; Thu, 10 Oct 2002 14:38:10 -0700 From: "Pan, Ping" To: Shahram Davari Cc: Hitesh Kulkarni , mpls@UU.NET Message-ID: <3DA5F335.6060209@ciena.com> Date: Thu, 10 Oct 2002 14:37:57 -0700 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: what's the status of draft-ietf-mpls-rsvp-lsp-fastreroute-00. txt References: <4B6D09F3B826D411A67300D0B706EFDEB039C5@nt-exch-yow.pmc-sierra.bc.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Shahram, I have included some of your concerns in the new version, which will come out soon. As for the path-specific method, we cannot take it out for a simple reason, that is, it is how Juniper had implemented and deployed. For an LSP, SESSION and SENDER_TEMPLATE objects will be identical for both working and detour LSPs. But all the detours will have a DETOUR object. You use the merging rules to figure out what to. The advantage for such method is state aggregation, compare with sender-specific. The pain is the merging rules. Thanks! - Ping Shahram Davari wrote: > Ping, > > Have you considered removing the path-specific method from this draft? A number of people expressed their concern regarding the path-specific method, and did not get any satisfactory response from you. Also I gave a number of other comments that you seemed to agree with some of them. have you corrected those items too? > > Thanks, > -Shahram > > > > >>-----Original Message----- >>From: Ping Pan [mailto:pingpan@cs.columbia.edu] >>Sent: Wednesday, October 09, 2002 4:18 PM >>To: Hitesh Kulkarni >>Cc: mpls@UU.NET >>Subject: Re: what's the status of >>draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt >> >> >>A new version is in the process to spin out. There is no big changes. >> >>Sorry! >> >>- Ping >> >>Hitesh Kulkarni wrote: >> >>>Expiry date says July 2002.. Has it gone through the last >> >>call already >> >>>or it has been discontinued ?? Thanks >>> >>> >>> >>>_________________________________________________________________ >>>Join the world’s largest e-mail service with MSN Hotmail. >>>http://www.hotmail.com >>> >> >> From owner-mpls@UU.NET Thu Oct 10 17:52:39 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25373 for ; Thu, 10 Oct 2002 17:52:39 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkah25836 for ; Thu, 10 Oct 2002 21:54:40 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkah24548; Thu, 10 Oct 2002 21:53:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkah10957 for mpls-outgoing; Thu, 10 Oct 2002 21:53:30 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnkah10948 for ; Thu, 10 Oct 2002 21:53:14 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkah19041 for ; Thu, 10 Oct 2002 21:52:10 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkah22743 for ; Thu, 10 Oct 2002 21:52:10 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnkah22731 for ; Thu, 10 Oct 2002 21:52:09 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA04302 for ; Thu, 10 Oct 2002 17:45:24 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9ALjOG25838 for mpls@uu.net; Thu, 10 Oct 2002 17:45:24 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnkag09603 for ; Thu, 10 Oct 2002 21:40:57 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnkag14540 for ; Thu, 10 Oct 2002 21:40:54 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkag12928 for ; Thu, 10 Oct 2002 21:40:54 GMT Received: from c2.ciena.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.118.32.25]) id QQnkag12916 for ; Thu, 10 Oct 2002 21:40:54 GMT Received: by c2.ciena.com (8.8.8+Sun/SMI-SVR4-8.0) id RAA24829; Thu, 10 Oct 2002 17:40:53 -0400 (EDT) Received: from wntcsdexg01.csd.ciena.com(10.128.2.158) by c2.ciena.com via smap (V2.0) id xma024714; Thu, 10 Oct 02 17:40:31 -0400 Received: by wntcsdexg01.csd.ciena.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Oct 2002 14:40:29 -0700 Received: from ciena.com (ppan [10.128.20.74]) by wntcsdexg02.csd.ciena.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PF7Z5KLR; Thu, 10 Oct 2002 14:40:25 -0700 From: "Pan, Ping" To: "VILLARREAL, STEVE (SBC-MSI)" Cc: mpls@UU.NET Message-ID: <3DA5F3BC.3070905@ciena.com> Date: Thu, 10 Oct 2002 14:40:12 -0700 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: what's the status of draft-ietf-mpls-rsvp-lsp-fastreroute-00. txt References: <65A06DE70C4E3544AB006E2CCD4BA8530552365C@txsna09msgusr01.ITServices.sbc.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Please... find a church and argue there. As far as I am concerned, both are great as long as customers want them. VILLARREAL, STEVE (SBC-MSI) wrote: > Is there someone who can give a good comparison between PNNI and MPLS ? > From owner-mpls@UU.NET Thu Oct 10 18:11:17 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25652 for ; Thu, 10 Oct 2002 18:11:17 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkai20153 for ; Thu, 10 Oct 2002 22:13:15 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkai18661; Thu, 10 Oct 2002 22:12:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkai28994 for mpls-outgoing; Thu, 10 Oct 2002 22:11:52 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnkai28987 for ; Thu, 10 Oct 2002 22:11:39 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnkai12871 for ; Thu, 10 Oct 2002 22:10:07 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkai07757 for ; Thu, 10 Oct 2002 22:10:07 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnkai07750 for ; Thu, 10 Oct 2002 22:10:07 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA05757 for ; Thu, 10 Oct 2002 18:10:06 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9AMA6C29160 for mpls@uu.net; Thu, 10 Oct 2002 18:10:06 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnkai28044 for ; Thu, 10 Oct 2002 22:08:58 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkai00218 for ; Thu, 10 Oct 2002 22:07:51 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkai13658 for ; Thu, 10 Oct 2002 22:07:50 GMT Received: from father.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQnkai13640 for ; Thu, 10 Oct 2002 22:07:49 GMT Received: (qmail 12047 invoked by uid 104); 10 Oct 2002 22:07:48 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4228. . Clean. Processed in 0.475916 secs); 10 Oct 2002 22:07:48 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 10 Oct 2002 22:07:48 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g9AM7iQ20751; Thu, 10 Oct 2002 15:07:44 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Thu, 10 Oct 2002 15:07:44 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB039C6@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Pan, Ping'" Cc: Hitesh Kulkarni , mpls@UU.NET Subject: RE: what's the status of draft-ietf-mpls-rsvp-lsp-fastreroute-00. txt Date: Thu, 10 Oct 2002 15:07:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="windows-1252" Sender: owner-mpls@UU.NET Precedence: bulk Ping, > As for the path-specific method, we cannot take it out for a simple > reason, that is, it is how Juniper had implemented and > deployed. Although I have tried this a couple of times, but let me do it again: IETF is a standard organization. It is not a place to rubber stamp individual companies implementations, but rather a place to figure out the best solutions for the industry. There is always a risk of implementing a technology before it is standardized. If we go by your logic then every implementation in the field must be standardized ! Does that make sense? -Shahram From owner-mpls@UU.NET Thu Oct 10 18:20:33 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25730 for ; Thu, 10 Oct 2002 18:20:32 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkaj03788 for ; Thu, 10 Oct 2002 22:22:33 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkaj02391; Thu, 10 Oct 2002 22:21:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkaj00275 for mpls-outgoing; Thu, 10 Oct 2002 22:21:25 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnkaj00267 for ; Thu, 10 Oct 2002 22:21:22 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnkaj05419 for ; Thu, 10 Oct 2002 22:21:12 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkaj19702 for ; Thu, 10 Oct 2002 22:21:12 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnkaj19691 for ; Thu, 10 Oct 2002 22:21:11 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA06471 for ; Thu, 10 Oct 2002 18:21:11 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9AMLBs00904 for mpls@uu.net; Thu, 10 Oct 2002 18:21:11 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnkaj00021 for ; Thu, 10 Oct 2002 22:20:28 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnkaj12280 for ; Thu, 10 Oct 2002 22:19:53 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkaj18143 for ; Thu, 10 Oct 2002 22:19:52 GMT Received: from c2.ciena.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.118.32.25]) id QQnkaj18106 for ; Thu, 10 Oct 2002 22:19:52 GMT Received: by c2.ciena.com (8.8.8+Sun/SMI-SVR4-8.0) id SAA07144; Thu, 10 Oct 2002 18:19:51 -0400 (EDT) Received: from wntcsdexg02.csd.ciena.com(10.128.2.168) by c2.ciena.com via smap (V2.0) id xma007017; Thu, 10 Oct 02 18:19:20 -0400 Received: by wntcsdexg02.csd.ciena.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Oct 2002 15:19:18 -0700 Message-ID: <2135200C183FD5119588009027DE572302061E3F@wntcsdexg02.csd.ciena.com> From: "Pan, Ping" To: "'Shahram Davari'" Cc: Hitesh Kulkarni , mpls@UU.NET Subject: RE: what's the status of draft-ietf-mpls-rsvp-lsp-fastreroute-00. txt Date: Thu, 10 Oct 2002 15:19:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1252" Sender: owner-mpls@UU.NET Precedence: bulk > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Thursday, October 10, 2002 3:08 PM > To: Pan, Ping > Cc: Hitesh Kulkarni; mpls@UU.NET > Subject: RE: what's the status of > draft-ietf-mpls-rsvp-lsp-fastreroute-00. txt > > > There is always a risk of implementing a technology before it > is standardized. > If we go by your logic then every implementation in the field > must be standardized ! > If customers are buying and deploying, YES! From owner-mpls@UU.NET Fri Oct 11 02:34:18 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12627 for ; Fri, 11 Oct 2002 02:34:17 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkbq16194 for ; Fri, 11 Oct 2002 06:36:22 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkbq15525; Fri, 11 Oct 2002 06:36:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkbq17029 for mpls-outgoing; Fri, 11 Oct 2002 06:35:35 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnkbq17024 for ; Fri, 11 Oct 2002 06:35:29 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkbq07136 for ; Fri, 11 Oct 2002 06:34:47 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkbq14335 for ; Fri, 11 Oct 2002 06:34:47 GMT Received: from mtiwmhc11.worldnet.att.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mtiwmhc11.worldnet.att.net [204.127.131.115]) id QQnkbq14329 for ; Fri, 11 Oct 2002 06:34:46 GMT Received: from 6640bbc3r131 ([12.81.2.62]) by mtiwmhc11.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with SMTP id <20021011062932.YNTJ20527.mtiwmhc11.worldnet.att.net@6640bbc3r131>; Fri, 11 Oct 2002 06:29:32 +0000 Message-ID: <001301c270ef$ad4a0840$3e02510c@6640bbc3r131> From: "Brijesh Kumar" To: "Pan, Ping" , "'Shahram Davari'" Cc: "Hitesh Kulkarni" , References: <2135200C183FD5119588009027DE572302061E3F@wntcsdexg02.csd.ciena.com> Subject: Re: what's the status of draft-ietf-mpls-rsvp-lsp-fastreroute-00. txt Date: Thu, 10 Oct 2002 23:30:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Pan, Ping" To: "'Shahram Davari'" > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > > There is always a risk of implementing a technology before it > > is standardized. > > If we go by your logic then every implementation in the field > > must be standardized ! > > > If customers are buying and deploying, YES! Ping, I think it is an emotional response not a logical one. It is somewhat out of the context, but if IEEE 802.11 WLAN standardization group was to go by this logic, they would have ended blessing over 30 different proprietary standards developed by various companies over the last decade for wireless LANs. Shahram does have a very valid point here. cheers, --brijesh From owner-mpls@UU.NET Fri Oct 11 05:46:46 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15120 for ; Fri, 11 Oct 2002 05:46:46 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkcd07285 for ; Fri, 11 Oct 2002 09:48:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkcd06279; Fri, 11 Oct 2002 09:48:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkcd20036 for mpls-outgoing; Fri, 11 Oct 2002 09:48:07 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnkcd20031 for ; Fri, 11 Oct 2002 09:48:05 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnkcd18259 for ; Fri, 11 Oct 2002 09:45:34 GMT From: neil.2.harrison@bt.com Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkcd12611 for ; Fri, 11 Oct 2002 09:45:33 GMT Received: from cbibipnt08.hc.bt.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQnkcd12597 for ; Fri, 11 Oct 2002 09:45:33 GMT Received: by cbibipnt08.hc.bt.com with Internet Mail Service (5.5.2654.89) id <44MGXP7B>; Fri, 11 Oct 2002 10:45:05 +0100 Message-ID: To: brijesh.kumar@att.net, ppan@ciena.com, Shahram_Davari@pmc-sierra.com Cc: hkulk@hotmail.com, mpls@UU.NET Subject: RE: what's the status of draft-ietf-mpls-rsvp-lsp-fastreroute-00. txt Date: Fri, 11 Oct 2002 10:44:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="windows-1252" Sender: owner-mpls@UU.NET Precedence: bulk Brijesh Kumar11 wrote October 2002 07:30 > ----- Original Message ----- > From: "Pan, Ping" > To: "'Shahram Davari'" > > > > -----Original Message----- > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > > > > There is always a risk of implementing a technology before it > > > is standardized. > > > If we go by your logic then every implementation in the field > > > must be standardized ! > > > > > If customers are buying and deploying, YES! > > Ping, > > I think it is an emotional response not a logical one. > > It is somewhat out of the context, but if IEEE 802.11 WLAN > standardization > group was to go by this logic, they would have ended blessing over 30 > different proprietary standards developed by various > companies over the last > decade for wireless LANs. Shahram does have a very valid point here. > > cheers, > > --brijesh NH=> Absolutely right Brijesh. The consequences of what Ping is suggesting (while I can understand the simplistic logic here) is quite scary. It means the role of all stds bodies (sic) is now a simply a retrospective rubber-stamping job for the dominant mode based on 'what wins'....so what is the point of submitting any IDs for new ideas?....indeed the stds bodies might as well cease to exist. This model may be OK for some industries/products where interworking is not required and/or where product life-cycles are short, but it does not fit what we need in our industry. Further, I don't want to see innovation stifled by the dominant market players. There simply has to be up-front thinking/debate/agreement on solutions well in advance of large-scale deployment....else chaos.....maybe this (at least partially) explains the mess we see around us today? regards, Neil > From owner-mpls@UU.NET Fri Oct 11 07:33:41 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17055 for ; Fri, 11 Oct 2002 07:33:41 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkck16619 for ; Fri, 11 Oct 2002 11:35:37 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkck08272; Fri, 11 Oct 2002 11:32:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkck00171 for mpls-outgoing; Fri, 11 Oct 2002 11:31:47 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnkck00166 for ; Fri, 11 Oct 2002 11:31:33 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnkck20600 for ; Fri, 11 Oct 2002 11:31:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkck07395 for ; Fri, 11 Oct 2002 11:31:02 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnkck07382 for ; Fri, 11 Oct 2002 11:31:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA11181 for ; Fri, 11 Oct 2002 07:31:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9BBV1i10784 for mpls@uu.net; Fri, 11 Oct 2002 07:31:01 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnkcj29936 for ; Fri, 11 Oct 2002 11:29:48 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkcj17473 for ; Fri, 11 Oct 2002 11:29:11 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkcj26018 for ; Fri, 11 Oct 2002 11:29:11 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQnkcj26008 for ; Fri, 11 Oct 2002 11:29:11 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16581; Fri, 11 Oct 2002 07:27:04 -0400 (EDT) Message-Id: <200210111127.HAA16581@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; CC: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-kishan-lsp-btrace-04.txt Date: Fri, 11 Oct 2002 07:27:03 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Backtrace Messages for Label Switched Paths Author(s) : H. Desineni, K. Avasarala Filename : draft-kishan-lsp-btrace-04.txt Pages : 19 Date : 2002-10-10 Label switched path (LSP) backtrace is a method to backtrack the paths followed by packets in a particular multi protocol label switching (MPLS) forwarding equivalence class (FEC). This document describes encoding and procedures for new label distribution protocol (LDP) messages, backtrace message and backtrace reply message used for performing LSP backtrace. Backtrace message is sent upstream for an established LSP. Backtrace message can be used for LDP LSPs as well as for constraint based label switched paths (CR-LSPs). Data requested through backtrace message is encoded into backtrace reply message. Backtrace reply message is sent in downstream direction. It always travels towards the tail end of an LSP. Backtrace mechanism described in this document can also be used for obtaining additional attributes of LSPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kishan-lsp-btrace-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-kishan-lsp-btrace-04.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-kishan-lsp-btrace-04.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: <2002-10-10140626.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kishan-lsp-btrace-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-kishan-lsp-btrace-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-10140626.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Oct 11 09:11:46 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20322 for ; Fri, 11 Oct 2002 09:11:45 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkcq07392 for ; Fri, 11 Oct 2002 13:13:45 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkcq06451; Fri, 11 Oct 2002 13:13:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkcq10611 for mpls-outgoing; Fri, 11 Oct 2002 13:12:43 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnkcq10606 for ; Fri, 11 Oct 2002 13:12:30 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkcq09370 for ; Fri, 11 Oct 2002 13:12:04 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkcq04897 for ; Fri, 11 Oct 2002 13:12:04 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnkcq04887 for ; Fri, 11 Oct 2002 13:12:04 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA22031 for ; Fri, 11 Oct 2002 09:12:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9BDC3a15983 for mpls@uu.net; Fri, 11 Oct 2002 09:12:03 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnkcq10385 for ; Fri, 11 Oct 2002 13:11:23 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkcq16649 for ; Fri, 11 Oct 2002 13:10:42 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkcq03341 for ; Fri, 11 Oct 2002 13:10:42 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnkcq03334 for ; Fri, 11 Oct 2002 13:10:41 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9BDAjEN028477; Fri, 11 Oct 2002 09:10:46 -0400 (EDT) Received: from tnadeau-w2k.cisco.com (che-vpn2-84.cisco.com [10.86.244.84]) by bucket.cisco.com (Mirapoint) with ESMTP id ABY01992; Fri, 11 Oct 2002 09:10:30 -0400 (EDT) Message-Id: <4.3.2.7.2.20021011085907.01e6a6d0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 11 Oct 2002 09:10:29 -0400 To: Shahram Davari From: "Thomas D. Nadeau" Subject: RE: what's the status of draft-ietf-mpls-rsvp-lsp-fastreroute-00. txt Cc: mpls@UU.NET In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB039C6@nt-exch-yow.pmc-sie rra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk > > As for the path-specific method, we cannot take it out for a simple > > reason, that is, it is how Juniper had implemented and > > deployed. > >Although I have tried this a couple of times, but let me do it again: > >IETF is a standard organization. It is not a place to rubber stamp >individual companies implementations, but rather a place to figure out >the best solutions for the industry. > >There is always a risk of implementing a technology before it is standardized. >If we go by your logic then every implementation in the field must be >standardized ! > >Does that make sense? Sharam, At the risk of repeating myself and others on the topic, remember the IETF mantra: working code and rough consensus. This is to a large part why the Internet works today and is still not a research project. --Tom Success is relative; the more success, the more relatives. -Anonymous From owner-mpls@UU.NET Fri Oct 11 10:26:53 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23043 for ; Fri, 11 Oct 2002 10:26:53 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkcv28440 for ; Fri, 11 Oct 2002 14:28:52 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkcv27241; Fri, 11 Oct 2002 14:28:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkcv02533 for mpls-outgoing; Fri, 11 Oct 2002 14:27:51 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnkcv02528 for ; Fri, 11 Oct 2002 14:27:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnkcv19856 for ; Fri, 11 Oct 2002 14:26:22 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkcv24177 for ; Fri, 11 Oct 2002 14:26:22 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnkcv24117 for ; Fri, 11 Oct 2002 14:26:17 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA26347 for ; Fri, 11 Oct 2002 10:14:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9BEE2u20368 for mpls@uu.net; Fri, 11 Oct 2002 10:14:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnkcu01486 for ; Fri, 11 Oct 2002 14:13:00 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnkcu13558 for ; Fri, 11 Oct 2002 14:10:54 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkcu16768 for ; Fri, 11 Oct 2002 14:10:53 GMT Received: from mother.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQnkcu16757 for ; Fri, 11 Oct 2002 14:10:52 GMT Received: (qmail 2504 invoked by uid 104); 11 Oct 2002 14:09:58 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4228. . Clean. Processed in 0.493736 secs); 11 Oct 2002 14:09:58 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 11 Oct 2002 14:09:57 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g9BE9vQ27164; Fri, 11 Oct 2002 07:09:57 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Fri, 11 Oct 2002 07:09:57 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB039C7@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Thomas D. Nadeau'" Cc: mpls@UU.NET Subject: RE: what's the status of draft-ietf-mpls-rsvp-lsp-fastreroute-00. txt Date: Fri, 11 Oct 2002 07:09:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Unfortunately I did not see any consensus? and in fact I saw many objections. Therefore since no consensus exits for path-specific method, it has to be taken out of the draft. -Shahram > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Friday, October 11, 2002 9:10 AM > To: Shahram Davari > Cc: mpls@UU.NET > Subject: RE: what's the status of > draft-ietf-mpls-rsvp-lsp-fastreroute-00. txt > > > > > > As for the path-specific method, we cannot take it out > for a simple > > > reason, that is, it is how Juniper had implemented and > > > deployed. > > > >Although I have tried this a couple of times, but let me do it again: > > > >IETF is a standard organization. It is not a place to rubber stamp > >individual companies implementations, but rather a place to > figure out > >the best solutions for the industry. > > > >There is always a risk of implementing a technology before > it is standardized. > >If we go by your logic then every implementation in the > field must be > >standardized ! > > > >Does that make sense? > > Sharam, > > At the risk of repeating myself and others on the > topic, remember the > IETF mantra: working code and rough consensus. This is to a > large part > why the Internet works today and is still not a research project. > > --Tom > > > Success is relative; the more success, the more relatives. -Anonymous > From owner-mpls@UU.NET Fri Oct 11 10:37:48 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23645 for ; Fri, 11 Oct 2002 10:37:48 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkcw13631 for ; Fri, 11 Oct 2002 14:39:53 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkcw12468; Fri, 11 Oct 2002 14:39:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkcw03364 for mpls-outgoing; Fri, 11 Oct 2002 14:38:59 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnkcw03359 for ; Fri, 11 Oct 2002 14:38:53 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnkcw02858 for ; Fri, 11 Oct 2002 14:38:19 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkcw11419 for ; Fri, 11 Oct 2002 14:38:19 GMT Received: from mlsrv1.avici.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host128.avici.com [208.246.215.128] (may be forged)) id QQnkcw11413 for ; Fri, 11 Oct 2002 14:38:19 GMT Received: from aatlas-lt.avici.com (b2-pc53.avici.com [10.2.100.73]) by mlsrv1.avici.com (8.11.0/8.11.0) with ESMTP id g9BEbiV14465; Fri, 11 Oct 2002 10:37:44 -0400 (EDT) Message-Id: <5.1.0.14.2.20021011103645.01f535c8@mailhost.avici.com> X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 11 Oct 2002 10:38:28 -0400 To: Shahram Davari From: Alia Atlas Subject: RE: what's the status of draft-ietf-mpls-rsvp-lsp-fastreroute-00. txt Cc: "'Thomas D. Nadeau'" , mpls@UU.NET In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB039C7@nt-exch-yow.pmc-sie rra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk What about making the method an informational part of the draft, with the sender-template-specific method a SHOULD? In that way, the information about what was been done in the past will be preserved and inter-operable implementations can be made, but only as long as the interoperability with the path-specific method matters to someone. Alia At 07:09 AM 10/11/2002 -0700, Shahram Davari wrote: >Unfortunately I did not see any consensus? and in fact I saw many >objections. Therefore since no consensus exits for path-specific method, >it has to be taken out of the draft. > >-Shahram > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: Friday, October 11, 2002 9:10 AM > > To: Shahram Davari > > Cc: mpls@UU.NET > > Subject: RE: what's the status of > > draft-ietf-mpls-rsvp-lsp-fastreroute-00. txt > > > > > > > > > > As for the path-specific method, we cannot take it out > > for a simple > > > > reason, that is, it is how Juniper had implemented and > > > > deployed. > > > > > >Although I have tried this a couple of times, but let me do it again: > > > > > >IETF is a standard organization. It is not a place to rubber stamp > > >individual companies implementations, but rather a place to > > figure out > > >the best solutions for the industry. > > > > > >There is always a risk of implementing a technology before > > it is standardized. > > >If we go by your logic then every implementation in the > > field must be > > >standardized ! > > > > > >Does that make sense? > > > > Sharam, > > > > At the risk of repeating myself and others on the > > topic, remember the > > IETF mantra: working code and rough consensus. This is to a > > large part > > why the Internet works today and is still not a research project. > > > > --Tom > > > > > > Success is relative; the more success, the more relatives. -Anonymous > > From owner-mpls@UU.NET Fri Oct 11 13:28:36 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29471 for ; Fri, 11 Oct 2002 13:28:34 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkdi21869 for ; Fri, 11 Oct 2002 17:30:31 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkdh20383; Fri, 11 Oct 2002 17:29:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkdh05538 for mpls-outgoing; Fri, 11 Oct 2002 17:29:14 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnkdh05530 for ; Fri, 11 Oct 2002 17:29:06 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnkdh11462 for ; Fri, 11 Oct 2002 17:27:21 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkdh02618 for ; Fri, 11 Oct 2002 17:27:20 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnkdh02588 for ; Fri, 11 Oct 2002 17:27:19 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA12102 for ; Fri, 11 Oct 2002 13:27:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9BHR2a01622 for mpls@uu.net; Fri, 11 Oct 2002 13:27:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnkdh05284 for ; Fri, 11 Oct 2002 17:25:26 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkdh06778 for ; Fri, 11 Oct 2002 17:24:37 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkdh05417 for ; Fri, 11 Oct 2002 17:24:36 GMT Received: from father.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQnkdh05333 for ; Fri, 11 Oct 2002 17:24:34 GMT Received: (qmail 16243 invoked by uid 104); 11 Oct 2002 17:17:52 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4228. . Clean. Processed in 0.498533 secs); 11 Oct 2002 17:17:52 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 11 Oct 2002 17:17:51 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g9BHHgQ00062; Fri, 11 Oct 2002 10:17:43 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Fri, 11 Oct 2002 10:17:42 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB039CC@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Alia Atlas'" Cc: mpls@UU.NET Subject: RE: what's the status of draft-ietf-mpls-rsvp-lsp-fastreroute-00. txt Date: Fri, 11 Oct 2002 10:17:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Alia, I don't think it is possible (or even a good idea) to incorporate a method that has known problems in a standard RFC. However, it can be put in another informational or experimental RFC. -Shahram > -----Original Message----- > From: Alia Atlas [mailto:aatlas@avici.com] > Sent: Friday, October 11, 2002 10:38 AM > To: Shahram Davari > Cc: 'Thomas D. Nadeau'; mpls@UU.NET > Subject: RE: what's the status of > draft-ietf-mpls-rsvp-lsp-fastreroute-00. txt > > > What about making the method an informational part of the > draft, with the > sender-template-specific method a SHOULD? In that way, the > information > about what was been done in the past will be preserved and > inter-operable > implementations can be made, but only as long as the > interoperability with > the path-specific method matters to someone. > > Alia > > At 07:09 AM 10/11/2002 -0700, Shahram Davari wrote: > >Unfortunately I did not see any consensus? and in fact I saw many > >objections. Therefore since no consensus exits for > path-specific method, > >it has to be taken out of the draft. > > > >-Shahram > > > > > -----Original Message----- > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > Sent: Friday, October 11, 2002 9:10 AM > > > To: Shahram Davari > > > Cc: mpls@UU.NET > > > Subject: RE: what's the status of > > > draft-ietf-mpls-rsvp-lsp-fastreroute-00. txt > > > > > > > > > > > > > > As for the path-specific method, we cannot take it out > > > for a simple > > > > > reason, that is, it is how Juniper had implemented and > > > > > deployed. > > > > > > > >Although I have tried this a couple of times, but let me > do it again: > > > > > > > >IETF is a standard organization. It is not a place to > rubber stamp > > > >individual companies implementations, but rather a place to > > > figure out > > > >the best solutions for the industry. > > > > > > > >There is always a risk of implementing a technology before > > > it is standardized. > > > >If we go by your logic then every implementation in the > > > field must be > > > >standardized ! > > > > > > > >Does that make sense? > > > > > > Sharam, > > > > > > At the risk of repeating myself and others on the > > > topic, remember the > > > IETF mantra: working code and rough consensus. This is to a > > > large part > > > why the Internet works today and is still not a research project. > > > > > > --Tom > > > > > > > > > Success is relative; the more success, the more > relatives. -Anonymous > > > > > From owner-mpls@UU.NET Fri Oct 11 18:00:55 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05930 for ; Fri, 11 Oct 2002 18:00:55 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkdj04669; Fri, 11 Oct 2002 17:58:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkdj07799 for mpls-outgoing; Fri, 11 Oct 2002 17:57:59 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnkdj07792 for ; Fri, 11 Oct 2002 17:57:55 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnkdj23735 for ; Fri, 11 Oct 2002 17:57:29 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkdj17761 for ; Fri, 11 Oct 2002 17:57:28 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnkdj17738 for ; Fri, 11 Oct 2002 17:57:27 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA14990 for ; Fri, 11 Oct 2002 13:57:07 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9BHv7104399 for mpls@uu.net; Fri, 11 Oct 2002 13:57:07 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnkdj07546 for ; Fri, 11 Oct 2002 17:55:26 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnkdj11130 for ; Fri, 11 Oct 2002 17:54:59 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkdj13816 for ; Fri, 11 Oct 2002 17:54:59 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnkdj13750 for ; Fri, 11 Oct 2002 17:54:55 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9BHjQF4029890; Fri, 11 Oct 2002 13:45:27 -0400 (EDT) Received: from tnadeau-w2k.cisco.com (che-vpn2-84.cisco.com [10.86.244.84]) by bucket.cisco.com (Mirapoint) with ESMTP id ABY07415; Fri, 11 Oct 2002 13:45:17 -0400 (EDT) Message-Id: <4.3.2.7.2.20021011134241.04dd2dc0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 11 Oct 2002 13:45:17 -0400 To: "Brijesh Kumar" From: "Thomas D. Nadeau" Subject: Re: what's the status of draft-ietf-mpls-rsvp-lsp-fastreroute-00. txt Cc: In-Reply-To: <001c01c2714b$5966f240$e904510c@6640bbc3r131> References: <4B6D09F3B826D411A67300D0B706EFDEB039C7@nt-exch-yow.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk If you read it carefully, my statement was actually not voting in favor of one approach over another; rather, contesting Sharam's original statement that was down-playing the importance of working implementations within the context of IETF standards in exchange for architectural purity. --Tom >After following Shahram's mails on the issue, it doesn't look like that the >draft has a consensus. >The working code only comes after there is a consensus, not other way round. >Otherwise, it is not clear whose "working code" one is talking about. > >Cheers, > >--brijesh > >----- Original Message ----- >From: "Shahram Davari" >To: "'Thomas D. Nadeau'" >Cc: >Sent: Friday, October 11, 2002 7:09 AM >Subject: RE: what's the status of draft-ietf-mpls-rsvp-lsp-fastreroute-00. >txt > > > > Unfortunately I did not see any consensus? and in fact I saw many > > objections. Therefore since no consensus exits for path-specific method, > > it has to be taken out of the draft. > > > > -Shahram > > > > > -----Original Message----- > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > Sent: Friday, October 11, 2002 9:10 AM > > > To: Shahram Davari > > > Cc: mpls@UU.NET > > > Subject: RE: what's the status of > > > draft-ietf-mpls-rsvp-lsp-fastreroute-00. txt > > > > > > > > > > > > > > As for the path-specific method, we cannot take it out > > > for a simple > > > > > reason, that is, it is how Juniper had implemented and > > > > > deployed. > > > > > > > >Although I have tried this a couple of times, but let me do it again: > > > > > > > >IETF is a standard organization. It is not a place to rubber stamp > > > >individual companies implementations, but rather a place to > > > figure out > > > >the best solutions for the industry. > > > > > > > >There is always a risk of implementing a technology before > > > it is standardized. > > > >If we go by your logic then every implementation in the > > > field must be > > > >standardized ! > > > > > > > >Does that make sense? > > > > > > Sharam, > > > > > > At the risk of repeating myself and others on the > > > topic, remember the > > > IETF mantra: working code and rough consensus. This is to a > > > large part > > > why the Internet works today and is still not a research project. > > > > > --Tom Success is relative; the more success, the more relatives. -Anonymous From owner-mpls@UU.NET Fri Oct 11 18:09:22 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06062 for ; Fri, 11 Oct 2002 18:09:22 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkea10107 for ; Fri, 11 Oct 2002 22:11:28 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkea09462; Fri, 11 Oct 2002 22:11:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkea17815 for mpls-outgoing; Fri, 11 Oct 2002 22:10:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnkea17779 for ; Fri, 11 Oct 2002 22:10:41 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkea11838 for ; Fri, 11 Oct 2002 22:09:49 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkea08159 for ; Fri, 11 Oct 2002 22:09:49 GMT Received: from albatross.prod.itd.earthlink.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: albatross.mail.pas.earthlink.net [207.217.120.120]) id QQnkea08154 for ; Fri, 11 Oct 2002 22:09:48 GMT Received: from user-2ivfk2r.dialup.mindspring.com ([165.247.208.91] helo=earthlink.net) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 1807y9-0000Gj-00; Fri, 11 Oct 2002 15:09:18 -0700 Message-ID: <3DA74F42.C52FF9ED@earthlink.net> Date: Fri, 11 Oct 2002 15:22:58 -0700 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: Alia Atlas CC: Shahram Davari , "'Thomas D. Nadeau'" , mpls@UU.NET Subject: Re: what's the status ofdraft-ietf-mpls-rsvp-lsp-fastreroute-00. txt References: <5.1.0.14.2.20021011103645.01f535c8@mailhost.avici.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Group, and/or Shahram Davari, Doesn't early implementations of functionality always involve some risk that standard organizations will not accept the implementation? If the company is big-enough and they distribute enough copies of that functionality, then they use their customer-base to create a defacto-standard. Else, the company risks either being incompatible with the stardard, supporting multiple variations, or reverting their code to the now agreed upon standard. Thus, I don't know why Juniper doesn't release a Informational RFC on their implementation and the wg for this draft consider what should be done with the "path-specific method" to either achieve consensus or.... Mitchell Erblich ====================== Alia Atlas wrote: > > What about making the method an informational part of the draft, with the > sender-template-specific method a SHOULD? In that way, the information > about what was been done in the past will be preserved and inter-operable > implementations can be made, but only as long as the interoperability with > the path-specific method matters to someone. > > Alia > > At 07:09 AM 10/11/2002 -0700, Shahram Davari wrote: > >Unfortunately I did not see any consensus? and in fact I saw many > >objections. Therefore since no consensus exits for path-specific method, > >it has to be taken out of the draft. > > > >-Shahram > > > > > -----Original Message----- > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > Sent: Friday, October 11, 2002 9:10 AM > > > To: Shahram Davari > > > Cc: mpls@UU.NET > > > Subject: RE: what's the status of > > > draft-ietf-mpls-rsvp-lsp-fastreroute-00. txt > > > > > > > > > > > > > > As for the path-specific method, we cannot take it out > > > for a simple > > > > > reason, that is, it is how Juniper had implemented and > > > > > deployed. > > > > > > > >Although I have tried this a couple of times, but let me do it again: > > > > > > > >IETF is a standard organization. It is not a place to rubber stamp > > > >individual companies implementations, but rather a place to > > > figure out > > > >the best solutions for the industry. > > > > > > > >There is always a risk of implementing a technology before > > > it is standardized. > > > >If we go by your logic then every implementation in the > > > field must be > > > >standardized ! > > > > > > > >Does that make sense? > > > > > > Sharam, > > > > > > At the risk of repeating myself and others on the > > > topic, remember the > > > IETF mantra: working code and rough consensus. This is to a > > > large part > > > why the Internet works today and is still not a research project. > > > > > > --Tom > > > > > > > > > Success is relative; the more success, the more relatives. -Anonymous > > > From owner-mpls@UU.NET Fri Oct 11 18:15:46 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06176 for ; Fri, 11 Oct 2002 18:15:46 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkdh06209; Fri, 11 Oct 2002 17:26:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkdh05486 for mpls-outgoing; Fri, 11 Oct 2002 17:26:34 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnkdh05481 for ; Fri, 11 Oct 2002 17:26:26 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnkdh09125 for ; Fri, 11 Oct 2002 17:26:11 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkdh00965 for ; Fri, 11 Oct 2002 17:26:10 GMT Received: from mtiwmhc12.worldnet.att.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mtiwmhc12.worldnet.att.net [204.127.131.116]) id QQnkdh00953 for ; Fri, 11 Oct 2002 17:26:10 GMT Received: from 6640bbc3r131 ([12.81.4.233]) by mtiwmhc12.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with SMTP id <20021011172537.GHBG6348.mtiwmhc12.worldnet.att.net@6640bbc3r131>; Fri, 11 Oct 2002 17:25:37 +0000 Message-ID: <001c01c2714b$5966f240$e904510c@6640bbc3r131> From: "Brijesh Kumar" To: "Shahram Davari" , "'Thomas D. Nadeau'" Cc: References: <4B6D09F3B826D411A67300D0B706EFDEB039C7@nt-exch-yow.pmc-sierra.bc.ca> Subject: Re: what's the status of draft-ietf-mpls-rsvp-lsp-fastreroute-00. txt Date: Fri, 11 Oct 2002 10:26:32 -0700 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.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Tom, After following Shahram's mails on the issue, it doesn't look like that the draft has a consensus. The working code only comes after there is a consensus, not other way round. Otherwise, it is not clear whose "working code" one is talking about. Cheers, --brijesh ----- Original Message ----- From: "Shahram Davari" To: "'Thomas D. Nadeau'" Cc: Sent: Friday, October 11, 2002 7:09 AM Subject: RE: what's the status of draft-ietf-mpls-rsvp-lsp-fastreroute-00. txt > Unfortunately I did not see any consensus? and in fact I saw many > objections. Therefore since no consensus exits for path-specific method, > it has to be taken out of the draft. > > -Shahram > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: Friday, October 11, 2002 9:10 AM > > To: Shahram Davari > > Cc: mpls@UU.NET > > Subject: RE: what's the status of > > draft-ietf-mpls-rsvp-lsp-fastreroute-00. txt > > > > > > > > > > As for the path-specific method, we cannot take it out > > for a simple > > > > reason, that is, it is how Juniper had implemented and > > > > deployed. > > > > > >Although I have tried this a couple of times, but let me do it again: > > > > > >IETF is a standard organization. It is not a place to rubber stamp > > >individual companies implementations, but rather a place to > > figure out > > >the best solutions for the industry. > > > > > >There is always a risk of implementing a technology before > > it is standardized. > > >If we go by your logic then every implementation in the > > field must be > > >standardized ! > > > > > >Does that make sense? > > > > Sharam, > > > > At the risk of repeating myself and others on the > > topic, remember the > > IETF mantra: working code and rough consensus. This is to a > > large part > > why the Internet works today and is still not a research project. > > > --Tom From owner-mpls@UU.NET Fri Oct 11 19:25:52 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06898 for ; Fri, 11 Oct 2002 19:25:51 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkef28313 for ; Fri, 11 Oct 2002 23:27:53 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkef27055; Fri, 11 Oct 2002 23:27:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkef10278 for mpls-outgoing; Fri, 11 Oct 2002 23:26:43 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnkef10273 for ; Fri, 11 Oct 2002 23:26:42 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnkef22646 for ; Fri, 11 Oct 2002 23:25:08 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkef24968 for ; Fri, 11 Oct 2002 23:25:07 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnkef24834 for ; Fri, 11 Oct 2002 23:25:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA08295 for ; Fri, 11 Oct 2002 19:25:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9BNP2720943 for mpls@uu.net; Fri, 11 Oct 2002 19:25:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnkef10021 for ; Fri, 11 Oct 2002 23:24:02 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkef20623 for ; Fri, 11 Oct 2002 23:23:55 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkef09146 for ; Fri, 11 Oct 2002 23:23:55 GMT Received: from c2.ciena.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.118.32.25]) id QQnkef09140 for ; Fri, 11 Oct 2002 23:23:55 GMT Received: by c2.ciena.com (8.8.8+Sun/SMI-SVR4-8.0) id TAA03873; Fri, 11 Oct 2002 19:23:54 -0400 (EDT) Received: from wntcsdexg01.csd.ciena.com(10.128.2.158) by c2.ciena.com via smap (V2.0) id xma003836; Fri, 11 Oct 02 19:23:49 -0400 Received: by wntcsdexg01.csd.ciena.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Oct 2002 16:23:48 -0700 Received: from ciena.com (ppan [10.128.20.74]) by wntcsdexg02.csd.ciena.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PF7Z5L14; Fri, 11 Oct 2002 16:23:38 -0700 From: "Pan, Ping" Cc: Shahram Davari , "'Thomas D. Nadeau'" , mpls@UU.NET Message-ID: <3DA75D68.9020104@ciena.com> Date: Fri, 11 Oct 2002 16:23:20 -0700 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: what's the status ofdraft-ietf-mpls-rsvp-lsp-fastreroute-00. txt References: <5.1.0.14.2.20021011103645.01f535c8@mailhost.avici.com> <3DA74F42.C52FF9ED@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hmmm... let me see who have done what in this space... Path-specific one-to-one method: Juniper, several routers (cannot tell the names) Sender-specific one-to-one method: Avici. ? Many-to-one method: Cisco (both node and link protection), Juniper (link protection for now). We never said that every vendor has to support everything in the draft right away right now. Since each method has its own merits, we let the developers and carriers to decide. To talk about lack of consensus based on some people's comment is quite amazing and disturbing. People have been asking why we glued two approaches together in the first place. It looks like we are here for some rubber-stamping. But you guys gotta ask yourself this: Cisco and Juniper are not the best friends in the first place, so why in the world do they get together to do this? The answer is that marketing people tried to kill each other, but didn't work. :-) The customers seem to know more than we do on the advantages and disadvantages of both methods... ... It's been a slow Friday afternoon. Let me tell the whole story behind this fast reroute crap: About one year ago, Der-Hwa Gan got one-to-one fast reroute working on Juniper routers. The original idea came from Tony Li (while in Juniper) and Der-Hwa. It was by far the most complex code in RSVP (you guys ought to try it someday). It worked, and shipped. At the same time, Cisco got a MPLS fast-reroute working as well. Both methods didn't work together. So one day, Dave Cooper of Global Crossing came to us and told us that he needed fast reroute to be compatible with each other, and didn't care how to achieve it. I got the assignment, found a copy of draft-swallow, and started the coding. When I thought it was done, I hooked up a Cisco router. Nothing worked! There was no sender-specific stuff in sight. All I got was the original Path messages tunneled through the bypass LSP. After talking to George Swallow and JP directly over the phone, I was told that the new code was still in beta, and has not been released yet. To me, being upset was an understatement! But Cisco folks were kind enough to send a copy of their new draft that actually told me how it supposes to work. As my release date slipping fast, I had to rewrite the darn thing from scratch. More disturbing discovery was that since Cisco used Shared-explicit style, while Juniper used Fixed-Filter, there was no way we could turn on both Juniper and Cisco fast reroute to protect a single LSP. We could not ship this fast-reroute feature this way to the customers. Around this time, Alia from Avici told us that they had been reverse engineering Juniper fast reroute, and had found several serious problems (including merging rules and sender-specific vs. path-specific). So Der-Hwa and I started to changed our code while changing the spec. That merging rule in the draft was actually a line-by-line pseudo code at one point. It was kinda fun thinking back. :-) When I was done with the facility fast reroute proposed by Cisco, there were a lot of implementation issues. So I merged both drafts together, and sent it to George and JP for correction along with a bunch of questions. Avici folks came on board also. So we had several rounds of discussion and disagreement, but came up a draft that developers knew how to implement. That was what you have seen. The final outcome of the draft would allow both one-to-one and many-to-one fast reroute to be turned on to protect a single LSP. Both sender-specific and path-specific would work together too. That's what you have in Junos 5.4. The implementation of facility fast-reroute was limited to link protection in Juniper so far, because that was what Dave Cooper wanted anyway. Dave was kind enough that we actually interop'ed the facility fast-reroute with Cisco developers (Rob and Carol) in Global Crossing lab (this is bud to you, Brook!). The reason for telling you all this is that this draft came directly from engineers with the help from providers. No vendor politics, no IETF politics, it was a lot of pain and fun at the end! If you are a developer, you can really implement this by reading spec. So before you question our motives again, please reconsider. Thanks! - Ping From owner-mpls@UU.NET Fri Oct 11 19:33:31 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07017 for ; Fri, 11 Oct 2002 19:33:30 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkeg22908 for ; Fri, 11 Oct 2002 23:35:33 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkeg21993; Fri, 11 Oct 2002 23:35:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkeg10793 for mpls-outgoing; Fri, 11 Oct 2002 23:34:48 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnkeg10784 for ; Fri, 11 Oct 2002 23:34:41 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnkeg01572 for ; Fri, 11 Oct 2002 23:34:13 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkeg08842 for ; Fri, 11 Oct 2002 23:34:13 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnkeg08835 for ; Fri, 11 Oct 2002 23:34:12 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA08708 for ; Fri, 11 Oct 2002 19:34:12 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9BNYCU22160 for mpls@uu.net; Fri, 11 Oct 2002 19:34:12 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnkeg10727 for ; Fri, 11 Oct 2002 23:33:41 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkeg29840 for ; Fri, 11 Oct 2002 23:32:31 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkeg18855 for ; Fri, 11 Oct 2002 23:32:31 GMT Received: from c2.ciena.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.118.32.25]) id QQnkeg18847 for ; Fri, 11 Oct 2002 23:32:30 GMT Received: by c2.ciena.com (8.8.8+Sun/SMI-SVR4-8.0) id TAA05300; Fri, 11 Oct 2002 19:32:29 -0400 (EDT) Received: from wntcsdexg01.csd.ciena.com(10.128.2.158) by c2.ciena.com via smap (V2.0) id xma005246; Fri, 11 Oct 02 19:32:09 -0400 Received: by wntcsdexg01.csd.ciena.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Oct 2002 16:32:08 -0700 Received: from ciena.com (ppan [10.128.20.74]) by wntcsdexg02.csd.ciena.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PF7Z5L1Y; Fri, 11 Oct 2002 16:32:02 -0700 From: "Pan, Ping" To: Alia Atlas Cc: Shahram Davari , "'Thomas D. Nadeau'" , mpls@UU.NET Message-ID: <3DA75F60.9060301@ciena.com> Date: Fri, 11 Oct 2002 16:31:44 -0700 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: what's the status of draft-ietf-mpls-rsvp-lsp-fastreroute-00. txt References: <5.1.0.14.2.20021011103645.01f535c8@mailhost.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Alia, please don't go down that path. :-) We have seen that informational RFC 2547.... Let the customers decide, not IETF. Alia Atlas wrote: > What about making the method an informational part of the draft, with > the sender-template-specific method a SHOULD? In that way, the > information about what was been done in the past will be preserved and > inter-operable implementations can be made, but only as long as the > interoperability with the path-specific method matters to someone. > > Alia > > At 07:09 AM 10/11/2002 -0700, Shahram Davari wrote: > >> Unfortunately I did not see any consensus? and in fact I saw many >> objections. Therefore since no consensus exits for path-specific method, >> it has to be taken out of the draft. >> >> -Shahram >> >> > -----Original Message----- >> > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >> > Sent: Friday, October 11, 2002 9:10 AM >> > To: Shahram Davari >> > Cc: mpls@UU.NET >> > Subject: RE: what's the status of >> > draft-ietf-mpls-rsvp-lsp-fastreroute-00. txt >> > >> > >> > >> > > > As for the path-specific method, we cannot take it out >> > for a simple >> > > > reason, that is, it is how Juniper had implemented and >> > > > deployed. >> > > >> > >Although I have tried this a couple of times, but let me do it again: >> > > >> > >IETF is a standard organization. It is not a place to rubber stamp >> > >individual companies implementations, but rather a place to >> > figure out >> > >the best solutions for the industry. >> > > >> > >There is always a risk of implementing a technology before >> > it is standardized. >> > >If we go by your logic then every implementation in the >> > field must be >> > >standardized ! >> > > >> > >Does that make sense? >> > >> > Sharam, >> > >> > At the risk of repeating myself and others on the >> > topic, remember the >> > IETF mantra: working code and rough consensus. This is to a >> > large part >> > why the Internet works today and is still not a research project. >> > >> > --Tom >> > >> > >> > Success is relative; the more success, the more relatives. -Anonymous >> > > > From owner-mpls@UU.NET Fri Oct 11 19:49:50 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07333 for ; Fri, 11 Oct 2002 19:49:50 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkeh29471 for ; Fri, 11 Oct 2002 23:51:53 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkeh28196; Fri, 11 Oct 2002 23:51:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkeh12197 for mpls-outgoing; Fri, 11 Oct 2002 23:50:48 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnkeh12191 for ; Fri, 11 Oct 2002 23:50:40 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkeh06108 for ; Fri, 11 Oct 2002 23:49:17 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkeh12380 for ; Fri, 11 Oct 2002 23:49:16 GMT Received: from mlsrv1.avici.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host128.avici.com [208.246.215.128] (may be forged)) id QQnkeh12371 for ; Fri, 11 Oct 2002 23:49:16 GMT Received: from aatlas-lt.avici.com (vpn-pc37.avici.com [10.6.101.57]) by mlsrv1.avici.com (8.11.0/8.11.0) with ESMTP id g9BNn4V09370; Fri, 11 Oct 2002 19:49:04 -0400 (EDT) Message-Id: <5.1.0.14.2.20021011193609.01faf8c8@mailhost.avici.com> X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 11 Oct 2002 19:49:48 -0400 To: "Pan, Ping" From: Alia Atlas Subject: Re: what's the status ofdraft-ietf-mpls-rsvp-lsp-fastreroute-00. txt Cc: Shahram Davari , "'Thomas D. Nadeau'" , mpls@UU.NET In-Reply-To: <3DA75D68.9020104@ciena.com> References: <5.1.0.14.2.20021011103645.01f535c8@mailhost.avici.com> <3DA74F42.C52FF9ED@earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Absolutely. The real requirement has been for inter-operability. It is important that what is out there be inter-operable and provide the functionality required. While I would not have chosen the trade-offs made for the path-specific method, there are advantages to it (earlier merging of detours so less bandwidth reserved) as well as disadvantages. Let those who plan to deploy it decide what they want. The draft says how to sit down and actually implement this feature. As Ping says, the code for it is rather complicated. One has to keep track of merging states, keeping state around even though the relevant interface is down, propagating or not propagating messages, etc. That said, much as Ping had the need to inter-operate with Cisco's bypass tunnels, we've had the requirement to inter-operate with both. Much like Ping, I sat down and figured out what would be possible and logical to do; we did so. That's why I did the draft suggesting how to deal in a network with both cases. Certainly, we've implemented both the Path-specific method as well as the sender-specific method, because of the requirement to interoperate. That's what standardization is about - the need to interoperate. We're keeping the old Class-type for FAST_REROUTE, without the include-any administrative-color, in the draft for the same reason. It describes what is done. Clearly the issue of the path-specific method is contentious. Are there others with opinions on this one? Perhaps we could/should put in some applicability words about the advantages and disadvantages of each approach to aid those deciding which to implement and/or deploy? Alia At 04:23 PM 10/11/2002 -0700, Pan, Ping wrote: >Hmmm... let me see who have done what in this space... > >Path-specific one-to-one method: > Juniper, several routers (cannot tell the names) > >Sender-specific one-to-one method: > Avici. ? > >Many-to-one method: > Cisco (both node and link protection), Juniper (link protection for now). > >We never said that every vendor has to support everything in the draft >right away right now. Since each method has its own merits, we let the >developers and carriers to decide. > >To talk about lack of consensus based on some people's comment is quite >amazing and disturbing. > >People have been asking why we glued two approaches together in the first >place. It looks like we are here for some rubber-stamping. But you guys >gotta ask yourself this: Cisco and Juniper are not the best friends in the >first place, so why in the world do they get together to do this? The >answer is that marketing people tried to kill each other, but didn't work. >:-) The customers seem to know more than we do on the advantages and >disadvantages of both methods... > >... It's been a slow Friday afternoon. Let me tell the whole story behind >this fast reroute crap: > >About one year ago, Der-Hwa Gan got one-to-one fast reroute working on >Juniper routers. The original idea came from Tony Li (while in Juniper) >and Der-Hwa. It was by far the most complex code in RSVP (you guys ought >to try it someday). It worked, and shipped. At the same time, Cisco got a >MPLS fast-reroute working as well. Both methods didn't work together. So >one day, Dave Cooper of Global Crossing came to us and told us that he >needed fast reroute to be compatible with each other, and didn't care how >to achieve it. > >I got the assignment, found a copy of draft-swallow, and started the >coding. When I thought it was done, I hooked up a Cisco router. Nothing >worked! There was no sender-specific stuff in sight. All I got was the >original Path messages tunneled through the bypass LSP. After talking to >George Swallow and JP directly over the phone, I was told that the new >code was still in beta, and has not been released yet. To me, being upset >was an understatement! But Cisco folks were kind enough to send a copy of >their new draft that actually told me how it supposes to work. As my >release date slipping fast, I had to rewrite the darn thing from scratch. > >More disturbing discovery was that since Cisco used Shared-explicit style, >while Juniper used Fixed-Filter, there was no way we could turn on both >Juniper and Cisco fast reroute to protect a single LSP. We could not ship >this fast-reroute feature this way to the customers. Around this time, >Alia from Avici told us that they had been reverse engineering Juniper >fast reroute, and had found several serious problems (including merging >rules and sender-specific vs. path-specific). So Der-Hwa and I started to >changed our code while changing the spec. That merging rule in the draft >was actually a line-by-line pseudo code at one point. It was kinda fun >thinking back. :-) > >When I was done with the facility fast reroute proposed by Cisco, there >were a lot of implementation issues. So I merged both drafts together, and >sent it to George and JP for correction along with a bunch of questions. >Avici folks came on board also. So we had several rounds of discussion and >disagreement, but came up a draft that developers knew how to implement. >That was what you have seen. > >The final outcome of the draft would allow both one-to-one and many-to-one >fast reroute to be turned on to protect a single LSP. Both sender-specific >and path-specific would work together too. That's what you have in Junos >5.4. The implementation of facility fast-reroute was limited to link >protection in Juniper so far, because that was what Dave Cooper wanted >anyway. Dave was kind enough that we actually interop'ed the facility >fast-reroute with Cisco developers (Rob and Carol) in Global Crossing lab >(this is bud to you, Brook!). > >The reason for telling you all this is that this draft came directly from >engineers with the help from providers. No vendor politics, no IETF >politics, it was a lot of pain and fun at the end! If you are a developer, >you can really implement this by reading spec. > >So before you question our motives again, please reconsider. > >Thanks! > >- Ping From owner-mpls@UU.NET Fri Oct 11 21:14:07 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08526 for ; Fri, 11 Oct 2002 21:14:07 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnken03190 for ; Sat, 12 Oct 2002 01:16:12 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnken02260; Sat, 12 Oct 2002 01:15:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQnken21541 for mpls-outgoing; Sat, 12 Oct 2002 01:15:33 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnken21536 for ; Sat, 12 Oct 2002 01:15:30 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnkem15053 for ; Sat, 12 Oct 2002 01:12:37 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkem26693 for ; Sat, 12 Oct 2002 01:12:37 GMT Received: from hall.mail.mindspring.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hall.mail.mindspring.net [207.69.200.60]) id QQnkem26685 for ; Sat, 12 Oct 2002 01:12:36 GMT Received: from user-uinjme7.dsl.mindspring.com ([165.121.217.199] helo=METANOIA) by hall.mail.mindspring.net with smtp (Exim 3.33 #1) id 180ApE-00041Z-00; Fri, 11 Oct 2002 21:12:16 -0400 Reply-To: From: "Vishal Sharma" To: "Alia Atlas" , "Pan, Ping" Cc: "Shahram Davari" , "'Thomas D. Nadeau'" , Subject: RE: what's the status ofdraft-ietf-mpls-rsvp-lsp-fastreroute-00. txt Date: Fri, 11 Oct 2002 21:12:29 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <5.1.0.14.2.20021011193609.01faf8c8@mailhost.avici.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Alia, I think the applicability idea is a very good one. Have been following the interesting exchange for a while, and the applicability idea would indeed be helpful in clearing confusions all around. I would think a separate applicability draft on the applicability of fast reroute techniques might be preferable, rather than cluttering the existing draft that focuses on protocol details and method descriptions. -Vishal > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Alia > Atlas > Sent: Friday, October 11, 2002 7:50 PM > To: Pan, Ping > Cc: Shahram Davari; 'Thomas D. Nadeau'; mpls@UU.NET > Subject: Re: what's the status > ofdraft-ietf-mpls-rsvp-lsp-fastreroute-00. txt > > > Absolutely. The real requirement has been for inter-operability. It is > important that what is out there be inter-operable and provide the > functionality required. > > While I would not have chosen the trade-offs made for the path-specific > method, there are advantages to it (earlier merging of detours so less > bandwidth reserved) as well as disadvantages. Let those who plan to > deploy it decide what they want. > > The draft says how to sit down and actually implement this feature. As > Ping says, the code for it is rather complicated. One has to keep track > of merging states, keeping state around even though the relevant > interface > is down, propagating or not propagating messages, etc. > > That said, much as Ping had the need to inter-operate with Cisco's bypass > tunnels, we've had the requirement to inter-operate with both. Much like > Ping, I sat down and figured out what would be possible and > logical to do; > we did so. That's why I did the draft suggesting how to deal in > a network > with both cases. > > Certainly, we've implemented both the Path-specific method as well as the > sender-specific method, because of the requirement to > interoperate. That's > what standardization is about - the need to interoperate. > > We're keeping the old Class-type for FAST_REROUTE, without the > include-any > administrative-color, in the draft for the same reason. It > describes what > is done. > > Clearly the issue of the path-specific method is contentious. Are there > others with opinions on this one? Perhaps we could/should put in some > applicability words about the advantages and disadvantages of > each approach > to aid those deciding which to implement and/or deploy? > > Alia > > At 04:23 PM 10/11/2002 -0700, Pan, Ping wrote: > >Hmmm... let me see who have done what in this space... > > > >Path-specific one-to-one method: > > Juniper, several routers (cannot tell the names) > > > >Sender-specific one-to-one method: > > Avici. ? > > > >Many-to-one method: > > Cisco (both node and link protection), Juniper (link > protection for now). > > > >We never said that every vendor has to support everything in the draft > >right away right now. Since each method has its own merits, we let the > >developers and carriers to decide. > > > >To talk about lack of consensus based on some people's comment is quite > >amazing and disturbing. > > > >People have been asking why we glued two approaches together in > the first > >place. It looks like we are here for some rubber-stamping. But you guys > >gotta ask yourself this: Cisco and Juniper are not the best > friends in the > >first place, so why in the world do they get together to do this? The > >answer is that marketing people tried to kill each other, but > didn't work. > >:-) The customers seem to know more than we do on the advantages and > >disadvantages of both methods... > > > >... It's been a slow Friday afternoon. Let me tell the whole > story behind > >this fast reroute crap: > > > >About one year ago, Der-Hwa Gan got one-to-one fast reroute working on > >Juniper routers. The original idea came from Tony Li (while in Juniper) > >and Der-Hwa. It was by far the most complex code in RSVP (you guys ought > >to try it someday). It worked, and shipped. At the same time, > Cisco got a > >MPLS fast-reroute working as well. Both methods didn't work together. So > >one day, Dave Cooper of Global Crossing came to us and told us that he > >needed fast reroute to be compatible with each other, and didn't > care how > >to achieve it. > > > >I got the assignment, found a copy of draft-swallow, and started the > >coding. When I thought it was done, I hooked up a Cisco router. Nothing > >worked! There was no sender-specific stuff in sight. All I got was the > >original Path messages tunneled through the bypass LSP. After talking to > >George Swallow and JP directly over the phone, I was told that the new > >code was still in beta, and has not been released yet. To me, > being upset > >was an understatement! But Cisco folks were kind enough to send > a copy of > >their new draft that actually told me how it supposes to work. As my > >release date slipping fast, I had to rewrite the darn thing from scratch. > > > >More disturbing discovery was that since Cisco used > Shared-explicit style, > >while Juniper used Fixed-Filter, there was no way we could turn on both > >Juniper and Cisco fast reroute to protect a single LSP. We could > not ship > >this fast-reroute feature this way to the customers. Around this time, > >Alia from Avici told us that they had been reverse engineering Juniper > >fast reroute, and had found several serious problems (including merging > >rules and sender-specific vs. path-specific). So Der-Hwa and I > started to > >changed our code while changing the spec. That merging rule in the draft > >was actually a line-by-line pseudo code at one point. It was kinda fun > >thinking back. :-) > > > >When I was done with the facility fast reroute proposed by Cisco, there > >were a lot of implementation issues. So I merged both drafts > together, and > >sent it to George and JP for correction along with a bunch of questions. > >Avici folks came on board also. So we had several rounds of > discussion and > >disagreement, but came up a draft that developers knew how to implement. > >That was what you have seen. > > > >The final outcome of the draft would allow both one-to-one and > many-to-one > >fast reroute to be turned on to protect a single LSP. Both > sender-specific > >and path-specific would work together too. That's what you have in Junos > >5.4. The implementation of facility fast-reroute was limited to link > >protection in Juniper so far, because that was what Dave Cooper wanted > >anyway. Dave was kind enough that we actually interop'ed the facility > >fast-reroute with Cisco developers (Rob and Carol) in Global > Crossing lab > >(this is bud to you, Brook!). > > > >The reason for telling you all this is that this draft came > directly from > >engineers with the help from providers. No vendor politics, no IETF > >politics, it was a lot of pain and fun at the end! If you are a > developer, > >you can really implement this by reading spec. > > > >So before you question our motives again, please reconsider. > > > >Thanks! > > > >- Ping > > From owner-mpls@UU.NET Fri Oct 11 22:23:25 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09619 for ; Fri, 11 Oct 2002 22:23:25 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnker12763 for ; Sat, 12 Oct 2002 02:25:30 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnker11752; Sat, 12 Oct 2002 02:25:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQnker12572 for mpls-outgoing; Sat, 12 Oct 2002 02:24:44 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnker12566 for ; Sat, 12 Oct 2002 02:24:41 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnker23393 for ; Sat, 12 Oct 2002 02:24:29 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnker10508 for ; Sat, 12 Oct 2002 02:24:28 GMT Received: from mlsrv1.avici.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host128.avici.com [208.246.215.128] (may be forged)) id QQnker10498 for ; Sat, 12 Oct 2002 02:24:27 GMT Received: from aatlas-lt.avici.com (vpn-pc37.avici.com [10.6.101.57]) by mlsrv1.avici.com (8.11.0/8.11.0) with ESMTP id g9C2CeV17769; Fri, 11 Oct 2002 22:12:40 -0400 (EDT) Message-Id: <5.1.0.14.2.20021011221120.01fb81c8@mailhost.avici.com> X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 11 Oct 2002 22:13:24 -0400 To: "Pan, Ping" From: Alia Atlas Subject: Re: what's the status of draft-ietf-mpls-rsvp-lsp-fastreroute-00. txt Cc: Shahram Davari , "'Thomas D. Nadeau'" , mpls@UU.NET In-Reply-To: <3DA75F60.9060301@ciena.com> References: <5.1.0.14.2.20021011103645.01f535c8@mailhost.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Good point. :-) I was just hunting a reasonable compromise... if it becomes necessary. I'd rather not frankly. Let's just get what we've defined clearly standardized. Alia At 04:31 PM 10/11/2002 -0700, Pan, Ping wrote: >Alia, please don't go down that path. :-) We have seen that informational >RFC 2547.... Let the customers decide, not IETF. > >Alia Atlas wrote: >>What about making the method an informational part of the draft, with the >>sender-template-specific method a SHOULD? In that way, the information >>about what was been done in the past will be preserved and inter-operable >>implementations can be made, but only as long as the interoperability >>with the path-specific method matters to someone. >>Alia >>At 07:09 AM 10/11/2002 -0700, Shahram Davari wrote: >> >>>Unfortunately I did not see any consensus? and in fact I saw many >>>objections. Therefore since no consensus exits for path-specific method, >>>it has to be taken out of the draft. >>> >>>-Shahram >>> >>> > -----Original Message----- >>> > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >>> > Sent: Friday, October 11, 2002 9:10 AM >>> > To: Shahram Davari >>> > Cc: mpls@UU.NET >>> > Subject: RE: what's the status of >>> > draft-ietf-mpls-rsvp-lsp-fastreroute-00. txt >>> > >>> > >>> > >>> > > > As for the path-specific method, we cannot take it out >>> > for a simple >>> > > > reason, that is, it is how Juniper had implemented and >>> > > > deployed. >>> > > >>> > >Although I have tried this a couple of times, but let me do it again: >>> > > >>> > >IETF is a standard organization. It is not a place to rubber stamp >>> > >individual companies implementations, but rather a place to >>> > figure out >>> > >the best solutions for the industry. >>> > > >>> > >There is always a risk of implementing a technology before >>> > it is standardized. >>> > >If we go by your logic then every implementation in the >>> > field must be >>> > >standardized ! >>> > > >>> > >Does that make sense? >>> > >>> > Sharam, >>> > >>> > At the risk of repeating myself and others on the >>> > topic, remember the >>> > IETF mantra: working code and rough consensus. This is to a >>> > large part >>> > why the Internet works today and is still not a research project. >>> > >>> > --Tom >>> > >>> > >>> > Success is relative; the more success, the more relatives. -Anonymous >>> > > From owner-mpls@UU.NET Sun Oct 13 11:45:19 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20975 for ; Sun, 13 Oct 2002 11:45:19 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkkl27917 for ; Sun, 13 Oct 2002 15:47:26 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkkl27074; Sun, 13 Oct 2002 15:47:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkkl26282 for mpls-outgoing; Sun, 13 Oct 2002 15:46:00 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnkkl26277 for ; Sun, 13 Oct 2002 15:45:58 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnkkk03719 for ; Sun, 13 Oct 2002 15:44:37 GMT Received: from tomp.smb.utfors.se by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tomp.smb.utfors.se [195.58.112.6]) id QQnkkj19691 for ; Sun, 13 Oct 2002 15:21:58 GMT Received: from utfors.se ([195.58.105.106]) by tomp.smb.utfors.se (Netscape Messaging Server 4.15) with ESMTP id H3XEX100.7O3; Sun, 13 Oct 2002 17:27:01 +0200 Message-ID: <3DA98F6F.9020100@utfors.se> Date: Sun, 13 Oct 2002 17:21:19 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls wg , George Swallow , Scott Bradner Subject: status of mpls draft - and slots at the Atlanta meeting Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit All, as a step in preparation for the meeting in Atlanta here is an over view of the state of the MPLS drafts WG discussion draft-ietf-mpls-lsp-query-04.txt Awaiting updates from authors draft-ietf-mpls-ttl-03.txt draft-ietf-mpls-te-feed-04.txt draft-ietf-mpls-rsvp-unnum-07.txt draft-ietf-mpls-recovery-frmwrk-06.txt (the iesg has suggested updates and editors working on it, some further comments from the wg will also be incorporated) draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt draft-ietf-mpls-lsp-query-04.txt draft-ietf-mpls-ldp-mtu-extensions-00.txt Updated from authors: draft-ietf-mpls-lsp-ping-01.txt (wg last call scheduled after the Atlanta meeting) WG Last call draft-ietf-mpls-ldp-ft-05.txt draft-ietf-mpls-bgp-mpls-restart-01.txt draft-ietf-mpls-ldp-restart-03.txt (intention is to submit the drafts to the iesg after this wg last call) Under IESG -review draft-ietf-mpls-crldp-unnum-08.txt draft-ietf-mpls-bundle-04.txt draft-ietf-mpls-lsp-hierarchy-07.txt MIBs draft-ietf-mpls-te-mib-08.txt draft-ietf-mpls-lsr-mib-08.txt draft-ietf-mpls-ftn-mib-04.txt draft-ietf-mpls-mgmt-overview-02.txt draft-ietf-mpls-ldp-mib-08.txt draft-ietf-mpls-tc-mib-03.txt draft-ietf-mpls-bundle-mib-03.txt draft-ietf-mpls-fastreroute-mib-00.txt all the MIBs will be review at the earlier announced open review meeting in Atlanta. Since the MIBs are being updated just now, look for the next version if you can't find the ones listed in the repository. Authors, if this does not match what you think is the state of your draft let us know! If you want time to discuss issues around the draft at the Atlanta meeting let us know. Note: Joan and Tom will report the result of the review to the wg meeting in Atlanta. As necessary wg chairs and/or ADs will also discuss to outcome of this meeting. /Loa and George -- Loa Andersson Utfors AB Email loa.andersson@utfors.se From owner-mpls@UU.NET Sun Oct 13 11:46:35 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21048 for ; Sun, 13 Oct 2002 11:46:35 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkkl29604 for ; Sun, 13 Oct 2002 15:48:41 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkkl28758; Sun, 13 Oct 2002 15:48:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkkl26523 for mpls-outgoing; Sun, 13 Oct 2002 15:47:50 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnkkl26516 for ; Sun, 13 Oct 2002 15:47:41 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnkkl17012 for ; Sun, 13 Oct 2002 15:46:24 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkkl26582 for ; Sun, 13 Oct 2002 15:46:23 GMT Received: from tomp.smb.utfors.se by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tomp.smb.utfors.se [195.58.112.6]) id QQnkkl26562 for ; Sun, 13 Oct 2002 15:46:23 GMT Received: from utfors.se ([195.58.105.106]) by tomp.smb.utfors.se (Netscape Messaging Server 4.15) with ESMTP id H3XG2T00.0P8; Sun, 13 Oct 2002 17:52:05 +0200 Message-ID: <3DA9954E.5050206@utfors.se> Date: Sun, 13 Oct 2002 17:46:22 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls wg , George Swallow , Scott Bradner , Bert Wijnen Subject: the mpls wg meeting in Atlanta Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit All, it is time to start setting the agenda for the Atlanta meeting. If you want to discuss issues with drafts at the Atlanta meeting please request a slot to do so, by sending mail to the wg chairs. As always the slots will be allocated for discussions according to what is outlined below. Loa and George ---------------------------------------------------------------- It is not the purpose of a WG session to have presentation of the content of a document. It is assumed that all attendees will have read the drafts in advance of the meeting. For documents that are work-in-progress, the presentation should cover issues resolved since the last draft followed by open issues and controversial topics with the intent to reach a resolution of said issues and topics. For new work items, the presentation should focus on what the problem is and why it is necessary for the work group to address it. Further it should be either shown how it falls within the existing charter or why and how the charter should be extended to encompass it. The solution should only be sketched. The appropriate way of bringing new work to the working group is to send a draft to the mailing list and promoting discussion on the list. Slots on the agenda should be used to discuss outstanding topics that has not be solved on the mailing list. For new proposals addressing issues where work-in-progess the presentation should focus on the (perceived) short-fallings of the existing work and why those issues need to be addressed both in terms of why they are required and why they cannot be addressed in the existing work. the new work must be related to existing work (i.e. compatible, mutually exclusive, outright replacement). Finally, the new solution should be skechted, explaining how the solution overcomes those issues. The primary purpose of this last part is to allow commentary from the floor, it should not be orientented toward selling the idea. In all cases only a limited number of slides should be used. Speakers should budget their at least 25% of their time to allow for questions. Loa and George -- Loa Andersson Utfors AB Email loa.andersson@utfors.se From owner-mpls@UU.NET Sun Oct 13 18:37:05 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25568 for ; Sun, 13 Oct 2002 18:37:04 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnklm22696 for ; Sun, 13 Oct 2002 22:39:12 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnklm21935; Sun, 13 Oct 2002 22:38:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQnklm19829 for mpls-outgoing; Sun, 13 Oct 2002 22:38:32 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnklm19822 for ; Sun, 13 Oct 2002 22:38:27 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnklm09660 for ; Sun, 13 Oct 2002 22:36:50 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnklm21347 for ; Sun, 13 Oct 2002 22:36:50 GMT Received: from tomp.smb.utfors.se by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tomp.smb.utfors.se [195.58.112.6]) id QQnklm21338 for ; Sun, 13 Oct 2002 22:36:49 GMT Received: from utfors.se ([195.58.105.89]) by tomp.smb.utfors.se (Netscape Messaging Server 4.15) with ESMTP id H3XZ2U00.LTI; Mon, 14 Oct 2002 00:42:30 +0200 Message-ID: <3DA9F580.4070305@utfors.se> Date: Mon, 14 Oct 2002 00:36:48 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MPLS wg CC: Loa Andersson , George Swallow Subject: Re: wg lst call on ft/restart drafts References: <3D97FD64.1030707@utfors.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit All, this last call has ended! /Loa Loa Andersson wrote: > All, > > this is to initiate a wg last call on the following drafts. > > draft-ietf-mpls-bgp-mpls-restart-01.txt > draft-ietf-mpls-ldp-restart-03.txt > draft-ietf-mpls-ldp-ft-05.txt > > > All draft has been through wg last call and been updated according > to the comments in the last call. The normal way of doing this would > be to restrict the comments in this last call to the changes only, > however in this case I would like to invite comments on the > drafts as a group, since there has been a need to coordinate them. > > Further information on this is found in: > > > > This document is not yet up for a last call, but, as a first step, > we propose it to become a working group document. Comments on the > draft will be viewed in this context. > > The last call will end October 13th 12.00 PM GMT > > > /Loa -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se From owner-mpls@UU.NET Mon Oct 14 07:30:34 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14797 for ; Mon, 14 Oct 2002 07:30:33 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnknm26685 for ; Mon, 14 Oct 2002 11:32:38 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnknm25291; Mon, 14 Oct 2002 11:32:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQnknm17861 for mpls-outgoing; Mon, 14 Oct 2002 11:31:32 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnknm17830 for ; Mon, 14 Oct 2002 11:31:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnknm18808 for ; Mon, 14 Oct 2002 11:30:29 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnknm14053 for ; Mon, 14 Oct 2002 11:30:29 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnknm14048 for ; Mon, 14 Oct 2002 11:30:28 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA10193 for ; Mon, 14 Oct 2002 07:30:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9EBU1C06438 for mpls@uu.net; Mon, 14 Oct 2002 07:30:01 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnknl17631 for ; Mon, 14 Oct 2002 11:28:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnknl22144 for ; Mon, 14 Oct 2002 11:28:13 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnknl19575 for ; Mon, 14 Oct 2002 11:28:12 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQnknl19565 for ; Mon, 14 Oct 2002 11:28:12 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14655; Mon, 14 Oct 2002 07:26:01 -0400 (EDT) Message-Id: <200210141126.HAA14655@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt Date: Mon, 14 Oct 2002 07:26:01 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --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 : Definitions of Textual for Multiprotocol Label Switching (MPLS) Management Author(s) : T. Nadeau et al. Filename : draft-ietf-mpls-tc-mib-04.txt Pages : 18 Date : 2002-10-11 This memo describes Textual Conventions for use in definitions of management information for Multiprotocol Label Switching (MPLS) networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tc-mib-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-tc-mib-04.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-tc-mib-04.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: <2002-10-11133842.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-tc-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-tc-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-11133842.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Oct 14 07:32:31 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14884 for ; Mon, 14 Oct 2002 07:32:31 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnknm04805 for ; Mon, 14 Oct 2002 11:34:38 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnknm03811; Mon, 14 Oct 2002 11:34:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQnknm17900 for mpls-outgoing; Mon, 14 Oct 2002 11:33:47 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnknm17877 for ; Mon, 14 Oct 2002 11:33:34 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnknm27798 for ; Mon, 14 Oct 2002 11:30:31 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnknm14067 for ; Mon, 14 Oct 2002 11:30:31 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnknm14060 for ; Mon, 14 Oct 2002 11:30:30 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA10201 for ; Mon, 14 Oct 2002 07:30:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9EBU1306447 for mpls@uu.net; Mon, 14 Oct 2002 07:30:01 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnknl17632 for ; Mon, 14 Oct 2002 11:28:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnknl22156 for ; Mon, 14 Oct 2002 11:28:13 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnknl19591 for ; Mon, 14 Oct 2002 11:28:13 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQnknl19574 for ; Mon, 14 Oct 2002 11:28:12 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14639; Mon, 14 Oct 2002 07:25:57 -0400 (EDT) Message-Id: <200210141125.HAA14639@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-ldp-mib-09.txt Date: Mon, 14 Oct 2002 07:25:57 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --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 : Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP) Author(s) : J. Cucchiara, H. Sjostrand, J. Luciani Filename : draft-ietf-mpls-ldp-mib-09.txt Pages : 101 Date : 2002-10-11 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-mib-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-ldp-mib-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-ldp-mib-09.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: <2002-10-11133832.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ldp-mib-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ldp-mib-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-11133832.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Oct 14 08:17:41 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16319 for ; Mon, 14 Oct 2002 08:17:41 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnknp14891 for ; Mon, 14 Oct 2002 12:19:47 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnknp13571; Mon, 14 Oct 2002 12:19:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQnknp07944 for mpls-outgoing; Mon, 14 Oct 2002 12:18:57 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnknp07939 for ; Mon, 14 Oct 2002 12:18:51 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnknp14067 for ; Mon, 14 Oct 2002 12:17:54 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnknp03069 for ; Mon, 14 Oct 2002 12:17:54 GMT Received: from blooper.utfors.se by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQnknp03048 for ; Mon, 14 Oct 2002 12:17:53 GMT Received: from utfors.se (nat-sto.utfors.se [212.73.0.237]) by blooper.utfors.se (8.12.6/8.12.6) with ESMTP id g9ECHbw1020871; Mon, 14 Oct 2002 14:17:37 +0200 (MEST) Message-ID: <3DAAB5D5.6080805@utfors.se> Date: Mon, 14 Oct 2002 14:17:25 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MPLS wg , Scott Bradner CC: George Swallow Subject: mpls wg document status - continued Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit All, there is a small web page, where I keep track of the state of the mpls wg documents. It gives just a hint on what is going on, though sometimes there are small notes that explains what is going on. http://62.119.0.68/~loa/MPLS_WG_Drafts.htm If you need more specific information you'll have to ASK. The latest development is that the fault tolerance and restart drafts < draft-ietf-mpls-bgp-mpls-restart-01.txt > < draft-ietf-mpls-ldp-restart-03.txt > < draft-ietf-mpls-ldp-ft-05.txt > has been submitted to the IESG for review and eventually publication. /Loa -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se From owner-mpls@UU.NET Mon Oct 14 08:27:24 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14800 for ; Mon, 14 Oct 2002 07:30:34 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnknm26857 for ; Mon, 14 Oct 2002 11:32:42 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnknm25295; Mon, 14 Oct 2002 11:32:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQnknm17866 for mpls-outgoing; Mon, 14 Oct 2002 11:31:34 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnknm17831 for ; Mon, 14 Oct 2002 11:31:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnknl17922 for ; Mon, 14 Oct 2002 11:29:47 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnknl13712 for ; Mon, 14 Oct 2002 11:29:47 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnknl13707 for ; Mon, 14 Oct 2002 11:29:46 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA10146 for ; Mon, 14 Oct 2002 07:29:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9EBT2L06395 for mpls@uu.net; Mon, 14 Oct 2002 07:29:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnknl17620 for ; Mon, 14 Oct 2002 11:28:20 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnknl03901 for ; Mon, 14 Oct 2002 11:28:17 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnknl19674 for ; Mon, 14 Oct 2002 11:28:17 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQnknl19656 for ; Mon, 14 Oct 2002 11:28:17 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14671; Mon, 14 Oct 2002 07:26:06 -0400 (EDT) Message-Id: <200210141126.HAA14671@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-lsr-mib-09.txt Date: Mon, 14 Oct 2002 07:26:06 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Multiprotocol Label Switching (MPLS) Label Switching Router (LSR)Management Information Base Author(s) : C. Srinivasan, A. Viswanathan, T. Nadeau Filename : draft-ietf-mpls-lsr-mib-09.txt Pages : 53 Date : 2002-10-11 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling a Multiprotocol Label Switching (MPLS) Label Switch Router (LSR). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-mib-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-lsr-mib-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-lsr-mib-09.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: <2002-10-11133913.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lsr-mib-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lsr-mib-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-11133913.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Oct 14 08:53:39 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17709 for ; Mon, 14 Oct 2002 08:53:39 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnknr01806 for ; Mon, 14 Oct 2002 12:55:46 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnknr00483; Mon, 14 Oct 2002 12:54:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQnknr10354 for mpls-outgoing; Mon, 14 Oct 2002 12:54:17 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnknr10345 for ; Mon, 14 Oct 2002 12:53:58 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnknr01500 for ; Mon, 14 Oct 2002 12:51:57 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnknr28865 for ; Mon, 14 Oct 2002 12:51:56 GMT Received: from parsmtp1.rd.francetelecom.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: parsmtp1.rd.francetelecom.com [194.167.105.13]) id QQnknr28856 for ; Mon, 14 Oct 2002 12:51:56 GMT Received: from lanmhs30.rd.francetelecom.fr ([10.193.21.61]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 14 Oct 2002 14:51:24 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: what's the status ofdraft-ietf-mpls-rsvp-lsp-fastreroute-00. txt Date: Mon, 14 Oct 2002 14:51:24 +0200 Message-ID: <1FB136FD10CE33409C882630E299F5BE1EDB86@lanmhs30.rd.francetelecom.fr> Thread-Topic: what's the status ofdraft-ietf-mpls-rsvp-lsp-fastreroute-00. txt Thread-Index: AcJxsGcFnAidmepAS6udx3WN2vjnMwBzdhtA From: "LE ROUX Jean-Louis FTRD/DAC/LAN" To: "Alia Atlas" , "Pan, Ping" Cc: "Shahram Davari" , "Thomas D. Nadeau" , X-OriginalArrivalTime: 14 Oct 2002 12:51:24.0897 (UTC) FILETIME=[677BCD10:01C27380] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA17709 Hi Alia You say that an advantage of the path specific method is less bandwidth reservation, thanks to detour merging. I'm not sure that detour merging always reduce bandwidth reservation. Indeed, when you merge many detours, the final detour protects many entities (links, nodes, SRLGs). and thus you reduce the possibility to share bandwith with other detours. Regards JL -----Message d'origine----- De : Alia Atlas [mailto:aatlas@avici.com] Envoye : samedi 12 octobre 2002 01:50 A : Pan, Ping Cc : Shahram Davari; 'Thomas D. Nadeau'; mpls@UU.NET Objet : Re: what's the status ofdraft-ietf-mpls-rsvp-lsp-fastreroute-00. txt Absolutely. The real requirement has been for inter-operability. It is important that what is out there be inter-operable and provide the functionality required. While I would not have chosen the trade-offs made for the path-specific method, there are advantages to it (earlier merging of detours so less bandwidth reserved) as well as disadvantages. Let those who plan to deploy it decide what they want. The draft says how to sit down and actually implement this feature. As Ping says, the code for it is rather complicated. One has to keep track of merging states, keeping state around even though the relevant interface is down, propagating or not propagating messages, etc. That said, much as Ping had the need to inter-operate with Cisco's bypass tunnels, we've had the requirement to inter-operate with both. Much like Ping, I sat down and figured out what would be possible and logical to do; we did so. That's why I did the draft suggesting how to deal in a network with both cases. Certainly, we've implemented both the Path-specific method as well as the sender-specific method, because of the requirement to interoperate. That's what standardization is about - the need to interoperate. We're keeping the old Class-type for FAST_REROUTE, without the include-any administrative-color, in the draft for the same reason. It describes what is done. Clearly the issue of the path-specific method is contentious. Are there others with opinions on this one? Perhaps we could/should put in some applicability words about the advantages and disadvantages of each approach to aid those deciding which to implement and/or deploy? Alia At 04:23 PM 10/11/2002 -0700, Pan, Ping wrote: >Hmmm... let me see who have done what in this space... > >Path-specific one-to-one method: > Juniper, several routers (cannot tell the names) > >Sender-specific one-to-one method: > Avici. ? > >Many-to-one method: > Cisco (both node and link protection), Juniper (link protection for now). > >We never said that every vendor has to support everything in the draft >right away right now. Since each method has its own merits, we let the >developers and carriers to decide. > >To talk about lack of consensus based on some people's comment is quite >amazing and disturbing. > >People have been asking why we glued two approaches together in the first >place. It looks like we are here for some rubber-stamping. But you guys >gotta ask yourself this: Cisco and Juniper are not the best friends in the >first place, so why in the world do they get together to do this? The >answer is that marketing people tried to kill each other, but didn't work. >:-) The customers seem to know more than we do on the advantages and >disadvantages of both methods... > >... It's been a slow Friday afternoon. Let me tell the whole story behind >this fast reroute crap: > >About one year ago, Der-Hwa Gan got one-to-one fast reroute working on >Juniper routers. The original idea came from Tony Li (while in Juniper) >and Der-Hwa. It was by far the most complex code in RSVP (you guys ought >to try it someday). It worked, and shipped. At the same time, Cisco got a >MPLS fast-reroute working as well. Both methods didn't work together. So >one day, Dave Cooper of Global Crossing came to us and told us that he >needed fast reroute to be compatible with each other, and didn't care how >to achieve it. > >I got the assignment, found a copy of draft-swallow, and started the >coding. When I thought it was done, I hooked up a Cisco router. Nothing >worked! There was no sender-specific stuff in sight. All I got was the >original Path messages tunneled through the bypass LSP. After talking to >George Swallow and JP directly over the phone, I was told that the new >code was still in beta, and has not been released yet. To me, being upset >was an understatement! But Cisco folks were kind enough to send a copy of >their new draft that actually told me how it supposes to work. As my >release date slipping fast, I had to rewrite the darn thing from scratch. > >More disturbing discovery was that since Cisco used Shared-explicit style, >while Juniper used Fixed-Filter, there was no way we could turn on both >Juniper and Cisco fast reroute to protect a single LSP. We could not ship >this fast-reroute feature this way to the customers. Around this time, >Alia from Avici told us that they had been reverse engineering Juniper >fast reroute, and had found several serious problems (including merging >rules and sender-specific vs. path-specific). So Der-Hwa and I started to >changed our code while changing the spec. That merging rule in the draft >was actually a line-by-line pseudo code at one point. It was kinda fun >thinking back. :-) > >When I was done with the facility fast reroute proposed by Cisco, there >were a lot of implementation issues. So I merged both drafts together, and >sent it to George and JP for correction along with a bunch of questions. >Avici folks came on board also. So we had several rounds of discussion and >disagreement, but came up a draft that developers knew how to implement. >That was what you have seen. > >The final outcome of the draft would allow both one-to-one and many-to-one >fast reroute to be turned on to protect a single LSP. Both sender-specific >and path-specific would work together too. That's what you have in Junos >5.4. The implementation of facility fast-reroute was limited to link >protection in Juniper so far, because that was what Dave Cooper wanted >anyway. Dave was kind enough that we actually interop'ed the facility >fast-reroute with Cisco developers (Rob and Carol) in Global Crossing lab >(this is bud to you, Brook!). > >The reason for telling you all this is that this draft came directly from >engineers with the help from providers. No vendor politics, no IETF >politics, it was a lot of pain and fun at the end! If you are a developer, >you can really implement this by reading spec. > >So before you question our motives again, please reconsider. > >Thanks! > >- Ping From owner-mpls@UU.NET Mon Oct 14 12:57:28 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26153 for ; Mon, 14 Oct 2002 12:57:27 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkoh12483 for ; Mon, 14 Oct 2002 16:59:34 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkoh11036; Mon, 14 Oct 2002 16:58:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkoh11109 for mpls-outgoing; Mon, 14 Oct 2002 16:58:38 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnkoh11104 for ; Mon, 14 Oct 2002 16:58:28 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnkoh13916 for ; Mon, 14 Oct 2002 16:57:48 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkoh15713 for ; Mon, 14 Oct 2002 16:57:48 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnkoh15705 for ; Mon, 14 Oct 2002 16:57:47 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA00162 for ; Mon, 14 Oct 2002 12:57:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9EGv2G23548 for mpls@uu.net; Mon, 14 Oct 2002 12:57:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnkoh10875 for ; Mon, 14 Oct 2002 16:55:27 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnkoh08467 for ; Mon, 14 Oct 2002 16:54:29 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkoh05218 for ; Mon, 14 Oct 2002 16:54:28 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQnkoh05210 for ; Mon, 14 Oct 2002 16:54:28 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25956; Mon, 14 Oct 2002 12:52:17 -0400 (EDT) Message-Id: <200210141652.MAA25956@ietf.org> To: IETF-Announce:; Cc: mpls@UU.NET From: The IESG SUBJECT: Last Call: Fault Tolerance for the Label Distribution Protocol (LDP) to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 14 Oct 2002 12:52:17 -0400 Sender: owner-mpls@UU.NET Precedence: bulk The IESG has received a request from the Multiprotocol Label Switching Working Group to consider Fault Tolerance for the Label Distribution Protocol (LDP) as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2002-10-28. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-ft-06.txt From owner-mpls@UU.NET Mon Oct 14 14:12:06 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28505 for ; Mon, 14 Oct 2002 14:12:06 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkom03744 for ; Mon, 14 Oct 2002 18:14:12 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkom02785; Mon, 14 Oct 2002 18:13:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkom19889 for mpls-outgoing; Mon, 14 Oct 2002 18:13:19 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnkom19882 for ; Mon, 14 Oct 2002 18:13:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkom17440 for ; Mon, 14 Oct 2002 18:12:12 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkom00891 for ; Mon, 14 Oct 2002 18:12:12 GMT Received: from gateway.ipinfusion.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.ipinfusion.com [65.223.109.2]) id QQnkom00857 for ; Mon, 14 Oct 2002 18:12:11 GMT Received: from YuanHong (dhcp123.ipinfusion.com [10.10.0.123] (may be forged)) by gateway.ipinfusion.com (8.11.6/8.11.6) with SMTP id g9EIB3W20954 for ; Mon, 14 Oct 2002 11:11:03 -0700 From: "Yuan Gu" To: "mpls group" Subject: RE: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt Date: Mon, 14 Oct 2002 11:11:25 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-4" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200210141126.HAA14655@ietf.org> Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi: I have two questions of MplsLSPID defined in this MIB: 1. It states in this MIB: (MplsLSPId): "A unique identifier within an MPLS network that is assigned to each LSP. This is assigned at the head end of the LSP and can be used by all LSRs to identify this LSP...For LSPs signaled using RSVP-TE, the LSP ID is defined as a 16-bit (2 byte) identifier used in the SENDER_TEMPLATE..." My question is: How does a head end LSR assign a "MPLS network unique" LSPID for a LSP in case the signaling is RSVP-TE? In RFC3209, it says: "The SENDER_TEMPLATE object together with the session object uniquely identifies an LSP tunnel." Does MplsLSPId definition conflict with RFC3209? 2. A "mplsXCLspId" object is defined in XC table of LSR MIB while MplsLSPId is only used for CR-LDP and RSVP-TE. My question is: In case of LDP, how do we populate mplsXCLspID's value? Thanks for your reply! Yuan IP Infusion -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Internet-Drafts@ietf.org Sent: Monday, October 14, 2002 4:26 AM To: IETF-Announce: Cc: mpls@UU.NET Subject: I-D ACTION:draft-ietf-mpls-tc-mib-04.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 : Definitions of Textual for Multiprotocol Label Switching (MPLS) Management Author(s) : T. Nadeau et al. Filename : draft-ietf-mpls-tc-mib-04.txt Pages : 18 Date : 2002-10-11 This memo describes Textual Conventions for use in definitions of management information for Multiprotocol Label Switching (MPLS) networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tc-mib-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-tc-mib-04.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-tc-mib-04.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. From owner-mpls@UU.NET Mon Oct 14 17:04:01 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02828 for ; Mon, 14 Oct 2002 17:04:00 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkoy17650 for ; Mon, 14 Oct 2002 21:06:07 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkoy16396; Mon, 14 Oct 2002 21:05:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkoy20499 for mpls-outgoing; Mon, 14 Oct 2002 21:05:04 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnkoy20399 for ; Mon, 14 Oct 2002 21:04:59 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnkoy27304 for ; Mon, 14 Oct 2002 21:04:21 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkoy15407 for ; Mon, 14 Oct 2002 21:04:20 GMT Received: from fcs-nt1.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fcs-nt1.futsoft.com [66.122.42.228]) id QQnkoy15382 for ; Mon, 14 Oct 2002 21:04:19 GMT Received: from sanjose.futsoft.com (unverified) by fcs-nt1.futsoft.com (Content Technologies SMTPRS 2.0.15) with SMTP id for ; Mon, 14 Oct 2002 14:02:37 -0700 Received: from MANIS (adsl-66-122-42-231.futsoft.com [66.122.42.231]) by sanjose.futsoft.com (8.9.3/8.8.7) with SMTP id MAA32234 for ; Mon, 14 Oct 2002 12:45:16 -0700 Reply-To: From: "Manikantan Srinivasan" To: Subject: Comments for draft-vijay-mpls-rsvpte-lspsubobject-00.txt Date: Mon, 14 Oct 2002 14:04:09 -0700 Message-Id: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Vijay draft-vijay-mpls-rsvpte-lspsubobject-00.txt, is a good contribution, which helps to create TE-LSPs with pre-existing LSP/tunnels along the intended LSP Path. I have the following comments to your draft. 1) The "L" bit in the LSP sub object must not be set at all times, since utilizing a tunnel, is a strict hop. Reason, When the new LSP is created, we would like to leverage the existing tunnel. Can you indicate in your draft that the L bit will not be set at all times? 2) In the draft we have "...The LSP sub object would be removed from the ERO by r1 and the Path message would be then sent to r3 provided the bandwidth constraints of the LSP L1 are not violated by admitting the new LSP. At r3, the node would recognize that R3 is adjacent to it and propagate the path message to it. " If the LSP sub object is removed by r1, how will r3, know that it is a valid LSP setup request received. I believe, the LSP sub object can be removed from the ERO List, only by the egress node in the tunnel. Using your LSR topology example, I believe, r1, should pass the LSP sub object when it forwards the LSP setup request (Path Message) to r2. r2, can identify that is part of an existing tunnel, which is mentioned in the ERO object - "LSP sub object" and forward it towards the tunnel's destination. At r3, the ERO will be removed by r3 (r3 knows it is part of the tunnel, and it is the end of the tunnel) and then r3 can forward the path message to R3. 3) Can you explain why do we need both TunnelID and LSPID in the LSP sub object? The Ingress, Egress Addresses and the TunnelID is sufficient to uniquely identify a tunnel. best regards mani ==================================== Manikantan (Mani) Srinivasan Future Communications Software 4300 Stevens Creek Blvd, Suite 187, San Jose, CA, 95129. Phone : 408 243 3887 x 107 Fax : 408 243 0772 email : manis@futsoft.com ------------------------------------ Please do visit us at: Next Generation Networks, Marriott Copley Place, Boston, Massachusetts, USA. Booth No. 126 October 14-18, 2002. ==================================== From owner-mpls@UU.NET Mon Oct 14 17:19:05 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03093 for ; Mon, 14 Oct 2002 17:19:05 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkoz17811 for ; Mon, 14 Oct 2002 21:21:07 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkoz16432; Mon, 14 Oct 2002 21:20:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkoz23000 for mpls-outgoing; Mon, 14 Oct 2002 21:20:01 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnkoz22987 for ; Mon, 14 Oct 2002 21:19:55 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnkoz25914 for ; Mon, 14 Oct 2002 21:18:20 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkoz27019 for ; Mon, 14 Oct 2002 21:18:19 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQnkoz27005 for ; Mon, 14 Oct 2002 21:18:18 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA02503 for ; Mon, 14 Oct 2002 17:17:09 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA04844 for ; Mon, 14 Oct 2002 17:17:03 -0400 (EDT) Message-ID: <3DAB3449.3070308@marconi.com> Date: Mon, 14 Oct 2002 17:16:57 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: IETF MPLS List Subject: Re: Comments for draft-vijay-mpls-rsvpte-lspsubobject-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Manikantan Srinivasan wrote: > > 3) Can you explain why do we need both TunnelID and LSPID in the LSP > sub object? The Ingress, Egress Addresses and the TunnelID is > sufficient to uniquely identify a tunnel. It is not sufficient. In order to uniquely identify an RSVP-TE LSP, you need no fewer than five values: Tunnel endpoint (egress) address (in SESSION object) Tunnel ID (in SESSION object) Extended Tunnel ID (in SESSION object) Sender (ingress) address (in SENDER_TEMPLATE/FILTER_SPEC object) LSP ID (in SENDER_TEMPLATE/FILTER_SPEC object) Any implementation that makes assumptions about these values is broken. The existing MPLS MIBs (LSR and TE) do not contain enough information to cover all of RSVP-TE's capabilities. For instance, the extended tunnel ID does not have to match the sender address (it could also be zero). And one tunnel (defined by the three values in the SESSION object) may contain multiple LSPs, each with its own separate LSP ID. If you don't permit one tunnel to have separate LSPs, then you effectively eliminate SE style and all of the useful features that it offers. You also drasticly reduce the maximum number of LSPs that can be created between two endpoints. -- David From owner-mpls@UU.NET Mon Oct 14 17:54:37 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03615 for ; Mon, 14 Oct 2002 17:54:33 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkpb09727 for ; Mon, 14 Oct 2002 21:56:38 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkpb08028; Mon, 14 Oct 2002 21:55:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkpb25117 for mpls-outgoing; Mon, 14 Oct 2002 21:55:33 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnkpb25112 for ; Mon, 14 Oct 2002 21:55:29 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkpb25196 for ; Mon, 14 Oct 2002 21:54:55 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkpb07442 for ; Mon, 14 Oct 2002 21:54:54 GMT Received: from fcs-nt1.futsoft.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fcs-nt1.futsoft.com [66.122.42.228]) id QQnkpb07437 for ; Mon, 14 Oct 2002 21:54:53 GMT Received: from sanjose.futsoft.com (unverified) by fcs-nt1.futsoft.com (Content Technologies SMTPRS 2.0.15) with SMTP id ; Mon, 14 Oct 2002 14:53:06 -0700 Received: from MANIS (adsl-66-122-42-231.futsoft.com [66.122.42.231]) by sanjose.futsoft.com (8.9.3/8.8.7) with SMTP id NAA32605; Mon, 14 Oct 2002 13:35:42 -0700 Reply-To: From: "Manikantan Srinivasan" To: "David Charlap" , "IETF MPLS List" Subject: RE: Comments for draft-vijay-mpls-rsvpte-lspsubobject-00.txt Date: Mon, 14 Oct 2002 14:54:35 -0700 Message-Id: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3DAB3449.3070308@marconi.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dear David Thanks for your mail. I used the Tunnel/LSP interchanged and hence I used Tunnel ID equal with LSP ID. I believe, between an ingress and an egress, a LSP/Tunnel can be uniquely identified and it is called as LSPID/Tunnel ID. From the RSVP-TE definitions, I agree, a Tunnel can contain several LSP-IDs. A Tunnel ID is different from LSP IDs, and hence we need both Tunnel ID and LSP ID to uniquely identify the LSP. Regarding Extended Tunnel ID (in SESSION object), I agree from your clarification, that this need not be the ingress address. Might be zero. But if this is non-zero, can we assume that it will be sender IP Address? I assume that the extended Tunnel ID is either zero or the sender IP Address. If the extended tunnel id is same as sender IP address, then we don't require this right? Does the LSP Sub object in draft-vijay-mpls-rsvpte-lspsubobject-00.txt be extended to contain the 5 tuples you have mentioned? As you rightly said, the current MIBs does not have the support for the 5 tuples to determine a unique LSP in RSVP-TE context. Do you think it as worthwhile to add these in the MIB for total solution? best regards mani > -----Original Message----- > From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of David > Charlap > Sent: Monday, October 14, 2002 2:17 PM > To: IETF MPLS List > Subject: Re: Comments for draft-vijay-mpls-rsvpte-lspsubobject-00.txt > > > Manikantan Srinivasan wrote: > > > > 3) Can you explain why do we need both TunnelID and LSPID in the LSP > > sub object? The Ingress, Egress Addresses and the TunnelID is > > sufficient to uniquely identify a tunnel. > > It is not sufficient. In order to uniquely identify an RSVP-TE LSP, you > need no fewer than five values: > Tunnel endpoint (egress) address (in SESSION object) > Tunnel ID (in SESSION object) > Extended Tunnel ID (in SESSION object) > Sender (ingress) address (in SENDER_TEMPLATE/FILTER_SPEC object) > LSP ID (in SENDER_TEMPLATE/FILTER_SPEC object) > > Any implementation that makes assumptions about these values is broken. > The existing MPLS MIBs (LSR and TE) do not contain enough information > to cover all of RSVP-TE's capabilities. For instance, the extended > tunnel ID does not have to match the sender address (it could also be > zero). And one tunnel (defined by the three values in the SESSION > object) may contain multiple LSPs, each with its own separate LSP ID. > > If you don't permit one tunnel to have separate LSPs, then you > effectively eliminate SE style and all of the useful features that it > offers. You also drasticly reduce the maximum number of LSPs that can > be created between two endpoints. > > -- David > > From owner-mpls@UU.NET Mon Oct 14 18:33:53 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04747 for ; Mon, 14 Oct 2002 18:33:53 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkpe19601 for ; Mon, 14 Oct 2002 22:36:00 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkpe18191; Mon, 14 Oct 2002 22:35:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkpe14371 for mpls-outgoing; Mon, 14 Oct 2002 22:34:28 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnkpe14366 for ; Mon, 14 Oct 2002 22:34:25 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkpe00758 for ; Mon, 14 Oct 2002 22:33:01 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkpe01071 for ; Mon, 14 Oct 2002 22:33:01 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQnkpe01057 for ; Mon, 14 Oct 2002 22:33:00 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA04178 for ; Mon, 14 Oct 2002 18:32:58 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA12108 for ; Mon, 14 Oct 2002 18:33:00 -0400 (EDT) Message-ID: <3DAB4615.2020003@marconi.com> Date: Mon, 14 Oct 2002 18:32:53 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: IETF MPLS List Subject: Re: Comments for draft-vijay-mpls-rsvpte-lspsubobject-00.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Manikantan Srinivasan wrote: > > Regarding Extended Tunnel ID (in SESSION object), I agree from your > clarification, that this need not be the ingress address. Might be zero. > But if this is non-zero, can we assume that it will be sender IP Address? According to RSVP (RFC 2205) and RSVP-TE (RFC 3209), you can't. The extended tunnel ID may be any value that uniquely identifies the sender. By convention, the sender's IP address is used, because that's the easiest way to guarantee uniqueness. In actual practice, I think it's safe to assume that non-zero values will match an IP address on the sender node. I don't know if it's safe to assume that it will match the address used in the SENDER_TEMPLATE object, however. > Does the LSP Sub object in draft-vijay-mpls-rsvpte-lspsubobject-00.txt > be extended to contain the 5 tuples you have mentioned? I haven't read the draft very thoroughly yet, but I think extended tunnel ID should be present in the LSP subobject. Otherwise the draft will impose new restrictions on the rest of RSVP-TE. > As you rightly said, the current MIBs does not have the support for > the 5 tuples to determine a unique LSP in RSVP-TE context. Do you > think it as worthwhile to add these in the MIB for total solution? This has been discussed in the working group on many occasions in the past. The group's consensus is that nobody (or almost nobody) will want to use and extended tunnel ID that differs from the sender address, so there's no need to accommodate this feature in the MIB. I disagree, but mine is a minority opinion. I doubt anybody will be changing the MIB at this point, especially since it's a key field that would have to change. If you think this is an important thing to have in the MIB, I think the best thing to do is to implement a private MIB in addition to the standard one. Your private one can accommodate the extra key field. -- David From owner-mpls@UU.NET Mon Oct 14 19:19:55 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05329 for ; Mon, 14 Oct 2002 19:19:55 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkph10530 for ; Mon, 14 Oct 2002 23:22:03 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkph09485; Mon, 14 Oct 2002 23:21:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkph04565 for mpls-outgoing; Mon, 14 Oct 2002 23:21:06 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnkph04489 for ; Mon, 14 Oct 2002 23:20:53 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnkph16026 for ; Mon, 14 Oct 2002 23:19:24 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkph06049 for ; Mon, 14 Oct 2002 23:19:24 GMT Received: from fcs-nt1.futsoft.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fcs-nt1.futsoft.com [66.122.42.228]) id QQnkph05997 for ; Mon, 14 Oct 2002 23:19:23 GMT Received: from sanjose.futsoft.com (unverified) by fcs-nt1.futsoft.com (Content Technologies SMTPRS 2.0.15) with SMTP id ; Mon, 14 Oct 2002 16:17:41 -0700 Received: from MANIS (adsl-66-122-42-231.futsoft.com [66.122.42.231]) by sanjose.futsoft.com (8.9.3/8.8.7) with SMTP id PAA00699; Mon, 14 Oct 2002 15:00:17 -0700 Reply-To: From: "Manikantan Srinivasan" To: "David Charlap" , "IETF MPLS List" Subject: RE: Comments for draft-vijay-mpls-rsvpte-lspsubobject-00.txt Date: Mon, 14 Oct 2002 16:19:10 -0700 Message-Id: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3DAB4615.2020003@marconi.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dear David Thanks for your replies. Yes, an enterprise MIB is a good suggestion to use if the Extended tunnel id is different from the Sender's IP Address. and I would take that way. Thanks again. regards mani > -----Original Message----- > From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of David > Charlap > Sent: Monday, October 14, 2002 3:33 PM > To: IETF MPLS List > Subject: Re: Comments for draft-vijay-mpls-rsvpte-lspsubobject-00.txt > > > Manikantan Srinivasan wrote: > > > > Regarding Extended Tunnel ID (in SESSION object), I agree from your > > clarification, that this need not be the ingress address. Might be zero. > > But if this is non-zero, can we assume that it will be sender > IP Address? > > According to RSVP (RFC 2205) and RSVP-TE (RFC 3209), you can't. The > extended tunnel ID may be any value that uniquely identifies the sender. > By convention, the sender's IP address is used, because that's the > easiest way to guarantee uniqueness. > > In actual practice, I think it's safe to assume that non-zero values > will match an IP address on the sender node. I don't know if it's safe > to assume that it will match the address used in the SENDER_TEMPLATE > object, however. > > > Does the LSP Sub object in draft-vijay-mpls-rsvpte-lspsubobject-00.txt > > be extended to contain the 5 tuples you have mentioned? > > I haven't read the draft very thoroughly yet, but I think extended > tunnel ID should be present in the LSP subobject. Otherwise the draft > will impose new restrictions on the rest of RSVP-TE. > > > As you rightly said, the current MIBs does not have the support for > > the 5 tuples to determine a unique LSP in RSVP-TE context. Do you > > think it as worthwhile to add these in the MIB for total solution? > > This has been discussed in the working group on many occasions in > the past. > > The group's consensus is that nobody (or almost nobody) will want to use > and extended tunnel ID that differs from the sender address, so there's > no need to accommodate this feature in the MIB. > > I disagree, but mine is a minority opinion. I doubt anybody will be > changing the MIB at this point, especially since it's a key field that > would have to change. > > If you think this is an important thing to have in the MIB, I think the > best thing to do is to implement a private MIB in addition to the > standard one. Your private one can accommodate the extra key field. > > -- David > From owner-mpls@UU.NET Tue Oct 15 03:20:13 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22689 for ; Tue, 15 Oct 2002 03:20:12 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkqn00160 for ; Tue, 15 Oct 2002 07:22:19 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkqn28771; Tue, 15 Oct 2002 07:21:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkqn19957 for mpls-outgoing; Tue, 15 Oct 2002 07:21:14 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnkqn19929 for ; Tue, 15 Oct 2002 07:21:12 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkqn19893 for ; Tue, 15 Oct 2002 07:21:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkqn10309 for ; Tue, 15 Oct 2002 07:21:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnkqn10284 for ; Tue, 15 Oct 2002 07:21:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id DAA19088 for ; Tue, 15 Oct 2002 03:21:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9F7L1L05899 for mpls@uu.net; Tue, 15 Oct 2002 03:21:01 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnkqn19806 for ; Tue, 15 Oct 2002 07:20:07 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnkqn01083 for ; Tue, 15 Oct 2002 07:19:37 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkqn26101 for ; Tue, 15 Oct 2002 07:19:37 GMT Received: from ganesh.ctd.hctech.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQnkqn26083 for ; Tue, 15 Oct 2002 07:19:35 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id <48ZB6XP9>; Tue, 15 Oct 2002 12:49:32 +0530 Message-ID: <55E277B99171E041ABF5F4B1C6DDCA06A57614@haritha.hclt.com> From: "Vijayanand C - CTD, Chennai." To: manis@futsoft.com Cc: mpls@UU.NET, David Charlap Subject: RE: Comments for draft-vijay-mpls-rsvpte-lspsubobject-00.txt Date: Tue, 15 Oct 2002 12:51:47 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Mani, Thanks for your comments. 1) Regarding the L Bit - This could be set. For instance, if the previous node of the tunnel ingress is not mentioned in the ERO then the node before that can still route the path message to the tunnel ingress looking at the tunnel ingress address if the L bit is set. 2) Regarding the path message sent over the tunnel- I would say that the path message would be sent over the existing tunnel as if it were an interface, transparent to the intermediate nodes.It would not create path state in the intermediate nodes. I did nt mention it explicitly though. 3) Reg the parameters to identify the tunnel , there was some confusion on the need for a 5 th parameter. But the LSPID is definitly needed as David pointed out. Some discussion has happened regarding the significance of the extended tunnel ID. I thought it would not be necessary since it seemed that extended tunnel ID would be either zero or sender IP address from the discussions in the mailing list. But Davids' argument may need to be incorporated from the robustness angle. Regards, Vijay -----Original Message----- From: Manikantan Srinivasan [mailto:manis@futsoft.com] Sent: Tuesday, October 15, 2002 2:34 AM To: mpls@UU.NET Subject: Comments for draft-vijay-mpls-rsvpte-lspsubobject-00.txt Hello Vijay draft-vijay-mpls-rsvpte-lspsubobject-00.txt, is a good contribution, which helps to create TE-LSPs with pre-existing LSP/tunnels along the intended LSP Path. I have the following comments to your draft. 1) The "L" bit in the LSP sub object must not be set at all times, since utilizing a tunnel, is a strict hop. Reason, When the new LSP is created, we would like to leverage the existing tunnel. Can you indicate in your draft that the L bit will not be set at all times? 2) In the draft we have "...The LSP sub object would be removed from the ERO by r1 and the Path message would be then sent to r3 provided the bandwidth constraints of the LSP L1 are not violated by admitting the new LSP. At r3, the node would recognize that R3 is adjacent to it and propagate the path message to it. " If the LSP sub object is removed by r1, how will r3, know that it is a valid LSP setup request received. I believe, the LSP sub object can be removed from the ERO List, only by the egress node in the tunnel. Using your LSR topology example, I believe, r1, should pass the LSP sub object when it forwards the LSP setup request (Path Message) to r2. r2, can identify that is part of an existing tunnel, which is mentioned in the ERO object - "LSP sub object" and forward it towards the tunnel's destination. At r3, the ERO will be removed by r3 (r3 knows it is part of the tunnel, and it is the end of the tunnel) and then r3 can forward the path message to R3. 3) Can you explain why do we need both TunnelID and LSPID in the LSP sub object? The Ingress, Egress Addresses and the TunnelID is sufficient to uniquely identify a tunnel. best regards mani ==================================== Manikantan (Mani) Srinivasan Future Communications Software 4300 Stevens Creek Blvd, Suite 187, San Jose, CA, 95129. Phone : 408 243 3887 x 107 Fax : 408 243 0772 email : manis@futsoft.com ------------------------------------ Please do visit us at: Next Generation Networks, Marriott Copley Place, Boston, Massachusetts, USA. Booth No. 126 October 14-18, 2002. ==================================== From owner-mpls@UU.NET Tue Oct 15 05:12:48 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24317 for ; Tue, 15 Oct 2002 05:12:47 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkqu08365 for ; Tue, 15 Oct 2002 09:14:54 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkqu07236; Tue, 15 Oct 2002 09:14:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkqu00862 for mpls-outgoing; Tue, 15 Oct 2002 09:13:55 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnkqu00855 for ; Tue, 15 Oct 2002 09:13:45 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnkqu07856 for ; Tue, 15 Oct 2002 09:13:10 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkqu29308 for ; Tue, 15 Oct 2002 09:13:09 GMT Received: from miles.dataconnection.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.dataconnection.com [192.91.191.8]) id QQnkqu29297 for ; Tue, 15 Oct 2002 09:13:09 GMT Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2656.59) id <44DDRMTQ>; Tue, 15 Oct 2002 10:12:06 +0100 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F80109C96E@baker.datcon.co.uk> From: Edward Harrison To: Cisco - Thomas Nadeau , "'jcucchiara@crescentnetworks.com'" , Parama - Cheenu Srinivasan , "'arun@force10networks.com'" , "'hans@ipunplugged.com'" Cc: mpls@UU.NET Subject: RE: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt Date: Tue, 15 Oct 2002 10:11:03 +0100 Deferred-Delivery: Tue, 15 Oct 2002 10:11:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk It's good to see the new revisions of the MPLS MIBs coming out. One comment, though - the text describing MplsTunnelAffinity says that it is used for Include-any, Include-all and Exclude-all constraints. I think it should say "Exclude-any" rather than "Exclude-all". I believe this has stemmed from a bug in the MPLS TE-MIB, which the authors (or Tom at least!) said they were going to fix in the next revision. [As a reminder, section 4.7.2 of RFC 3209 shows the vectors describing resource affinities are Exclude-any, Include-any and Include-all, however draft-ietf-mpls-te-mib-08.txt includes the objects mplsTunnelExcludeAllAffinity, mplsTunnelIncludeAllAffinity and mplsTunnelIncludeAnyAffinity.] Regards, Ed -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: 14 October 2002 12:26 To: IETF-Announce Cc: mpls@UU.NET Subject: I-D ACTION:draft-ietf-mpls-tc-mib-04.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 : Definitions of Textual for Multiprotocol Label Switching (MPLS) Management Author(s) : T. Nadeau et al. Filename : draft-ietf-mpls-tc-mib-04.txt Pages : 18 Date : 2002-10-11 This memo describes Textual Conventions for use in definitions of management information for Multiprotocol Label Switching (MPLS) networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tc-mib-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-tc-mib-04.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-tc-mib-04.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. From owner-mpls@UU.NET Tue Oct 15 07:37:30 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26935 for ; Tue, 15 Oct 2002 07:37:30 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkre17925 for ; Tue, 15 Oct 2002 11:39:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkre17257; Tue, 15 Oct 2002 11:39:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkre13499 for mpls-outgoing; Tue, 15 Oct 2002 11:38:33 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnkre13494 for ; Tue, 15 Oct 2002 11:38:24 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkre09666 for ; Tue, 15 Oct 2002 11:35:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkre12403 for ; Tue, 15 Oct 2002 11:35:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnkre12373 for ; Tue, 15 Oct 2002 11:35:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA26717 for ; Tue, 15 Oct 2002 07:35:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9FBZ1318548 for mpls@uu.net; Tue, 15 Oct 2002 07:35:01 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnkre13246 for ; Tue, 15 Oct 2002 11:34:31 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkre25058 for ; Tue, 15 Oct 2002 11:32:54 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkre09193 for ; Tue, 15 Oct 2002 11:32:53 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQnkre09185 for ; Tue, 15 Oct 2002 11:32:53 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26448; Tue, 15 Oct 2002 07:30:37 -0400 (EDT) Message-Id: <200210151130.HAA26448@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; CC: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-farrel-mpls-ldp-restart-applic-01.txt Date: Tue, 15 Oct 2002 07:30:37 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Applicability Statement for Restart Mechanisms for the Label Distribution Protocol Author(s) : A. Farrel Filename : draft-farrel-mpls-ldp-restart-applic-01.txt Pages : 14 Date : 2002-10-14 Multiprotocol Label Switching (MPLS) systems will be used in core networks where system downtime must be kept to a minimum. Similarly, where MPLS is at the network edges (for example, in Provider Edge routers) system downtime must also be kept as small as possible. Many MPLS Label Switching Routers (LSRs) may, therefore, exploit Fault Tolerant (FT) hardware or software to provide high availability of the core networks. The details of how FT is achieved for the various components of an FT LSR, including the switching hardware and the TCP stack are implementation specific. How the software module itself chooses to implement FT for the state created by the Label Distribution Protocol (LDP) is also implementation specific but there are several issues in the LDP specification in RFC 3036 'LDP Specification' that make it difficult to implement an FT LSR using the LDP protocols without some extensions to those protocols. Proposals have been made in 'Fault Tolerance for the Label Distribution Protocol (LDP)' [LDP-FT] and 'Graceful Restart Mechanism for LDP' [LDP-RESTART] to address these issues. This document gives guidance on when it is advisable to implement some form of LDP restart mechanism and which approach might be more suitable. The issues and extensions described here are equally applicable to RFC 3212, 'Constraint-Based LSP Setup Using LDP' (CR-LDP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-farrel-mpls-ldp-restart-applic-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-farrel-mpls-ldp-restart-applic-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-farrel-mpls-ldp-restart-applic-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: <2002-10-14142142.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-farrel-mpls-ldp-restart-applic-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-farrel-mpls-ldp-restart-applic-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-14142142.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Oct 15 07:39:36 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26974 for ; Tue, 15 Oct 2002 07:39:36 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkre21748 for ; Tue, 15 Oct 2002 11:41:41 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkre20925; Tue, 15 Oct 2002 11:41:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkre13551 for mpls-outgoing; Tue, 15 Oct 2002 11:40:55 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnkre13539 for ; Tue, 15 Oct 2002 11:40:40 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkre25780 for ; Tue, 15 Oct 2002 11:39:04 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkre17655 for ; Tue, 15 Oct 2002 11:39:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnkre17635 for ; Tue, 15 Oct 2002 11:39:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA26854 for ; Tue, 15 Oct 2002 07:39:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9FBd2818730 for mpls@uu.net; Tue, 15 Oct 2002 07:39:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnkre13478 for ; Tue, 15 Oct 2002 11:37:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkre08028 for ; Tue, 15 Oct 2002 11:33:44 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkre10659 for ; Tue, 15 Oct 2002 11:33:44 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQnkre10646 for ; Tue, 15 Oct 2002 11:33:44 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26667; Tue, 15 Oct 2002 07:31:32 -0400 (EDT) Message-Id: <200210151131.HAA26667@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-bgp-mpls-restart-02.txt Date: Tue, 15 Oct 2002 07:31:32 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --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 : Graceful Restart Mechanism for BGP with MPLS Author(s) : Y. Rekhter, R. Aggarwal Filename : draft-ietf-mpls-bgp-mpls-restart-02.txt Pages : 11 Date : 2002-10-14 A mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart is described in 'Graceful Restart Mechanism for BGP' (see [1]). This document extends this mechanism to also minimize the negative effects on MPLS forwarding caused by the Label Switching Router's (LSR's) control plane restart, and specifically by the restart of its BGP component when BGP is used to carry MPLS labels and the LSR is capable of preserving the MPLS forwarding state across the restart. The mechanism described in this document is agnostic with respect to the types of the addresses carried in the BGP Network Layer Reachability Information (NLRI) field. As such it works in conjunction with any of the address famililies that could be carried in BGP (e.g., IPv4, IPv6, etc...) The mechanism described in this document is applicable to all LSRs, both those with the ability to preserve their forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanism described in this document). Supporting (a subset of) the mechanism described here by the LSRs that can not preserve their MPLS forwarding state across the restart would not reduce the negative impact on MPLS traffic caused by their control plane restart, but it would minimize the impact if their neighbor(s) are capable of preserving the forwarding state across the restart of their control plane and implement the mechanism described here. The mechanism makes minimalistic assumptions on what has to be preserved across restart - the mechanism assumes that only the actual MPLS forwarding state has to be preserved; the mechanism does not require any of the BGP-related state to be preserved across the restart. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-bgp-mpls-restart-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-bgp-mpls-restart-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-bgp-mpls-restart-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-14142336.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-bgp-mpls-restart-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-bgp-mpls-restart-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-14142336.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Oct 15 07:43:40 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27098 for ; Tue, 15 Oct 2002 07:43:39 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkrf02275 for ; Tue, 15 Oct 2002 11:45:43 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkre25336; Tue, 15 Oct 2002 11:42:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkre13750 for mpls-outgoing; Tue, 15 Oct 2002 11:42:20 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnkre13721 for ; Tue, 15 Oct 2002 11:41:56 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkre05390 for ; Tue, 15 Oct 2002 11:39:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkre17636 for ; Tue, 15 Oct 2002 11:39:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnkre17624 for ; Tue, 15 Oct 2002 11:39:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA26849 for ; Tue, 15 Oct 2002 07:39:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9FBd2g18723 for mpls@uu.net; Tue, 15 Oct 2002 07:39:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnkre13477 for ; Tue, 15 Oct 2002 11:37:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkre08162 for ; Tue, 15 Oct 2002 11:33:49 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkre10724 for ; Tue, 15 Oct 2002 11:33:48 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQnkre10715 for ; Tue, 15 Oct 2002 11:33:48 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26684; Tue, 15 Oct 2002 07:31:37 -0400 (EDT) Message-Id: <200210151131.HAA26684@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-ldp-restart-06.txt Date: Tue, 15 Oct 2002 07:31:37 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --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 : Graceful Restart Mechanism for LDP Author(s) : M. Leelanivas, Y. Rekhter, R. Aggarwal Filename : draft-ietf-mpls-ldp-restart-06.txt Pages : 13 Date : 2002-10-14 This document describes a mechanism that helps to minimize the negative effects on MPLS traffic caused by Label Switching Router's (LSR's) control plane restart, and specifically by the restart of its Label Distribution Protocol (LDP) component, on LSRs that are capable of preserving the MPLS forwarding component across the restart. The mechanism described in this document is applicable to all LSRs, both those with the ability to preserve forwarding state during LDP restart and those without (although the latter need to implement only a subset of the mechanism described in this document). Supporting (a subset of) the mechanism described here by the LSRs that can not preserve their MPLS forwarding state across the restart would not reduce the negative impact on MPLS traffic caused by their control plane restart, but it would minimize the impact if their neighbor(s) are capable of preserving the forwarding state across the restart of their control plane and implement the mechanism described here. The mechanism makes minimalistic assumptions on what has to be preserved across restart - the mechanism assumes that only the actual MPLS forwarding state has to be preserved; the mechanism does not require any of the LDP-related state to be preserved across the restart. The procedures described in this document apply to downstream unsolicited label distribution. Extending these procedures to downstream on demand label distribution is for further study. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-restart-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-ldp-restart-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-ldp-restart-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-14142345.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ldp-restart-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ldp-restart-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-14142345.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Oct 15 09:40:27 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01287 for ; Tue, 15 Oct 2002 09:40:26 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkrm25068 for ; Tue, 15 Oct 2002 13:42:33 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkrm23681; Tue, 15 Oct 2002 13:41:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkrm25634 for mpls-outgoing; Tue, 15 Oct 2002 13:41:31 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnkrm25629 for ; Tue, 15 Oct 2002 13:41:30 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkrm01873 for ; Tue, 15 Oct 2002 13:39:35 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkrm21106 for ; Tue, 15 Oct 2002 13:39:35 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnkrm21097 for ; Tue, 15 Oct 2002 13:39:34 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA02449 for ; Tue, 15 Oct 2002 09:39:34 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9FDdYM26197 for mpls@uu.net; Tue, 15 Oct 2002 09:39:34 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnkob15815 for ; Mon, 14 Oct 2002 15:27:45 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkob28134 for ; Mon, 14 Oct 2002 15:24:50 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkob15402 for ; Mon, 14 Oct 2002 15:24:50 GMT Received: from gorilla.mchh.siemens.de by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gorilla.mchh.siemens.de [194.138.158.18]) id QQnkob15380 for ; Mon, 14 Oct 2002 15:24:49 GMT Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA15044 for ; Mon, 14 Oct 2002 17:06:18 +0200 (MET DST) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA09260 for ; Mon, 14 Oct 2002 17:06:18 +0200 (MET DST) Received: by MCHH273E with Internet Mail Service (5.5.2656.59) id <4RYKJRQX>; Mon, 14 Oct 2002 17:06:03 +0200 Message-ID: From: Hummel Heinrich To: mpls@UU.NET Subject: Version 2 of draft-hummel-mpls-hierarchical-lsp-02.txt Date: Mon, 14 Oct 2002 17:06:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hello, I submitted draft version 2 on "Hierarchical LSP". New in this version is: 1) I changed its basis: from LDP/CR-LDP to RSVP-TE 2) I believe that H-LSPs and Non H-LSPs can be treated in a generic way, i.e. in a way which comprises both. 3) I referred to the "Differentiated Routing" discussion for IP Forwarding. The benefit for MPLS: A one single-octet sized source routing info, called DiffRout Codepoint, may guide the LSP-establishment message in accordance with a (virtual) DRCP-specific Smallest-Size- Tree graph. This enables the establishment of p2p, p2mp, mp2p, mp2mp -LSPs sensitive to all the constraints which casted that SST-graph: virtual carrier selection, QoS/SLA/traffic type, traffic balancing/overflow, transit versus non-transit traffic. Your comments are gratefully appreciated. Heinrich Hummel From owner-mpls@UU.NET Tue Oct 15 09:46:58 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01471 for ; Tue, 15 Oct 2002 09:46:58 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkrn15436 for ; Tue, 15 Oct 2002 13:49:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkrn13999; Tue, 15 Oct 2002 13:48:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkrn26381 for mpls-outgoing; Tue, 15 Oct 2002 13:47:52 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnkrn26376 for ; Tue, 15 Oct 2002 13:47:49 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkrm08448 for ; Tue, 15 Oct 2002 13:40:06 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkrm21686 for ; Tue, 15 Oct 2002 13:40:06 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnkrm21673 for ; Tue, 15 Oct 2002 13:40:05 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA02501 for ; Tue, 15 Oct 2002 09:40:05 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9FDe5926247 for mpls@uu.net; Tue, 15 Oct 2002 09:40:05 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnkqq09579 for ; Tue, 15 Oct 2002 08:10:55 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnkqq24750 for ; Tue, 15 Oct 2002 08:10:51 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkqq14642 for ; Tue, 15 Oct 2002 08:10:50 GMT Received: from webmail2.rediffmail.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: webmail2.rediffmail.com [202.54.124.147] (may be forged)) id QQnkqq14596 for ; Tue, 15 Oct 2002 08:10:48 GMT Received: (qmail 6166 invoked by uid 510); 15 Oct 2002 08:15:52 -0000 Date: 15 Oct 2002 08:15:52 -0000 Message-ID: <20021015081552.6165.qmail@webmail2.rediffmail.com> Received: from unknown (203.200.20.226) by rediffmail.com via HTTP; 15 Oct 2002 08:15:52 -0000 MIME-Version: 1.0 From: "Hemant Khare" Reply-To: "Hemant Khare" To: rsvp@isi.edu Cc: mpls@UU.NET Content-type: text/plain; format=flowed Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hi, I've a question. In RFC 2205 (RSVP)it is given that ERROR_SPEC object carries following information, 1. Error code 2. Error value 3. some flags 4. The IP address of the node in which the error was detected Purpose of 1,2,3 are clear to me. But purpose of carrying IP address of node which detected the error is not clear. When the intented node receives the error message (which carries ERROR_SPEC), what he'll do using this IP address? There must be some specific purpose, i think. Please let me know ur thoughts on this Ragards and TIA -hemanth __________________________________________________________ Give your Company an email address like ravi @ ravi-exports.com. Sign up for Rediffmail Pro today! Know more. http://www.rediffmailpro.com/signup/ From owner-mpls@UU.NET Tue Oct 15 10:28:01 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03252 for ; Tue, 15 Oct 2002 10:28:00 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkrq11474 for ; Tue, 15 Oct 2002 14:30:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkrp10191; Tue, 15 Oct 2002 14:29:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkrp16291 for mpls-outgoing; Tue, 15 Oct 2002 14:28:56 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnkrp16281 for ; Tue, 15 Oct 2002 14:28:49 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnkrp16093 for ; Tue, 15 Oct 2002 14:28:39 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkrp18650 for ; Tue, 15 Oct 2002 14:28:38 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnkrp18644 for ; Tue, 15 Oct 2002 14:28:37 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA05766 for ; Tue, 15 Oct 2002 10:28:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9FES2c01075 for mpls@uu.net; Tue, 15 Oct 2002 10:28:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnkrp16226 for ; Tue, 15 Oct 2002 14:26:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnkrp13400 for ; Tue, 15 Oct 2002 14:23:11 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkrp15315 for ; Tue, 15 Oct 2002 14:23:11 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnkrp15309 for ; Tue, 15 Oct 2002 14:23:11 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9FEM1f3002684; Tue, 15 Oct 2002 10:22:01 -0400 (EDT) Received: from tnadeau-w2k.cisco.com (che-vpn2-84.cisco.com [10.86.244.84]) by bucket.cisco.com (Mirapoint) with ESMTP id ABY41745; Tue, 15 Oct 2002 10:21:50 -0400 (EDT) Message-Id: <4.3.2.7.2.20021015102102.07ebe4c0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Oct 2002 10:21:49 -0400 To: Edward Harrison From: "Thomas D. Nadeau" Subject: RE: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt Cc: "'jcucchiara@crescentnetworks.com'" , Parama - Cheenu Srinivasan , "'arun@force10networks.com'" , "'hans@ipunplugged.com'" , mpls@UU.NET In-Reply-To: <53F74F5A7B94D511841C00B0D0AB16F80109C96E@baker.datcon.co.u k> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >It's good to see the new revisions of the MPLS MIBs coming out. Slowly but surely. 8) >One comment, though - the text describing MplsTunnelAffinity says that it is >used for Include-any, Include-all and Exclude-all constraints. I think it >should say "Exclude-any" rather than "Exclude-all". > >I believe this has stemmed from a bug in the MPLS TE-MIB, which the authors >(or Tom at least!) said they were going to fix in the next revision. [As a >reminder, section 4.7.2 of RFC 3209 shows the vectors describing resource >affinities are Exclude-any, Include-any and Include-all, however >draft-ietf-mpls-te-mib-08.txt includes the objects >mplsTunnelExcludeAllAffinity, mplsTunnelIncludeAllAffinity and >mplsTunnelIncludeAnyAffinity.] Yes, thanks. That was a typo on my part. I will fix this during the next (and hopefully final) round of edits. --Tom >Regards, > >Ed > >-----Original Message----- >From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >Sent: 14 October 2002 12:26 >To: IETF-Announce >Cc: mpls@UU.NET >Subject: I-D ACTION:draft-ietf-mpls-tc-mib-04.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 : Definitions of Textual for Multiprotocol Label > Switching (MPLS) Management > Author(s) : T. Nadeau et al. > Filename : draft-ietf-mpls-tc-mib-04.txt > Pages : 18 > Date : 2002-10-11 > >This memo describes Textual Conventions for use in definitions of >management information for Multiprotocol Label Switching (MPLS) >networks. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-mpls-tc-mib-04.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >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-tc-mib-04.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-tc-mib-04.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. Success is relative; the more success, the more relatives. -Anonymous From owner-mpls@UU.NET Tue Oct 15 10:56:57 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04065 for ; Tue, 15 Oct 2002 10:56:57 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkrr05661 for ; Tue, 15 Oct 2002 14:59:03 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkrr04266; Tue, 15 Oct 2002 14:58:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkrr18780 for mpls-outgoing; Tue, 15 Oct 2002 14:57:58 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnkrr18760 for ; Tue, 15 Oct 2002 14:57:49 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnkrr15174 for ; Tue, 15 Oct 2002 14:54:31 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkrr26369 for ; Tue, 15 Oct 2002 14:54:31 GMT Received: from mlsrv1.avici.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host128.avici.com [208.246.215.128] (may be forged)) id QQnkrr26349 for ; Tue, 15 Oct 2002 14:54:30 GMT Received: from aatlas-lt.avici.com (b2-pc13.avici.com [10.2.100.33]) by mlsrv1.avici.com (8.11.0/8.11.0) with ESMTP id g9FEs1V00930; Tue, 15 Oct 2002 10:54:01 -0400 (EDT) Message-Id: <5.1.0.14.2.20021015105329.01f4ea60@mailhost.avici.com> X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 15 Oct 2002 10:54:48 -0400 To: "LE ROUX Jean-Louis FTRD/DAC/LAN" From: Alia Atlas Subject: RE: what's the status ofdraft-ietf-mpls-rsvp-lsp-fastreroute-00. txt Cc: "Pan, Ping" , "Shahram Davari" , "Thomas D. Nadeau" , In-Reply-To: <1FB136FD10CE33409C882630E299F5BE1EDB86@lanmhs30.rd.francet elecom.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi JL, Remember that today one can only merge detours for the same protected LSP. Currently, there's no idea that one could share bandwidth between detours protecting different primary LSPs (though the DETOUR object is there, so it would be possible...). Alia At 02:51 PM 10/14/2002 +0200, LE ROUX Jean-Louis FTRD/DAC/LAN wrote: >Hi Alia > >You say that an advantage of the path specific method >is less bandwidth reservation, thanks to detour merging. > >I'm not sure that detour merging always reduce bandwidth reservation. >Indeed, when you merge many detours, the final detour protects many >entities (links, nodes, SRLGs). >and thus you reduce the possibility to share bandwith with other >detours. > >Regards > >JL > >-----Message d'origine----- >De : Alia Atlas [mailto:aatlas@avici.com] >Envoye : samedi 12 octobre 2002 01:50 >A : Pan, Ping >Cc : Shahram Davari; 'Thomas D. Nadeau'; mpls@UU.NET >Objet : Re: what's the status ofdraft-ietf-mpls-rsvp-lsp-fastreroute-00. >txt > > >Absolutely. The real requirement has been for inter-operability. It is > >important that what is out there be inter-operable and provide the >functionality required. > >While I would not have chosen the trade-offs made for the path-specific >method, there are advantages to it (earlier merging of detours so less >bandwidth reserved) as well as disadvantages. Let those who plan to >deploy it decide what they want. > >The draft says how to sit down and actually implement this feature. As >Ping says, the code for it is rather complicated. One has to keep >track >of merging states, keeping state around even though the relevant >interface >is down, propagating or not propagating messages, etc. > >That said, much as Ping had the need to inter-operate with Cisco's >bypass >tunnels, we've had the requirement to inter-operate with both. Much >like >Ping, I sat down and figured out what would be possible and logical to >do; >we did so. That's why I did the draft suggesting how to deal in a >network >with both cases. > >Certainly, we've implemented both the Path-specific method as well as >the >sender-specific method, because of the requirement to interoperate. >That's >what standardization is about - the need to interoperate. > >We're keeping the old Class-type for FAST_REROUTE, without the >include-any >administrative-color, in the draft for the same reason. It describes >what >is done. > >Clearly the issue of the path-specific method is contentious. Are there > >others with opinions on this one? Perhaps we could/should put in some >applicability words about the advantages and disadvantages of each >approach >to aid those deciding which to implement and/or deploy? > >Alia > >At 04:23 PM 10/11/2002 -0700, Pan, Ping wrote: > >Hmmm... let me see who have done what in this space... > > > >Path-specific one-to-one method: > > Juniper, several routers (cannot tell the names) > > > >Sender-specific one-to-one method: > > Avici. ? > > > >Many-to-one method: > > Cisco (both node and link protection), Juniper (link protection for >now). > > > >We never said that every vendor has to support everything in the draft > >right away right now. Since each method has its own merits, we let the > >developers and carriers to decide. > > > >To talk about lack of consensus based on some people's comment is quite > > >amazing and disturbing. > > > >People have been asking why we glued two approaches together in the >first > >place. It looks like we are here for some rubber-stamping. But you guys > > >gotta ask yourself this: Cisco and Juniper are not the best friends in >the > >first place, so why in the world do they get together to do this? The > >answer is that marketing people tried to kill each other, but didn't >work. > >:-) The customers seem to know more than we do on the advantages and > >disadvantages of both methods... > > > >... It's been a slow Friday afternoon. Let me tell the whole story >behind > >this fast reroute crap: > > > >About one year ago, Der-Hwa Gan got one-to-one fast reroute working on > >Juniper routers. The original idea came from Tony Li (while in Juniper) > > >and Der-Hwa. It was by far the most complex code in RSVP (you guys >ought > >to try it someday). It worked, and shipped. At the same time, Cisco got >a > >MPLS fast-reroute working as well. Both methods didn't work together. >So > >one day, Dave Cooper of Global Crossing came to us and told us that he > >needed fast reroute to be compatible with each other, and didn't care >how > >to achieve it. > > > >I got the assignment, found a copy of draft-swallow, and started the > >coding. When I thought it was done, I hooked up a Cisco router. Nothing > > >worked! There was no sender-specific stuff in sight. All I got was the > >original Path messages tunneled through the bypass LSP. After talking >to > >George Swallow and JP directly over the phone, I was told that the new > >code was still in beta, and has not been released yet. To me, being >upset > >was an understatement! But Cisco folks were kind enough to send a copy >of > >their new draft that actually told me how it supposes to work. As my > >release date slipping fast, I had to rewrite the darn thing from >scratch. > > > >More disturbing discovery was that since Cisco used Shared-explicit >style, > >while Juniper used Fixed-Filter, there was no way we could turn on both > > >Juniper and Cisco fast reroute to protect a single LSP. We could not >ship > >this fast-reroute feature this way to the customers. Around this time, > >Alia from Avici told us that they had been reverse engineering Juniper > >fast reroute, and had found several serious problems (including merging > > >rules and sender-specific vs. path-specific). So Der-Hwa and I started >to > >changed our code while changing the spec. That merging rule in the >draft > >was actually a line-by-line pseudo code at one point. It was kinda fun > >thinking back. :-) > > > >When I was done with the facility fast reroute proposed by Cisco, there > > >were a lot of implementation issues. So I merged both drafts together, >and > >sent it to George and JP for correction along with a bunch of >questions. > >Avici folks came on board also. So we had several rounds of discussion >and > >disagreement, but came up a draft that developers knew how to >implement. > >That was what you have seen. > > > >The final outcome of the draft would allow both one-to-one and >many-to-one > >fast reroute to be turned on to protect a single LSP. Both >sender-specific > >and path-specific would work together too. That's what you have in >Junos > >5.4. The implementation of facility fast-reroute was limited to link > >protection in Juniper so far, because that was what Dave Cooper wanted > >anyway. Dave was kind enough that we actually interop'ed the facility > >fast-reroute with Cisco developers (Rob and Carol) in Global Crossing >lab > >(this is bud to you, Brook!). > > > >The reason for telling you all this is that this draft came directly >from > >engineers with the help from providers. No vendor politics, no IETF > >politics, it was a lot of pain and fun at the end! If you are a >developer, > >you can really implement this by reading spec. > > > >So before you question our motives again, please reconsider. > > > >Thanks! > > > >- Ping From owner-mpls@UU.NET Tue Oct 15 11:43:53 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05290 for ; Tue, 15 Oct 2002 11:43:53 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkrv03192 for ; Tue, 15 Oct 2002 15:46:00 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkrv01782; Tue, 15 Oct 2002 15:45:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkru10229 for mpls-outgoing; Tue, 15 Oct 2002 15:44:59 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnkru10224 for ; Tue, 15 Oct 2002 15:44:55 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnkru26371 for ; Tue, 15 Oct 2002 15:44:23 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkru25551 for ; Tue, 15 Oct 2002 15:44:23 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnkru25510 for ; Tue, 15 Oct 2002 15:44:22 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA12322 for ; Tue, 15 Oct 2002 11:44:21 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9FFiLl06370 for mpls@uu.net; Tue, 15 Oct 2002 11:44:21 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnkru10117 for ; Tue, 15 Oct 2002 15:41:19 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnkru18547 for ; Tue, 15 Oct 2002 15:35:41 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkru03191 for ; Tue, 15 Oct 2002 15:35:40 GMT Received: from petasus.isw.intel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: petasus.isw.intel.com [192.55.37.196]) id QQnkru03183 for ; Tue, 15 Oct 2002 15:35:39 GMT Received: from swsmsxvs01.isw.intel.com (swsmsxvs01.isw.intel.com [172.28.130.22]) by petasus.isw.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.47 2002/10/10 20:35:15 dmccart Exp $) with SMTP id g9FFY8b29176 for ; Tue, 15 Oct 2002 15:34:08 GMT Received: from swsmsx17.isw.intel.com ([172.28.130.21]) by swsmsxvs01.isw.intel.com (NAVGW 2.5.2.11) with SMTP id M2002101516323003160 for ; Tue, 15 Oct 2002 16:32:30 +0100 Received: by swsmsx17.isw.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Oct 2002 16:38:49 +0100 Message-ID: From: "Szymanski, Pawel" To: "'mpls@UU.NET'" Subject: TTL check in short pipe model without PHP Date: Tue, 15 Oct 2002 16:34:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-2" Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have a question regarding the draft-ietf-mpls-ttl-03. What TTL check should be performed for the short pipe model without PHP ? Is it the same check as for pipe model (i.e. the TTL from the exposed header is decremented and checked against 0) ? Best regards, Pawel Szymanski Software Engineer at Intel Technology Poland mailto:pawel.szymanski@intel.com From owner-mpls@UU.NET Tue Oct 15 12:39:42 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07023 for ; Tue, 15 Oct 2002 12:39:42 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkry15657 for ; Tue, 15 Oct 2002 16:41:49 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkry14563; Tue, 15 Oct 2002 16:41:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkry00618 for mpls-outgoing; Tue, 15 Oct 2002 16:41:01 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnkry00606 for ; Tue, 15 Oct 2002 16:40:54 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnkry09271 for ; Tue, 15 Oct 2002 16:36:18 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkry08925 for ; Tue, 15 Oct 2002 16:36:18 GMT Received: from fcs-nt1.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fcs-nt1.futsoft.com [66.122.42.228]) id QQnkry08906 for ; Tue, 15 Oct 2002 16:36:16 GMT Received: from sanjose.futsoft.com (unverified) by fcs-nt1.futsoft.com (Content Technologies SMTPRS 2.0.15) with SMTP id ; Tue, 15 Oct 2002 09:24:13 -0700 Received: from MANIS (adsl-66-122-42-231.futsoft.com [66.122.42.231]) by sanjose.futsoft.com (8.9.3/8.8.7) with SMTP id IAA04068; Tue, 15 Oct 2002 08:05:48 -0700 Reply-To: From: "Manikantan Srinivasan" To: "Vijayanand C - CTD, Chennai." Cc: , "David Charlap" Subject: RE: Comments for draft-vijay-mpls-rsvpte-lspsubobject-00.txt Date: Tue, 15 Oct 2002 09:24:47 -0700 Message-Id: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <55E277B99171E041ABF5F4B1C6DDCA06A57614@haritha.hclt.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Vijay > > 1) Regarding the L Bit - This could be set. For instance, if the previous > node of the tunnel ingress is not mentioned in the ERO then the > node before > that can still route the path message to the tunnel ingress looking at the > tunnel ingress address if the L bit is set. The ERO processing for the LSP subject needs clarification. Can this be added in your draft, how to process the ERO object in case of Strict ERO, Loose ERO etc., > > 2) Regarding the path message sent over the tunnel- I would say that the > path message would be sent over the existing tunnel as if it were an > interface, transparent to the intermediate nodes.It would not create path > state in the intermediate nodes. I did nt mention it explicitly though. Can this be explained as well. I am not sure to which FEC, this path message (data) will be mapped to? Because the initial tunnel/LSP is created for a specific FEC. Can this be added in your draft? best regards mani From owner-mpls@UU.NET Tue Oct 15 13:08:03 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07792 for ; Tue, 15 Oct 2002 13:08:02 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnksa02159 for ; Tue, 15 Oct 2002 17:10:08 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnksa01336; Tue, 15 Oct 2002 17:09:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQnksa17922 for mpls-outgoing; Tue, 15 Oct 2002 17:08:59 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnksa17876 for ; Tue, 15 Oct 2002 17:08:43 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnksa01065 for ; Tue, 15 Oct 2002 17:07:38 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnksa10016 for ; Tue, 15 Oct 2002 17:07:37 GMT Received: from gateway.ipinfusion.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.ipinfusion.com [65.223.109.2]) id QQnksa10004 for ; Tue, 15 Oct 2002 17:07:37 GMT Received: from YuanHong (dhcp123.ipinfusion.com [10.10.0.123] (may be forged)) by gateway.ipinfusion.com (8.11.6/8.11.6) with SMTP id g9FH6cW15727 for ; Tue, 15 Oct 2002 10:06:38 -0700 From: "Yuan Gu" To: "mpls group" Subject: RE: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt Date: Tue, 15 Oct 2002 10:06:59 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-4" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I didn't receive any reply yet. Does anyone have any clue? -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Yuan Gu Sent: Monday, October 14, 2002 11:11 AM To: mpls group Subject: RE: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt Hi: I have two questions of MplsLSPID defined in this MIB: 1. It states in this MIB: (MplsLSPId): "A unique identifier within an MPLS network that is assigned to each LSP. This is assigned at the head end of the LSP and can be used by all LSRs to identify this LSP...For LSPs signaled using RSVP-TE, the LSP ID is defined as a 16-bit (2 byte) identifier used in the SENDER_TEMPLATE..." My question is: How does a head end LSR assign a "MPLS network unique" LSPID for a LSP in case the signaling is RSVP-TE? In RFC3209, it says: "The SENDER_TEMPLATE object together with the session object uniquely identifies an LSP tunnel." Does MplsLSPId definition conflict with RFC3209? 2. A "mplsXCLspId" object is defined in XC table of LSR MIB while MplsLSPId is only used for CR-LDP and RSVP-TE. My question is: In case of LDP, how do we populate mplsXCLspID's value? Thanks for your reply! Yuan IP Infusion -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Internet-Drafts@ietf.org Sent: Monday, October 14, 2002 4:26 AM To: IETF-Announce: Cc: mpls@UU.NET Subject: I-D ACTION:draft-ietf-mpls-tc-mib-04.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 : Definitions of Textual for Multiprotocol Label Switching (MPLS) Management Author(s) : T. Nadeau et al. Filename : draft-ietf-mpls-tc-mib-04.txt Pages : 18 Date : 2002-10-11 This memo describes Textual Conventions for use in definitions of management information for Multiprotocol Label Switching (MPLS) networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tc-mib-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-tc-mib-04.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-tc-mib-04.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. From owner-mpls@UU.NET Tue Oct 15 13:53:21 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09546 for ; Tue, 15 Oct 2002 13:53:20 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnksd04490 for ; Tue, 15 Oct 2002 17:55:30 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnksd03050; Tue, 15 Oct 2002 17:54:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQnksd20759 for mpls-outgoing; Tue, 15 Oct 2002 17:54:40 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnksd20754 for ; Tue, 15 Oct 2002 17:54:30 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnksd14071 for ; Tue, 15 Oct 2002 17:53:31 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnksd16115 for ; Tue, 15 Oct 2002 17:53:30 GMT Received: from atlntex01.movaz.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: exchange.movaz.com [65.205.166.141]) id QQnksd16107 for ; Tue, 15 Oct 2002 17:53:30 GMT Received: from BLIULAPTOP ([172.16.24.104]) by atlntex01.movaz.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 15 Oct 2002 13:53:07 -0400 Message-ID: <012101c27473$b77dc810$681810ac@movaz.com> From: "Adrian Farrel" To: "'mpls@uu.net'" Subject: draft-farrel-mpls-ldp-restart-applic-01.txt Date: Tue, 15 Oct 2002 13:53:06 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-OriginalArrivalTime: 15 Oct 2002 17:53:07.0321 (UTC) FILETIME=[B7C83E90:01C27473] Sender: owner-mpls@UU.NET Precedence: bulk All, During the last calls on the LDP Fault Tolerance and LDP Restart drafts I received a few comments on the applicability draft. These are included in the republished version available at http://www.ietf.org/internet-drafts/draft-farrel-mpls-ldp-restart-applic-01.txt Adrian -- Adrian Farrel Director Protocol Development Movaz Networks Inc. Tel: 703-847-1867 afarrel@movaz.com From owner-mpls@UU.NET Tue Oct 15 14:00:34 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09907 for ; Tue, 15 Oct 2002 14:00:34 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkse07825 for ; Tue, 15 Oct 2002 18:02:42 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkse06489; Tue, 15 Oct 2002 18:02:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkse26033 for mpls-outgoing; Tue, 15 Oct 2002 18:01:18 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnkse25929 for ; Tue, 15 Oct 2002 18:01:12 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnksd04261 for ; Tue, 15 Oct 2002 17:56:35 GMT From: stefaan.de_cnodder@alcatel.be Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnksd22024 for ; Tue, 15 Oct 2002 17:56:35 GMT Received: from mail.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc250.alcatel.be [195.207.101.250]) id QQnksd21980 for ; Tue, 15 Oct 2002 17:56:34 GMT Received: from Bemail06.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g9FHnFs03028; Tue, 15 Oct 2002 19:49:15 +0200 Received: from alcatel.be ([138.203.197.32]) by Bemail06.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2002101519560397:7551 ; Tue, 15 Oct 2002 19:56:03 +0200 Message-ID: <3DAC56B0.3D7D1855@alcatel.be> Date: Tue, 15 Oct 2002 19:56:00 +0200 X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: LE ROUX Jean-Louis FTRD/DAC/LAN Cc: Alia Atlas , mpls@UU.NET Subject: Re: what's the statusofdraft-ietf-mpls-rsvp-lsp-fastreroute-00. txt References: <5.1.0.14.2.20021015105329.01f4ea60@mailhost.avici.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 10/15/2002 19:56:04, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 10/15/2002 19:56:05, Serialize complete at 10/15/2002 19:56:06, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 10/15/2002 19:56:06 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit JL, When a PLR (in case of one-to-one protection) receives a ResvTear, it may also do a switchover to the detour. So a detour is used not only when the immediate downstream link or router fails, but it can also be triggered by failures further downstream and the downstream nodes do not have a detour (the last paragraph of section 5.2 of the fast-reroute draft suggests this behavior although it is not clear). So sharing bandwidth between detours protecting different primary LSPs becomes difficult, i.e. in the worst case, a detour can protect the whole primary LSP downstream of the PLR and merging another detour with it will not necessarily increase the number of protected entities. This looks like a good property because you have fast protection (although somewhat slower) even in case the local PLR upstream the failure was not able to establish a detour. So merging detours (for both types of detours) looks like a good solution to save bandwidth. regards, Stefaan Alia Atlas wrote: > > Hi JL, > > Remember that today one can only merge detours for the same protected > LSP. Currently, there's no idea that one could share bandwidth between > detours protecting different primary LSPs (though the DETOUR object is > there, so it would be possible...). > > Alia > > At 02:51 PM 10/14/2002 +0200, LE ROUX Jean-Louis FTRD/DAC/LAN wrote: > >Hi Alia > > > >You say that an advantage of the path specific method > >is less bandwidth reservation, thanks to detour merging. > > > >I'm not sure that detour merging always reduce bandwidth reservation. > >Indeed, when you merge many detours, the final detour protects many > >entities (links, nodes, SRLGs). > >and thus you reduce the possibility to share bandwith with other > >detours. > > > >Regards > > > >JL > > > >-----Message d'origine----- > >De : Alia Atlas [mailto:aatlas@avici.com] > >Envoye : samedi 12 octobre 2002 01:50 > >A : Pan, Ping > >Cc : Shahram Davari; 'Thomas D. Nadeau'; mpls@UU.NET > >Objet : Re: what's the status ofdraft-ietf-mpls-rsvp-lsp-fastreroute-00. > >txt > > > > > >Absolutely. The real requirement has been for inter-operability. It is > > > >important that what is out there be inter-operable and provide the > >functionality required. > > > >While I would not have chosen the trade-offs made for the path-specific > >method, there are advantages to it (earlier merging of detours so less > >bandwidth reserved) as well as disadvantages. Let those who plan to > >deploy it decide what they want. > > > >The draft says how to sit down and actually implement this feature. As > >Ping says, the code for it is rather complicated. One has to keep > >track > >of merging states, keeping state around even though the relevant > >interface > >is down, propagating or not propagating messages, etc. > > > >That said, much as Ping had the need to inter-operate with Cisco's > >bypass > >tunnels, we've had the requirement to inter-operate with both. Much > >like > >Ping, I sat down and figured out what would be possible and logical to > >do; > >we did so. That's why I did the draft suggesting how to deal in a > >network > >with both cases. > > > >Certainly, we've implemented both the Path-specific method as well as > >the > >sender-specific method, because of the requirement to interoperate. > >That's > >what standardization is about - the need to interoperate. > > > >We're keeping the old Class-type for FAST_REROUTE, without the > >include-any > >administrative-color, in the draft for the same reason. It describes > >what > >is done. > > > >Clearly the issue of the path-specific method is contentious. Are there > > > >others with opinions on this one? Perhaps we could/should put in some > >applicability words about the advantages and disadvantages of each > >approach > >to aid those deciding which to implement and/or deploy? > > > >Alia > > > >At 04:23 PM 10/11/2002 -0700, Pan, Ping wrote: > > >Hmmm... let me see who have done what in this space... > > > > > >Path-specific one-to-one method: > > > Juniper, several routers (cannot tell the names) > > > > > >Sender-specific one-to-one method: > > > Avici. ? > > > > > >Many-to-one method: > > > Cisco (both node and link protection), Juniper (link protection for > >now). > > > > > >We never said that every vendor has to support everything in the draft > > >right away right now. Since each method has its own merits, we let the > > >developers and carriers to decide. > > > > > >To talk about lack of consensus based on some people's comment is quite > > > > >amazing and disturbing. > > > > > >People have been asking why we glued two approaches together in the > >first > > >place. It looks like we are here for some rubber-stamping. But you guys > > > > >gotta ask yourself this: Cisco and Juniper are not the best friends in > >the > > >first place, so why in the world do they get together to do this? The > > >answer is that marketing people tried to kill each other, but didn't > >work. > > >:-) The customers seem to know more than we do on the advantages and > > >disadvantages of both methods... > > > > > >... It's been a slow Friday afternoon. Let me tell the whole story > >behind > > >this fast reroute crap: > > > > > >About one year ago, Der-Hwa Gan got one-to-one fast reroute working on > > >Juniper routers. The original idea came from Tony Li (while in Juniper) > > > > >and Der-Hwa. It was by far the most complex code in RSVP (you guys > >ought > > >to try it someday). It worked, and shipped. At the same time, Cisco got > >a > > >MPLS fast-reroute working as well. Both methods didn't work together. > >So > > >one day, Dave Cooper of Global Crossing came to us and told us that he > > >needed fast reroute to be compatible with each other, and didn't care > >how > > >to achieve it. > > > > > >I got the assignment, found a copy of draft-swallow, and started the > > >coding. When I thought it was done, I hooked up a Cisco router. Nothing > > > > >worked! There was no sender-specific stuff in sight. All I got was the > > >original Path messages tunneled through the bypass LSP. After talking > >to > > >George Swallow and JP directly over the phone, I was told that the new > > >code was still in beta, and has not been released yet. To me, being > >upset > > >was an understatement! But Cisco folks were kind enough to send a copy > >of > > >their new draft that actually told me how it supposes to work. As my > > >release date slipping fast, I had to rewrite the darn thing from > >scratch. > > > > > >More disturbing discovery was that since Cisco used Shared-explicit > >style, > > >while Juniper used Fixed-Filter, there was no way we could turn on both > > > > >Juniper and Cisco fast reroute to protect a single LSP. We could not > >ship > > >this fast-reroute feature this way to the customers. Around this time, > > >Alia from Avici told us that they had been reverse engineering Juniper > > >fast reroute, and had found several serious problems (including merging > > > > >rules and sender-specific vs. path-specific). So Der-Hwa and I started > >to > > >changed our code while changing the spec. That merging rule in the > >draft > > >was actually a line-by-line pseudo code at one point. It was kinda fun > > >thinking back. :-) > > > > > >When I was done with the facility fast reroute proposed by Cisco, there > > > > >were a lot of implementation issues. So I merged both drafts together, > >and > > >sent it to George and JP for correction along with a bunch of > >questions. > > >Avici folks came on board also. So we had several rounds of discussion > >and > > >disagreement, but came up a draft that developers knew how to > >implement. > > >That was what you have seen. > > > > > >The final outcome of the draft would allow both one-to-one and > >many-to-one > > >fast reroute to be turned on to protect a single LSP. Both > >sender-specific > > >and path-specific would work together too. That's what you have in > >Junos > > >5.4. The implementation of facility fast-reroute was limited to link > > >protection in Juniper so far, because that was what Dave Cooper wanted > > >anyway. Dave was kind enough that we actually interop'ed the facility > > >fast-reroute with Cisco developers (Rob and Carol) in Global Crossing > >lab > > >(this is bud to you, Brook!). > > > > > >The reason for telling you all this is that this draft came directly > >from > > >engineers with the help from providers. No vendor politics, no IETF > > >politics, it was a lot of pain and fun at the end! If you are a > >developer, > > >you can really implement this by reading spec. > > > > > >So before you question our motives again, please reconsider. > > > > > >Thanks! > > > > > >- Ping From owner-mpls@UU.NET Tue Oct 15 14:47:04 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11548 for ; Tue, 15 Oct 2002 14:47:03 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnksh18739 for ; Tue, 15 Oct 2002 18:49:13 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnksh17665; Tue, 15 Oct 2002 18:48:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQnksh11292 for mpls-outgoing; Tue, 15 Oct 2002 18:48:15 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnksh11283 for ; Tue, 15 Oct 2002 18:48:12 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnksh08729 for ; Tue, 15 Oct 2002 18:45:29 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnksh11125 for ; Tue, 15 Oct 2002 18:45:29 GMT Received: from mailserv.hatteras.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailserv.hatterasnetworks.com [63.89.58.4]) id QQnksh11118 for ; Tue, 15 Oct 2002 18:45:28 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Latest MPLS Ping draft... Date: Tue, 15 Oct 2002 14:45:28 -0400 Message-ID: <8052E2EA753D144EB906B7A7AA3997140E9445@mailserv.hatteras.com> Thread-Topic: Latest MPLS Ping draft... Thread-Index: AcJ0ewhEomp/0owRSjC2Smdo5AubDA== From: "Brian Hassink" To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA11548 Hello, A few thoughts/suggestions/questions on the latest MPLS Ping draft... I'm wondering if it wouldn't be better to move the return code from the main header to the TLV header, or add a return code to the TLV header? I think there may be a couple of good reasons for doing this... o As more message types and TLV types are defined, more return codes will be required, possibly leading to overloaded meanings and a loss of scope. o If multiple TLVs are bundled in a request, a single return code may not be sufficient to return the full results of the request. I think the return code in the main header could be used for more general results, such as "no error", "unsupported version", "malformed request", "reply too big", etc, and the return code in the TLV header could be used for results specific to that TLV. Also, couldn't a (optional) "timestamp" TLV be defined rather than having this information as mandatory fields in the main header? Lastly, it's not clear to me which FEC applies to a tunnel that has been setup manually (i.e. static tunnels)? Cheers, Brian --- bhassink@hatterasnetworks.com From owner-mpls@UU.NET Tue Oct 15 15:03:34 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12199 for ; Tue, 15 Oct 2002 15:03:33 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnksi20091 for ; Tue, 15 Oct 2002 19:05:42 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnksi18924; Tue, 15 Oct 2002 19:05:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQnksi28266 for mpls-outgoing; Tue, 15 Oct 2002 19:04:37 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnksi28241 for ; Tue, 15 Oct 2002 19:04:26 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnksi28297 for ; Tue, 15 Oct 2002 19:00:48 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnksi08818 for ; Tue, 15 Oct 2002 19:00:47 GMT Received: from mailserv.hatteras.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailserv.hatterasnetworks.com [63.89.58.4]) id QQnksi08809 for ; Tue, 15 Oct 2002 19:00:47 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Latest MPLS Ping draft... Date: Tue, 15 Oct 2002 15:00:47 -0400 Message-ID: <8052E2EA753D144EB906B7A7AA3997140B46C8@mailserv.hatteras.com> Thread-Topic: Latest MPLS Ping draft... Thread-Index: AcJ0ewhEomp/0owRSjC2Smdo5AubDAAAX9Sg From: "Brian Hassink" To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA12199 Whoops, one other comment... I noticed there is no checksum field in the main header. Should it be called out that there is an assumption that the underlying transport (which is UDP for the request and two of the reply modes) will ensure the integrity of the MPLS ping packet? Could there ever be a reply-mode where this isn't the case? Cheers, Brian --- bhassink@hatterasnetworks.com -----Original Message----- From: Brian Hassink Sent: Tuesday, October 15, 2002 2:45 PM To: mpls@UU.NET Subject: Latest MPLS Ping draft... Hello, A few thoughts/suggestions/questions on the latest MPLS Ping draft... I'm wondering if it wouldn't be better to move the return code from the main header to the TLV header, or add a return code to the TLV header? I think there may be a couple of good reasons for doing this... o As more message types and TLV types are defined, more return codes will be required, possibly leading to overloaded meanings and a loss of scope. o If multiple TLVs are bundled in a request, a single return code may not be sufficient to return the full results of the request. I think the return code in the main header could be used for more general results, such as "no error", "unsupported version", "malformed request", "reply too big", etc, and the return code in the TLV header could be used for results specific to that TLV. Also, couldn't a (optional) "timestamp" TLV be defined rather than having this information as mandatory fields in the main header? Lastly, it's not clear to me which FEC applies to a tunnel that has been setup manually (i.e. static tunnels)? Cheers, Brian --- bhassink@hatterasnetworks.com From owner-mpls@UU.NET Tue Oct 15 17:35:54 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16573 for ; Tue, 15 Oct 2002 17:35:54 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkss09885 for ; Tue, 15 Oct 2002 21:38:02 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkss08963; Tue, 15 Oct 2002 21:37:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkss14981 for mpls-outgoing; Tue, 15 Oct 2002 21:36:49 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnkss14976 for ; Tue, 15 Oct 2002 21:36:42 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnkss10364 for ; Tue, 15 Oct 2002 21:34:11 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkss11548 for ; Tue, 15 Oct 2002 21:34:11 GMT Received: from milan.turinnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.turinnetworks.com [63.197.247.126]) id QQnkss11539 for ; Tue, 15 Oct 2002 21:34:10 GMT Received: by milan.turinnetworks.com with Internet Mail Service (5.5.2653.19) id <43L30G6Z>; Tue, 15 Oct 2002 14:17:09 -0700 Message-ID: <36EF020032CFD411B7B400508B55E59002B8F72A@milan.turinnetworks.com> From: Bhaskara Peela To: "'Hemant Khare'" , rsvp@isi.edu Cc: mpls@UU.NET Subject: RE: Date: Tue, 15 Oct 2002 14:17:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Hemanth, Using error node IP address, ingress node of LSP can know where the error occurred by associating what kind of error and it can take some fault correction action. If resources are not available on that node, ingress node can try establishing LSP in some other alternate path. bhaskara -----Original Message----- From: Hemant Khare [mailto:hemanth_khare@rediffmail.com] Sent: Tuesday, October 15, 2002 1:16 AM To: rsvp@isi.edu Cc: mpls@UU.NET Subject: Hi, I've a question. In RFC 2205 (RSVP)it is given that ERROR_SPEC object carries following information, 1. Error code 2. Error value 3. some flags 4. The IP address of the node in which the error was detected Purpose of 1,2,3 are clear to me. But purpose of carrying IP address of node which detected the error is not clear. When the intented node receives the error message (which carries ERROR_SPEC), what he'll do using this IP address? There must be some specific purpose, i think. Please let me know ur thoughts on this Ragards and TIA -hemanth __________________________________________________________ Give your Company an email address like ravi @ ravi-exports.com. Sign up for Rediffmail Pro today! Know more. http://www.rediffmailpro.com/signup/ From owner-mpls@UU.NET Wed Oct 16 01:42:46 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25670 for ; Wed, 16 Oct 2002 01:42:46 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkty29095 for ; Wed, 16 Oct 2002 05:44:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkty28028; Wed, 16 Oct 2002 05:44:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkty00624 for mpls-outgoing; Wed, 16 Oct 2002 05:44:14 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnkty00591 for ; Wed, 16 Oct 2002 05:44:06 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnkty21545 for ; Wed, 16 Oct 2002 05:44:01 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkty05956 for ; Wed, 16 Oct 2002 05:44:00 GMT Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQnkty05940 for ; Wed, 16 Oct 2002 05:43:58 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id <48ZB7P4L>; Wed, 16 Oct 2002 11:13:22 +0530 Message-ID: <55E277B99171E041ABF5F4B1C6DDCA06A57F92@haritha.hclt.com> From: "Vijayanand C - CTD, Chennai." To: manis@futsoft.com Cc: mpls@UU.NET, David Charlap Subject: RE: Comments for draft-vijay-mpls-rsvpte-lspsubobject-00.txt Date: Wed, 16 Oct 2002 11:15:40 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Mani, The L bit processing would be no different from the normal processing in other subobjects. The ingress IP address in the LSP subobject is the address of consideration in this subobject.Anyway, to make it clear and explicit it can be incorporated in subsequent revisions. Regarding the sending of path message through the tunnel, I think this is more of an implementation issue. The ingress of the tunnel, which processes the LSP subobject, would identify that the path message should be transparently sent to the egress without creating path state in intermediate nodes.The tunnel which is like an IP interface, would be the outgoing interface for reaching the egress. I would add an explicit mention of this in subsequent revisions of the draft. Thanks and Regards, Vijay -----Original Message----- From: Manikantan Srinivasan [mailto:manis@futsoft.com] Sent: Tuesday, October 15, 2002 9:55 PM To: Vijayanand C - CTD, Chennai. Cc: mpls@uu.net; David Charlap Subject: RE: Comments for draft-vijay-mpls-rsvpte-lspsubobject-00.txt Vijay > > 1) Regarding the L Bit - This could be set. For instance, if the previous > node of the tunnel ingress is not mentioned in the ERO then the > node before > that can still route the path message to the tunnel ingress looking at the > tunnel ingress address if the L bit is set. The ERO processing for the LSP subject needs clarification. Can this be added in your draft, how to process the ERO object in case of Strict ERO, Loose ERO etc., > > 2) Regarding the path message sent over the tunnel- I would say that the > path message would be sent over the existing tunnel as if it were an > interface, transparent to the intermediate nodes.It would not create path > state in the intermediate nodes. I did nt mention it explicitly though. Can this be explained as well. I am not sure to which FEC, this path message (data) will be mapped to? Because the initial tunnel/LSP is created for a specific FEC. Can this be added in your draft? best regards mani From owner-mpls@UU.NET Wed Oct 16 06:41:13 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24140 for ; Wed, 16 Oct 2002 06:41:13 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkus00475 for ; Wed, 16 Oct 2002 10:43:22 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkus29566; Wed, 16 Oct 2002 10:42:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkus13489 for mpls-outgoing; Wed, 16 Oct 2002 10:42:13 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnkus13484 for ; Wed, 16 Oct 2002 10:42:06 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnkus03647 for ; Wed, 16 Oct 2002 10:39:46 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkus27066 for ; Wed, 16 Oct 2002 10:39:46 GMT Received: from mail2.astaro.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.astaro.com [213.30.251.2]) id QQnkus27057 for ; Wed, 16 Oct 2002 10:39:45 GMT Received: from [192.168.2.10] (helo=exchange.astaro.de) by mail2.astaro.com with smtp (Exim 6.66 #1) id 181lL2-0003j6-00 for mpls@UU.NET; Wed, 16 Oct 2002 12:23:40 +0200 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MIMEOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: RE: Latest MPLS Ping draft... Date: Wed, 16 Oct 2002 12:38:54 +0200 Message-ID: <522A69BCBAD4D543B1638679965FBCA966EBCF@exchange.intranet.astaro.de> Thread-Topic: RE: RE: Latest MPLS Ping draft... thread-index: AcJ0mBejfObQhmslSwOPc9vS1wanZQ== From: "Markus Hennig" To: X-Scanner: exiscan *181lL2-0003j6-00*uMD/a/ahcjg* on Astaro Security Linux Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA24140 Hello all, my 2c to the lsp-ping-01 draft: What about target FEC types with more then the defined IPv[4|6] prefix (for example the prefix and(!) source and destination IPv[4|6] ports, maybe also a tcp/udp flag)? I wonder why this isn't a point of discussion at all... Markus From owner-mpls@UU.NET Wed Oct 16 16:11:12 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10760 for ; Wed, 16 Oct 2002 16:11:12 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkwe29501 for ; Wed, 16 Oct 2002 20:13:18 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkwe28488; Wed, 16 Oct 2002 20:12:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkwe05775 for mpls-outgoing; Wed, 16 Oct 2002 20:12:24 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnkwe05767 for ; Wed, 16 Oct 2002 20:12:08 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkwe01117 for ; Wed, 16 Oct 2002 20:11:40 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkwe21220 for ; Wed, 16 Oct 2002 20:11:40 GMT Received: from zcars04e.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQnkwe21213 for ; Wed, 16 Oct 2002 20:11:39 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9GKBXi24100 for ; Wed, 16 Oct 2002 16:11:33 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Oct 2002 16:11:33 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C05A23FD7@zcard031.ca.nortel.com> From: "David Allan" To: mpls@UU.NET Subject: RE: RE: Latest MPLS Ping draft... Date: Wed, 16 Oct 2002 16:11:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27550.381C2ADE" Sender: owner-mpls@UU.NET Precedence: bulk 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_01C27550.381C2ADE Content-Type: text/plain; charset="iso-8859-1" Hi: There were a comment I raised previously that was not addressed... section 4.5: Non-compliant routers. In general the topic of TTL came up earlier, as there is no explicit mention of that happens when testing a path that uses the uniform instead of the pipe model. Consistent with the expectation of non-compliant routers, shouldn't any LSP PING request that TTL exhausts and is not payload of the top label simply be discarded. If agreement breaks out, this should be documented. And some new questions: Section 2: Motivations: A bit more discussion of what consistutes a "reasonable time" and what factors affect this would be useful. In some applications such as LDP/ECMP etc. detection time would appear to be in proportion to network diameter. Section 3: When discussing "no reply" processing, the suggestion is that the egress router may track sequence numbers etc. This looks rather optimistic and is not exactly consistent with the application of port rate limiting at the egress and how use of LSP ping with MP2P will work when deployed. Similarly, the ingress issuing multiple messages with the same sequence number in hope that the egress will respond to one of them seems rather perverse. Presumably the egress can similarly reply to all of them hoping the ingress will see one of them. How does one track this (lets see, I got 3 fives and 2 sevens) Seems to me that a superior approach (and one that does not welcome really dumb replay attacks at some point in the future) is that the sequence number always increments, and the receivers discard duplicates. Otherwise one end may actually implement only monitonic increase of sequence numbers while the other end resends multiples, seems to me there is an interoperability issue here if one expects to infer anything meaningful from sequence number tracking. The reply codes still strike me as incomplete as an ENUM instead of a bit map or some other format that allows multiple outcomes for a probe. Section 4.1: It seems to be a bit of a misnomer to call an RSVP Session ID object an FEC. Could we user another term if it is simply any configuration or administered attribute of an LSP that should be verified? I presume the use of internal loopback address range is to address ECMP, and anything periodically pinging should be monotonically increasing the address. This is great if there is only one instance of ECMP downstream of the ping source. Any comments on when multiple ECMP points are traversed by the PING packet. Currently ECMP is proprietary, so I am not sure if this can be characterized or one can be sure that this will actually test everything. I can't envision using traceroute mode with don't reply, but that appears to be a valid option. Section 4.3: Some useful guidelines as to IP addresses NOT to respond to might be a good idea. Section 5.3: Other than being modelled on ICMP, it has otherwise not been mentioned. Why the reference to using explicit NULL with ICMP here? cheers Dave ------_=_NextPart_001_01C27550.381C2ADE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: RE: Latest MPLS Ping draft...

Hi:

There were a comment I raised previously that was not = addressed...

section 4.5: Non-compliant routers. In general the = topic of TTL came up earlier, as there is no explicit mention of that = happens when testing a path that uses the uniform instead of the pipe = model. Consistent with the expectation of non-compliant routers, = shouldn't any LSP PING request that TTL exhausts and is not payload of = the top label simply be discarded. If agreement breaks out, this should = be documented.

And some new questions:

Section 2: Motivations: A bit more discussion of what = consistutes a "reasonable time" and what factors affect this = would be useful. In some applications such as LDP/ECMP etc. detection = time would appear to be in proportion to network diameter.

Section 3: When discussing "no reply" = processing, the suggestion is that the egress router may track sequence = numbers etc. This looks rather optimistic and is not exactly consistent = with the application of port rate limiting at the egress and how use of = LSP ping with MP2P will work when deployed. Similarly, the ingress = issuing multiple messages with the same sequence number in hope that = the egress will respond to one of them seems rather perverse. = Presumably the egress can similarly reply to all of them hoping the = ingress will see one of them. How does one track this (lets see, I got = 3 fives and 2 sevens) Seems to me that a superior approach (and one = that does not welcome really dumb replay attacks at some point in the = future) is that the sequence number always increments, and the = receivers discard duplicates. Otherwise one end may actually implement = only monitonic increase of sequence numbers while the other end resends = multiples, seems to me there is an interoperability issue here if one = expects to infer anything meaningful from sequence number = tracking.

The reply codes still strike me as incomplete as an = ENUM instead of a bit map or some other format that allows multiple = outcomes for a probe.

Section 4.1: It seems to be a bit of a misnomer to = call an RSVP Session ID object an FEC. Could we user another term if it = is simply any configuration or administered attribute of an LSP that = should be verified?

I presume the use of internal loopback address range = is to address ECMP, and anything periodically pinging should be = monotonically increasing the address. This is great if there is only = one instance of ECMP downstream of the ping source. Any comments on = when multiple ECMP points are traversed by the PING packet. Currently = ECMP is proprietary, so I am not sure if this can be characterized or = one can be sure that this will actually test everything.

I can't envision using traceroute mode with don't = reply, but that appears to be a valid option.

Section 4.3: Some useful guidelines as to IP = addresses NOT to respond to might be a good idea.

Section 5.3: Other than being modelled on ICMP, it = has otherwise not been mentioned. Why the reference to using explicit = NULL with ICMP here?

cheers
Dave





------_=_NextPart_001_01C27550.381C2ADE-- From owner-mpls@UU.NET Wed Oct 16 16:20:06 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11094 for ; Wed, 16 Oct 2002 16:20:05 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkwf17914 for ; Wed, 16 Oct 2002 20:22:15 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkwf16393; Wed, 16 Oct 2002 20:21:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkwf06470 for mpls-outgoing; Wed, 16 Oct 2002 20:21:07 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnkwf06402 for ; Wed, 16 Oct 2002 20:20:54 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkwf21498 for ; Wed, 16 Oct 2002 20:15:02 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkwf26171 for ; Wed, 16 Oct 2002 20:15:02 GMT Received: from zcars04e.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQnkwf26152 for ; Wed, 16 Oct 2002 20:15:01 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9GKF0i24378 for ; Wed, 16 Oct 2002 16:15:00 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Oct 2002 16:15:00 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C05A23FEA@zcard031.ca.nortel.com> From: "David Allan" To: mpls@UU.NET Subject: FW: RE: Latest MPLS Ping draft... Date: Wed, 16 Oct 2002 16:14:59 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Apologies for the format of the last post.... Hi: There were a comment I raised previously that was not addressed... section 4.5: Non-compliant routers. In general the topic of TTL came up earlier, as there is no explicit mention of that happens when testing a path that uses the uniform instead of the pipe model. Consistent with the expectation of non-compliant routers, shouldn't any LSP PING request that TTL exhausts and is not payload of the top label simply be discarded. If agreement breaks out, this should be documented. And some new questions: Section 2: Motivations: A bit more discussion of what consistutes a "reasonable time" and what factors affect this would be useful. In some applications such as LDP/ECMP etc. detection time would appear to be in proportion to network diameter. Section 3: When discussing "no reply" processing, the suggestion is that the egress router may track sequence numbers etc. This looks rather optimistic and is not exactly consistent with the application of port rate limiting at the egress and how use of LSP ping with MP2P will work when deployed. Similarly, the ingress issuing multiple messages with the same sequence number in hope that the egress will respond to one of them seems rather perverse. Presumably the egress can similarly reply to all of them hoping the ingress will see one of them. How does one track this (lets see, I got 3 fives and 2 sevens) Seems to me that a superior approach (and one that does not welcome really dumb replay attacks at some point in the future) is that the sequence number always increments, and the receivers discard duplicates. Otherwise one end may actually implement only monitonic increase of sequence numbers while the other end resends multiples, seems to me there is an interoperability issue here if one expects to infer anything meaningful from sequence number tracking. The reply codes still strike me as incomplete as an ENUM instead of a bit map or some other format that allows multiple outcomes for a probe. Section 4.1: It seems to be a bit of a misnomer to call an RSVP Session ID object an FEC. Could we user another term if it is simply any configuration or administered attribute of an LSP that should be verified? I presume the use of internal loopback address range is to address ECMP, and anything periodically pinging should be monotonically increasing the address. This is great if there is only one instance of ECMP downstream of the ping source. Any comments on when multiple ECMP points are traversed by the PING packet. Currently ECMP is proprietary, so I am not sure if this can be characterized or one can be sure that this will actually test everything. I can't envision using traceroute mode with don't reply, but that appears to be a valid option. Section 4.3: Some useful guidelines as to IP addresses NOT to respond to might be a good idea. Section 5.3: Other than being modelled on ICMP, it has otherwise not been mentioned. Why the reference to using explicit NULL with ICMP here? cheers Dave From owner-mpls@UU.NET Wed Oct 16 18:57:12 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14400 for ; Wed, 16 Oct 2002 18:57:12 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkwp29634 for ; Wed, 16 Oct 2002 22:59:19 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkwp28195; Wed, 16 Oct 2002 22:58:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkwp19383 for mpls-outgoing; Wed, 16 Oct 2002 22:58:22 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnkwp19378 for ; Wed, 16 Oct 2002 22:58:17 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkwp21875 for ; Wed, 16 Oct 2002 22:56:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkwp00602 for ; Wed, 16 Oct 2002 22:56:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnkwp00574 for ; Wed, 16 Oct 2002 22:56:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA16955 for ; Wed, 16 Oct 2002 18:56:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9GMu2u07931 for mpls@uu.net; Wed, 16 Oct 2002 18:56:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnkwp19054 for ; Wed, 16 Oct 2002 22:54:29 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkwp27821 for ; Wed, 16 Oct 2002 22:53:57 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkwp27159 for ; Wed, 16 Oct 2002 22:53:57 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQnkwp27151 for ; Wed, 16 Oct 2002 22:53:57 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14304; Wed, 16 Oct 2002 18:51:45 -0400 (EDT) Message-Id: <200210162251.SAA14304@ietf.org> To: IETF-Announce:; Cc: mpls@UU.NET From: The IESG SUBJECT: Last Call: Graceful Restart Mechanism for LDP to Proposed Standard Reply-to: iesg@ietf.org Date: Wed, 16 Oct 2002 18:51:45 -0400 Sender: owner-mpls@UU.NET Precedence: bulk The IESG has received a request from the Multiprotocol Label Switching Working Group to consider Graceful Restart Mechanism for LDP as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2002-10-30. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-restart-06.txt From owner-mpls@UU.NET Wed Oct 16 19:18:39 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14771 for ; Wed, 16 Oct 2002 19:18:39 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkwr17320 for ; Wed, 16 Oct 2002 23:20:46 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkwr15880; Wed, 16 Oct 2002 23:19:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkwr07676 for mpls-outgoing; Wed, 16 Oct 2002 23:19:02 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnkwr07671 for ; Wed, 16 Oct 2002 23:18:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkwr12284 for ; Wed, 16 Oct 2002 23:18:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkwr06045 for ; Wed, 16 Oct 2002 23:18:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnkwr06032 for ; Wed, 16 Oct 2002 23:18:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA18126 for ; Wed, 16 Oct 2002 19:18:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9GNI1309427 for mpls@uu.net; Wed, 16 Oct 2002 19:18:01 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnkwr07646 for ; Wed, 16 Oct 2002 23:17:12 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkwq12672 for ; Wed, 16 Oct 2002 23:12:36 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkwq27233 for ; Wed, 16 Oct 2002 23:12:36 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQnkwq27204 for ; Wed, 16 Oct 2002 23:12:35 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14624; Wed, 16 Oct 2002 19:10:24 -0400 (EDT) Message-Id: <200210162310.TAA14624@ietf.org> To: IETF-Announce:; Cc: mpls@UU.NET From: The IESG SUBJECT: Last Call: Graceful Restart Mechanism for BGP with MPLS to Proposed Standard Reply-to: iesg@ietf.org Date: Wed, 16 Oct 2002 19:10:24 -0400 Sender: owner-mpls@UU.NET Precedence: bulk The IESG has received a request from the Multiprotocol Label Switching Working Group to consider Graceful Restart Mechanism for BGP with MPLS as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2002-10-30. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-bgp-mpls-restart-02.txt From owner-mpls@UU.NET Wed Oct 16 22:26:27 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18709 for ; Wed, 16 Oct 2002 22:26:27 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnksm09691 for ; Tue, 15 Oct 2002 20:09:40 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnksm08574; Tue, 15 Oct 2002 20:09:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQnksm20365 for mpls-outgoing; Tue, 15 Oct 2002 20:08:16 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnksm20309 for ; Tue, 15 Oct 2002 20:08:07 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnksm20633 for ; Tue, 15 Oct 2002 20:07:04 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnksm23346 for ; Tue, 15 Oct 2002 20:07:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnksm23309 for ; Tue, 15 Oct 2002 20:07:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA06168 for ; Tue, 15 Oct 2002 16:07:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9FK72H21909 for mpls@uu.net; Tue, 15 Oct 2002 16:07:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnksm19929 for ; Tue, 15 Oct 2002 20:05:19 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnksm29757 for ; Tue, 15 Oct 2002 20:02:12 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnksm06707 for ; Tue, 15 Oct 2002 20:02:12 GMT Received: from hawk.CrescentNetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hawk.crescentnetworks.com [66.105.92.144]) id QQnksm06698 for ; Tue, 15 Oct 2002 20:02:12 GMT Received: from CrescentNetworks.com (jcucchiara.in.crescentnets.com [192.168.29.132]) by hawk.CrescentNetworks.com (8.9.3/8.9.3) with ESMTP id QAA08141; Tue, 15 Oct 2002 16:01:14 -0400 (EDT) Message-ID: <3DAC7429.B7B8A270@CrescentNetworks.com> Date: Tue, 15 Oct 2002 16:01:45 -0400 From: Joan Cucchiara X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Yuan Gu CC: mpls group Subject: Re: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Yuan, Yuan Gu wrote: > > I didn't receive any reply yet. Does anyone have any clue? > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Yuan Gu > Sent: Monday, October 14, 2002 11:11 AM > To: mpls group > Subject: RE: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt > > Hi: > > I have two questions of MplsLSPID defined in this MIB: > > 1. It states in this MIB: > (MplsLSPId): "A unique identifier within an MPLS network that is assigned to > each LSP. This is assigned at the head end of the LSP and can be used by all > LSRs to identify this LSP...For LSPs signaled using RSVP-TE, the LSP ID is > defined as a 16-bit (2 byte) identifier used in the SENDER_TEMPLATE..." > My question is: How does a head end LSR assign a "MPLS network unique" LSPID > for a LSP in case the signaling is RSVP-TE? In RFC3209, it says: "The > SENDER_TEMPLATE object together with the session object uniquely identifies > an LSP tunnel." Does MplsLSPId definition conflict with RFC3209? The LSP ID portion of the Session object, does uniquely identify the specific Tunnel (see section 2.5 of that same spec). > > 2. A "mplsXCLspId" object is defined in XC table of LSR MIB while MplsLSPId > is only used for CR-LDP and RSVP-TE. My question is: In case of LDP, how do > we populate mplsXCLspID's value? I do not believe it is necessary to give this object a value for LDP. The conformance statement makes this object optional. -Joan > > Thanks for your reply! > > Yuan > IP Infusion > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > Internet-Drafts@ietf.org > Sent: Monday, October 14, 2002 4:26 AM > To: IETF-Announce: > Cc: mpls@UU.NET > Subject: I-D ACTION:draft-ietf-mpls-tc-mib-04.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 : Definitions of Textual for Multiprotocol Label > Switching (MPLS) Management > Author(s) : T. Nadeau et al. > Filename : draft-ietf-mpls-tc-mib-04.txt > Pages : 18 > Date : 2002-10-11 > > This memo describes Textual Conventions for use in definitions of > management information for Multiprotocol Label Switching (MPLS) > networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-tc-mib-04.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > 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-tc-mib-04.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-tc-mib-04.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. From owner-mpls@UU.NET Thu Oct 17 02:31:10 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02172 for ; Thu, 17 Oct 2002 02:31:10 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkxu22088 for ; Thu, 17 Oct 2002 06:33:19 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkxu21203; Thu, 17 Oct 2002 06:32:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkxu03160 for mpls-outgoing; Thu, 17 Oct 2002 06:32:32 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnkxu03155 for ; Thu, 17 Oct 2002 06:32:28 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkxt16985 for ; Thu, 17 Oct 2002 06:29:37 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkxt05759 for ; Thu, 17 Oct 2002 06:29:36 GMT Received: from ganesh.ctd.hctech.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQnkxt05743 for ; Thu, 17 Oct 2002 06:29:35 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id <48ZB8MZQ>; Thu, 17 Oct 2002 11:59:24 +0530 Message-ID: <55E277B99171E041ABF5F4B1C6DDCA06A765C2@haritha.hclt.com> From: "Vijayanand C - CTD, Chennai." To: manis@futsoft.com Cc: mpls@UU.NET Subject: RE: Comments for draft-vijay-mpls-rsvpte-lspsubobject-00.txt Date: Thu, 17 Oct 2002 12:01:46 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Mani, Regarding the sending of path message over the tunnel, how else do you think it can be done, given that it has to be sent transparently without creating path state. I am not sure how its done over FA-LSPs. Is there any problem in treating the tunnel as an IP interface for the control plane and sending over it ? Regards, Vijay -----Original Message----- From: Manikantan Srinivasan [mailto:manis@futsoft.com] Sent: Tuesday, October 15, 2002 9:55 PM To: Vijayanand C - CTD, Chennai. Cc: mpls@uu.net; David Charlap Subject: RE: Comments for draft-vijay-mpls-rsvpte-lspsubobject-00.txt Vijay > > 1) Regarding the L Bit - This could be set. For instance, if the previous > node of the tunnel ingress is not mentioned in the ERO then the > node before > that can still route the path message to the tunnel ingress looking at the > tunnel ingress address if the L bit is set. The ERO processing for the LSP subject needs clarification. Can this be added in your draft, how to process the ERO object in case of Strict ERO, Loose ERO etc., > > 2) Regarding the path message sent over the tunnel- I would say that the > path message would be sent over the existing tunnel as if it were an > interface, transparent to the intermediate nodes.It would not create path > state in the intermediate nodes. I did nt mention it explicitly though. Can this be explained as well. I am not sure to which FEC, this path message (data) will be mapped to? Because the initial tunnel/LSP is created for a specific FEC. Can this be added in your draft? best regards mani From owner-mpls@UU.NET Thu Oct 17 09:28:59 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10311 for ; Thu, 17 Oct 2002 09:28:59 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkyw28265 for ; Thu, 17 Oct 2002 13:31:08 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkyw27291; Thu, 17 Oct 2002 13:30:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkyw27199 for mpls-outgoing; Thu, 17 Oct 2002 13:30:22 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnkyw27194 for ; Thu, 17 Oct 2002 13:30:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnkyv29990 for ; Thu, 17 Oct 2002 13:29:59 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkyv00952 for ; Thu, 17 Oct 2002 13:29:58 GMT Received: from blooper.utfors.se by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQnkyv00920 for ; Thu, 17 Oct 2002 13:29:57 GMT Received: from utfors.se ([212.73.0.236]) by blooper.utfors.se (8.12.6/8.12.6) with ESMTP id g9HDTL4d008021 for ; Thu, 17 Oct 2002 15:29:21 +0200 (MEST) Message-ID: <3DAEBB32.4020405@utfors.se> Date: Thu, 17 Oct 2002 15:29:22 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MPLS wg Subject: administrativia Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit All, I will be leaving my current position shortly, though mail address and the web server I used e.g. for keeping wg meeting agendas and keeping track of wg documents will continue function until further notice. However, due circumstances outside my control the web server will shortly be moved to another address, we have therefore decided to change the name of the server (from IP addressed based) to urax.utfors.net, so that when the move is executed it will work seamlessly :) Current documents are found http://urax.utfors.net/~loa/MPLS_WG_Drafts.htm http://urax.utfors.net/~loa/MPLS-agenda-for-Atlanta.htm For those of you who have bookmarked the old web page please change! /Loa -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se From owner-mpls@UU.NET Thu Oct 17 10:33:37 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12858 for ; Thu, 17 Oct 2002 10:33:37 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkza21378 for ; Thu, 17 Oct 2002 14:35:46 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkza20677; Thu, 17 Oct 2002 14:35:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkza19060 for mpls-outgoing; Thu, 17 Oct 2002 14:35:02 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnkza19051 for ; Thu, 17 Oct 2002 14:34:59 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnkza21268 for ; Thu, 17 Oct 2002 14:31:45 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkza19578 for ; Thu, 17 Oct 2002 14:31:45 GMT Received: from mail.san.yahoo.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.san.yahoo.com [209.132.1.30]) id QQnkza19559 for ; Thu, 17 Oct 2002 14:31:45 GMT Received: from [65.213.193.52] by mail.san.yahoo.com with HTTP; Thu, 17 Oct 2002 07:35:28 -0700 Date: Thu, 17 Oct 2002 10:35:28 -0400 Message-ID: <3DAB0A1300003CBF@mta08.san.yahoo.com> From: "Kavita Khanna" Subject: MPLS 2002 (www.mpls2002.com) Program Details To: mpls@UU.NET, ppvpn@ppvpn.francetelecom.com, pwe3@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA12858 The program for the MPLS 2002 International Conference (http://www.mpls2002.com) is detailed below. The conference website has been updated with abstract and bio details (http://www.mpls2002.com/sessions.htm) Tutorials - Sunday, October 27, 2002 - Introduction To MPLS: S. Poretsky, Avici Systems - Label Distribution Protocol: E. Chen & R. Aggarwal, Redback Networks - Traffic Engineering: J. Boyle, PDNets - Optical Networks: D. Awduche, Isocore Corp. - MPLS Restoration: A. Sayeed & Dr. A. Charny, Cisco Systems - GMPLS Recovery: D. Papadimitriou, Alcatel Technical Sessions - Monday, October 28, 2002 - Building a Native Data Network for Corporate VPNs: L. Andersson, Utfors - MPLS Traffic Engineering and MPLS Fast Reroute within Equant's Network: Z. Ahmad, Equant - Multi-QoS Reliable MPLS Networks: H. Komura, NTT - MPLS Interoperability: Milestones and Progress: B. Jabbari, Isocore - Providing Fast convergence and Bandwidth protection with MPLS Traffic Engineering Fast Reroute: J. P. Vasseur, Cisco Systems - Dynamics of Restoration and Convergence in MPLS/TE: C. Villamizar & R. Khanna, Avici Systems - Multi-Layer Restoration: G. Grammel, Alcatel - MPLS Resiliency and Graceful Recovery: R. Aggarwal, Redback Networks - From Pseudowires to Layer 2 VPNs: B. Davie, Cisco Systems - BGP-based Layer 2 VPNs: K. Kompella, Juniper Networks - MPLS: The missing link for delivering Metro Ethernet and ATM Services: G. Leonard, Riverstone Networks - Architectural Considerations for Delivering Scalable Transparent LAN Services (VPLS) over MPLS: S. Khandekar, TiMetra Networks - Layer 2 Interworking between Ethernet, Frame Relay, and ATM: A. Malis, Vivace Networks - A New Paradigm for Layer 3 VPNs: R. Chandra, Redback Networks - Improving the Scability of MPLS based VPNs by Extending MPLS to an Aggregation Router between PE and CE: A. Kankkunen, Tellabs - Speed, Scale, and Services at the Network Edge Using MPLS Based VPNs: E. Gray, Celox Networks - MPLS based VPNs with Voice Applications: B. Goode, ATT Technical Sessions - Tuesday, October 29, 2002 - MPLS Architecture Considerations for Operations and Management: G. Swallow, Cisco Systems - MPLS OAM: Challenges and Opportunities: D. Allan, Nortel Networks - Next Generation Network Management for MPLS-based Services: G. Dixon, Laurel Networks - Integrating NAT and Stateful Firewalls with RFC 2547-based PEs: V. Srinivasan, Cosine Communications - Warning: MPLS is not Secure: M. Barsoum, Quarry Technologies - Security and Protection of PE-CE Interface: C. Chase, ATT Technologies - Characterization and Representation of Impairements for Routing in All-Optical Networks: D.O. Awduche, Isocore - GMPLS-based Photonic Backbone Network: N. Yamanaka, NTT - Routing and Wavelength Assignment Using GMPLS: J. Lang, Calient Networks - Interoperability of O-UNI and GMPLS Protocols: Z. Ali and K. Sage, Cisco Systems - GMPLS for Hierarchical and Hybrid Optical networks: S. Araki, NEC - Packet Optical Integration: D. Fedyk, Nortel Networks - Diff-Serv-Aware MPLS Traffic Engineering and its Applications: F. Le Faucheur, Cisco Systems - Online Traffic Engineering with Design-Based Routing: I. Widjaja, I. Saniee, A. Elwalid, and D. Mitra, Lucent Technologies - MPLS QoS Performance Evaluation: K. Owens, Erlang Technologies - Characterizing MPLS based VPNs: Capabilites and Role of Core Routers: R. Papneja, Avici Systems and V. Sharma, Metanoia, Inc. - Traffic Engineering Considerations in GMPLS Networks: Y. Xue - Emerging New GMPLS-based Optical VPNs: H. Ould-Brahim, Nortel Networks - The Emergence of a Multiprotocol Core: A. Missing, Alcatel From owner-mpls@UU.NET Thu Oct 17 10:44:01 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13201 for ; Thu, 17 Oct 2002 10:44:01 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkzb05271 for ; Thu, 17 Oct 2002 14:46:12 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkzb04271; Thu, 17 Oct 2002 14:45:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkzb19933 for mpls-outgoing; Thu, 17 Oct 2002 14:45:18 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnkzb19925 for ; Thu, 17 Oct 2002 14:45:12 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnkza15378 for ; Thu, 17 Oct 2002 14:44:27 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkza03091 for ; Thu, 17 Oct 2002 14:44:27 GMT Received: from dnsmx1pya.telcordia.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31]) id QQnkza03085 for ; Thu, 17 Oct 2002 14:44:27 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id KAA14132 for ; Thu, 17 Oct 2002 10:43:51 -0400 (EDT) Subject: Can anyone give me a point: RSVP te question for section 4.7.4 To: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Hong Liao" Date: Thu, 17 Oct 2002 10:43:50 -0400 X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 10/17/2002 10:43:52 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi all, I have two questions for section 4.7.4. 1) if the three tests mentioned in this section fail, should router send a patherr msg with the error code 'routing problem' or error code 'policy control failure'? I think it should be the error code 'routing problem'. 2) In the spec and this section, it was not clear that what kind of value should be put in the 'link-attr', 'exclude-any', 'include-any','include-any' in order to trigger the router to generate the patherr msg above. I would like to know how to set the value in this field, and give me an example on how to create this scenario with what kind of value in these fields? Thanks in an advance for your help. Julia From owner-mpls@UU.NET Thu Oct 17 14:21:27 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20598 for ; Thu, 17 Oct 2002 14:21:27 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkzp20410 for ; Thu, 17 Oct 2002 18:23:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkzp18644; Thu, 17 Oct 2002 18:22:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkzp09652 for mpls-outgoing; Thu, 17 Oct 2002 18:22:37 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnkzp09637 for ; Thu, 17 Oct 2002 18:22:23 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnkzp24715 for ; Thu, 17 Oct 2002 18:21:02 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkzp16759 for ; Thu, 17 Oct 2002 18:21:02 GMT Received: from gateway.ipinfusion.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.ipinfusion.com [65.223.109.2]) id QQnkzp16748 for ; Thu, 17 Oct 2002 18:21:01 GMT Received: from YuanHong (dhcp123.ipinfusion.com [10.10.0.123] (may be forged)) by gateway.ipinfusion.com (8.11.6/8.11.6) with SMTP id g9HIIhW10613; Thu, 17 Oct 2002 11:18:43 -0700 From: "Yuan Gu" To: "Thomas D. Nadeau" , , , , Cc: "mpls group" Subject: FW: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt Date: Thu, 17 Oct 2002 11:19:34 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-4" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dear MPLS-TC-MIB authors: Could you please give me a clearify of my following questions? From my point of view, the MplsLSPID defined in this MIB obvoiusly conflict with the RSVP-TE LSP identification principle. What do you think? Regards! Yuan -----Original Message----- From: Yuan Gu [mailto:YuanGu@ipinfusion.com] Sent: Monday, October 14, 2002 11:11 AM To: mpls group Subject: RE: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt Hi: I have two questions of MplsLSPID defined in this MIB: 1. It states in this MIB: (MplsLSPId): "A unique identifier within an MPLS network that is assigned to each LSP. This is assigned at the head end of the LSP and can be used by all LSRs to identify this LSP...For LSPs signaled using RSVP-TE, the LSP ID is defined as a 16-bit (2 byte) identifier used in the SENDER_TEMPLATE..." My question is: How does a head end LSR assign a "MPLS network unique" LSPID for a LSP in case the signaling is RSVP-TE? In RFC3209, it says: "The SENDER_TEMPLATE object together with the session object uniquely identifies an LSP tunnel." Does MplsLSPId definition conflict with RFC3209? 2. A "mplsXCLspId" object is defined in XC table of LSR MIB while MplsLSPId is only used for CR-LDP and RSVP-TE. My question is: In case of LDP, how do we populate mplsXCLspID's value? Thanks for your reply! Yuan IP Infusion -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Internet-Drafts@ietf.org Sent: Monday, October 14, 2002 4:26 AM To: IETF-Announce: Cc: mpls@UU.NET Subject: I-D ACTION:draft-ietf-mpls-tc-mib-04.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 : Definitions of Textual for Multiprotocol Label Switching (MPLS) Management Author(s) : T. Nadeau et al. Filename : draft-ietf-mpls-tc-mib-04.txt Pages : 18 Date : 2002-10-11 This memo describes Textual Conventions for use in definitions of management information for Multiprotocol Label Switching (MPLS) networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tc-mib-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-tc-mib-04.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-tc-mib-04.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. From owner-mpls@UU.NET Thu Oct 17 15:01:38 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22917 for ; Thu, 17 Oct 2002 15:01:37 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkzs00562 for ; Thu, 17 Oct 2002 19:03:47 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkzs28951; Thu, 17 Oct 2002 19:03:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkzs21277 for mpls-outgoing; Thu, 17 Oct 2002 19:02:37 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnkzs21261 for ; Thu, 17 Oct 2002 19:02:35 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkzs08005 for ; Thu, 17 Oct 2002 19:00:39 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkzs17645 for ; Thu, 17 Oct 2002 19:00:39 GMT Received: from zcars04e.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQnkzs17628 for ; Thu, 17 Oct 2002 19:00:38 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9HJ0aL29607 for ; Thu, 17 Oct 2002 15:00:37 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Oct 2002 15:00:37 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C05A9AC87@zcard031.ca.nortel.com> From: "David Allan" To: mpls@UU.NET Subject: MORE: Latest MPLS Ping draft... Date: Thu, 17 Oct 2002 15:00:33 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk A few more comments: Section 3: What are the procedures if "reply via control plane" is requested for an LSP set up with LDP? (presumably some error results) Any plans for IPv6 reply modes? How about "return subcode MUST be set to zero."? Section 3.2: I'm unable to understand this explanation. Should the statement be "...compute which LSRs could receive the packet with TTL=n-1...." as in "what is the set of reasonable next hops?". Or is it "which LSR will receive this packet with TTL=n-1..." as in "if there are multiple NHLFEs, which one would this specific probe resolve to?". I believe I asked this last time around (00 version) and did not get an answer. A re-write of this paragraph would be useful. Section 4.2 If the probe is not well formed... presumably the reply mode for the error is as requested (incl. no reply)? Section 4.2: "if the echo request is good...is valid for the FEC....if not L MAY log this fact. " Seems to me that this fact is relatively useless unless all the circumstances associated with the test (in particular what 127. address was used by the echo request and who the probe originated with) are logged. Otherwise a craftsperson may be obliged to do extensive testing to reproduce the circumstances of the test. And if one is using "no reply" mode, the stipluation should be stronger than a "MAY". thx Dave From owner-mpls@UU.NET Thu Oct 17 16:44:00 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25583 for ; Thu, 17 Oct 2002 16:44:00 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkzz16875 for ; Thu, 17 Oct 2002 20:46:09 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkzy13270; Thu, 17 Oct 2002 20:44:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkzy21517 for mpls-outgoing; Thu, 17 Oct 2002 20:44:17 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnkzy21501 for ; Thu, 17 Oct 2002 20:44:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnkzy05745 for ; Thu, 17 Oct 2002 20:41:12 GMT From: jcucchiara@mindspring.com Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkzy01004 for ; Thu, 17 Oct 2002 20:41:12 GMT Received: from smtp6.mindspring.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp6.mindspring.com [207.69.200.110]) id QQnkzy00988 for ; Thu, 17 Oct 2002 20:41:11 GMT Received: from dialup-63.214.99.230.dial1.boston1.level3.net ([63.214.99.230] helo=jluciani-laptop) by smtp6.mindspring.com with smtp (Exim 3.33 #1) id 182HQj-00013B-00; Thu, 17 Oct 2002 16:39:41 -0400 Message-Id: <3.0.1.32.20021017164954.007170f0@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 17 Oct 2002 16:49:54 -0400 To: "Yuan Gu" , "Thomas D. Nadeau" , , , , Subject: Re: FW: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt Cc: "mpls group" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk At 11:19 AM 10/17/02 -0700, Yuan Gu wrote: >Dear MPLS-TC-MIB authors: Yuan, Please note my email address has changed and is now: jcucchiara@mindspring.com. > >Could you please give me a clearify of my following questions? From my point >of view, the MplsLSPID defined in this MIB obvoiusly conflict with the >RSVP-TE LSP identification principle. What do you think? I do not believe this conflicts, as I said before. > >Regards! >Yuan > >-----Original Message----- >From: Yuan Gu [mailto:YuanGu@ipinfusion.com] >Sent: Monday, October 14, 2002 11:11 AM >To: mpls group >Subject: RE: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt > > >Hi: > >I have two questions of MplsLSPID defined in this MIB: > >1. It states in this MIB: >(MplsLSPId): "A unique identifier within an MPLS network that is assigned to >each LSP. This is assigned at the head end of the LSP and can be used by all >LSRs to identify this LSP...For LSPs signaled using RSVP-TE, the LSP ID is >defined as a 16-bit (2 byte) identifier used in the SENDER_TEMPLATE..." >My question is: How does a head end LSR assign a "MPLS network unique" LSPID >for a LSP in case the signaling is RSVP-TE? In RFC3209, it says: "The >SENDER_TEMPLATE object together with the session object uniquely identifies >an LSP tunnel." Does MplsLSPId definition conflict with RFC3209? Although, it may be necessary to clarify this a tad, I don't believe there is a conflict. Perhaps, this description should simply state: For RSVP, the MplsLSPId is the "LSP ID" as defined in RFC3209. The reason that I believe there is no conflict is because if there is a reroute, a new LSP ID is created by the ingress node and thus a new SENDER_TEMPLATE. This new SENDER_TEMPLATE along with the original SESSION object is used in establishing a new LSP. > >2. A "mplsXCLspId" object is defined in XC table of LSR MIB while MplsLSPId >is only used for CR-LDP and RSVP-TE. My question is: In case of LDP, how do >we populate mplsXCLspID's value? > In the case of LDP it does not apply. Since the mplsXCLspId object is optional in the conformance statements, the easiest thing is to not support this object at all. Thus, you don't have to worry about a valid value for it. -Joan >Thanks for your reply! > >Yuan >IP Infusion > >-----Original Message----- >From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of >Internet-Drafts@ietf.org >Sent: Monday, October 14, 2002 4:26 AM >To: IETF-Announce: >Cc: mpls@UU.NET >Subject: I-D ACTION:draft-ietf-mpls-tc-mib-04.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 : Definitions of Textual for Multiprotocol Label > Switching (MPLS) Management > Author(s) : T. Nadeau et al. > Filename : draft-ietf-mpls-tc-mib-04.txt > Pages : 18 > Date : 2002-10-11 > >This memo describes Textual Conventions for use in definitions of >management information for Multiprotocol Label Switching (MPLS) >networks. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-mpls-tc-mib-04.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >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-tc-mib-04.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-tc-mib-04.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. > > From owner-mpls@UU.NET Thu Oct 17 16:58:37 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25928 for ; Thu, 17 Oct 2002 16:58:37 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlaa06687 for ; Thu, 17 Oct 2002 21:00:46 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnkzz05311; Thu, 17 Oct 2002 20:59:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQnkzz22945 for mpls-outgoing; Thu, 17 Oct 2002 20:59:34 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnkzz22940 for ; Thu, 17 Oct 2002 20:59:24 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnkzz00053 for ; Thu, 17 Oct 2002 20:58:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnkzz03233 for ; Thu, 17 Oct 2002 20:58:07 GMT Received: from gateway.ipinfusion.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.ipinfusion.com [65.223.109.2]) id QQnkzz03217 for ; Thu, 17 Oct 2002 20:58:06 GMT Received: from YuanHong (dhcp123.ipinfusion.com [10.10.0.123] (may be forged)) by gateway.ipinfusion.com (8.11.6/8.11.6) with SMTP id g9HKtjW14818; Thu, 17 Oct 2002 13:55:45 -0700 From: "Yuan Gu" To: , "Thomas D. Nadeau" , , , , Cc: "mpls group" Subject: RE: FW: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt Date: Thu, 17 Oct 2002 13:56:37 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-reply-to: <3.0.1.32.20021017164954.007170f0@pop.mindspring.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit >Although, it may be necessary to clarify this a tad, I don't >believe there is a conflict. Perhaps, this description >should simply state: >For RSVP, the MplsLSPId is the "LSP ID" as defined in RFC3209. Then for RSVP-TE, what's the sense to define LSP ID in XC table? This two bytes LSPID can't identify an unique LSP. Don't need to mention transit node, even within single ingress node it's not unique right? From owner-mpls@UU.NET Fri Oct 18 07:07:07 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20978 for ; Fri, 18 Oct 2002 07:07:07 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlce18267 for ; Fri, 18 Oct 2002 11:09:18 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnlce17010; Fri, 18 Oct 2002 11:08:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQnlce05214 for mpls-outgoing; Fri, 18 Oct 2002 11:07:55 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnlce05183 for ; Fri, 18 Oct 2002 11:07:44 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnlce10813 for ; Fri, 18 Oct 2002 11:05:43 GMT From: neil.2.harrison@bt.com Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlce05718 for ; Fri, 18 Oct 2002 11:05:43 GMT Received: from cbibipnt08.hc.bt.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQnlce05711 for ; Fri, 18 Oct 2002 11:05:42 GMT Received: by cbibipnt08.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Fri, 18 Oct 2002 11:49:44 +0100 Message-ID: To: mpls@UU.NET Subject: RE: Latest MPLS Ping draft... Date: Fri, 18 Oct 2002 11:49:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Some general and specific observations on the latest draft 01. General comments: ----------------- 1 There are (at least) 3 phases to consider: (i) automatic detection of defects (ii) automatic consequent actions on detecting defects (these may differ between different defect types) (iii) ad hoc diagnostic tools to investigate anomalous behaviour (esp where such tools are either too complex/processing-intensive or are simply not needed in the general 80/20 case) The draft does not identify/specify any defects, and therefore by inference does not give any (automatic) consequent actions. This is not a criticism per se, just an observation of its limitations. It therefore falls more naturally in the ad hoc diagnostics category. 2 IP/cnls networks cannot suffer from the same defects as a MPLS network. This is because an IP pkt contains full source/destination addresses, ie each/every pkt contains it's own 'connectivity verification' handle that is networkwide unique. LDP LSPs however use only link-local unique identifiers to effect hop-by-hop routing. It is therefore possible for MPLS networks to misdirect traffic that will not 'self-correct' any misrouting (as it would in the IP case). When using link-local identifiers one should consider all these defects: - simple breaks - swapped connections - traffic from LSP A leaking into LSP B say (in simplest case involving only 2 LSPs), which has 2 modes: * LSP A traffic is otherwise unaffected, ie despite misbranching into LSP B, LSP A's traffic also carries on to its proper destination....so there is no indication of problems on LSP A and only LSP B is affected * LSP A suffers a break, ie as a consequence of misbranching into LSP B, LSP A's traffic does not carry on towards its proper destination, so here both LSP A and LSP B are affected. The need to specify these defects (in terms of entry/exit criteria and consequent actions) is required in Y.1710 and very simple techniques are given in Y.1711 as solutions for the p2p case. These defects should ideally also be specified for the mp2p case of LDP. Besides the obvious need for operators to be able to detect/handle these defects automatically, there are other reasons why this is required, such as: - the need to suppress traffic where necessary to protect customer traffic confidentially, eg swapped LSPs; - in cases such as ATMoverMPLS the need to provide indications (from the LSP sink point where the defect is detected/handled) to the client (ATM here) network in order to suppress alarm storms at the sink points of the client network trails (these may be in a different operator network to the MPLS network and potentially terminate at many geographically diverse locations); - to get some common ground for interworking between vendors and/or between operators its clearly important to have common specifications for defects and their handling. If this is not possible (for whatever reasons, eg mechanisms defined or network technology considered) then these limitations should be indicated so that operators can understand the scope of application. 3 If we can't define standardised defects for whatever reasons, then there are further limitations that should also be noted: - it will not be possible to specify standardised availability entry/exit criteria - it will not be possible to specify standardised QoS objectives, and in particular their apportionments across operator domains.....this arises since one needs the availability 'up-time' datum against which QoS metric collection is valid, ie collection of such metrics against long-term QoS objectives should be suppressed during unavailability. Note - the above are not meant as criticisms of the LSP-Ping mechanism per se (indeed I think its a useful diagnostic tool), they are merely observations of the limitations of its scope.....esp in the context of mp2p LSP constructs, which is probably the more limiting factor here. Specific comments on the draft: ------------------------------- 4 Towards the end of section 2 the draft talks about '....periodically ping a FEC...' and 'If a ping fails...'. I think its fine to leave these undefined like this so long as we agree that LSP-Ping is really a diagnostics tool, and will have limitations wrt its scope as a defect detection/handling tool or for any consequential use in measuring availability/QoS. However, if this is not the case then I think well-defined defect specifications (for the reasons given previously) will be required .....if this is indeed possible. 5 I was not clear why the opening sentence of section 3 says '...a (possibly) labelled UDP packet.' (a similar sentence appears at the start of section 4.1). I thought the intention was to exercise the data-plane of the outgoing LSP and so the pkts MUST be labelled. Can you please clarify what is meant here? 6 In section 3 the 'Reply Mode' field is only specified for IPv4 packets. Is there any reason the possible use of IPv6 packets has been omitted here, ie when using LSP-Ping in an IPv6 network? 7 Section 3.3 discusses the 'Pad TLV'......what is the intended use of this? 8 In section 5 reliable return paths are discussed. Agreed that defect detection/diagnosis/handling is a problem when attempted as a bidirectional function. When used with RSVP signalled p2p LSPs, I note there is an option to use the RSVP return LSP RESV message to carry back information of other direction Pings. Two observations: - forced coupling with a specific signalling protocol.....this is not a good idea IMO, the data-plane defect handling ought to look after itself independently of the control-plane routing/signalling protocols being used; - will only detect simple breaks, eg if pkts leaking out of forward direction of LSP there will not be a return RSVP instantiated LSP (to wherever they end up) to indicate this defect exists..........this will require the LSR where the pkts end up to use an IP return mode to detect. Given this, why bother with having a RSVP return mode in the 1st place....just use the IP-only return mode in all cases? BTW - when we are dealing with p2p entities, like an ER LSP, consideration should be given to the use of the less complex and more powerful techniques given in Y.1711....esp so in case of non-IP client layers. That's all the comments I have for now. thanks and regards, Neil From owner-mpls@UU.NET Fri Oct 18 13:55:01 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04883 for ; Fri, 18 Oct 2002 13:55:00 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnldf22736 for ; Fri, 18 Oct 2002 17:57:13 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnldf21772; Fri, 18 Oct 2002 17:56:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQnldf10452 for mpls-outgoing; Fri, 18 Oct 2002 17:56:21 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnldf10379 for ; Fri, 18 Oct 2002 17:56:09 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnldf27779 for ; Fri, 18 Oct 2002 17:55:27 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnldf14081 for ; Fri, 18 Oct 2002 17:55:27 GMT Received: from dnsmx1rrc.telcordia.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1rrc.telcordia.com [128.96.20.41]) id QQnldf14072 for ; Fri, 18 Oct 2002 17:55:27 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with ESMTP id NAA16612 for ; Fri, 18 Oct 2002 13:55:16 -0400 (EDT) Subject: Can anyone answer my questions? To: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Hong Liao" Date: Fri, 18 Oct 2002 13:55:10 -0400 X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 10/18/2002 01:55:20 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk "Hong Liao" cc: (bcc: Hong Liao/Telcordia) Subject: Can anyone give me a point: RSVP te question for 10/17/02 section 4.7.4 10:43 AM Hi all, I have two questions for section 4.7.4. 1) if the three tests mentioned in this section fail, should router send a patherr msg with the error code 'routing problem' or error code 'policy control failure'? I think it should be the error code 'routing problem'. 2) In the spec and this section, it was not clear that what kind of value should be put in the 'link-attr', 'exclude-any', 'include-any','include-any' in order to trigger the router to generate the patherr msg above. I would like to know how to set the value in this field, and give me an example on how to create this scenario with what kind of value in these fields? Thanks in an advance for your help. Julia From owner-mpls@UU.NET Fri Oct 18 14:53:19 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06889 for ; Fri, 18 Oct 2002 14:53:18 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnldj16887 for ; Fri, 18 Oct 2002 18:55:28 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnldj15510; Fri, 18 Oct 2002 18:54:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQnldj01190 for mpls-outgoing; Fri, 18 Oct 2002 18:53:59 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnldj01185 for ; Fri, 18 Oct 2002 18:53:44 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnldj27993 for ; Fri, 18 Oct 2002 18:49:40 GMT From: jcucchiara@mindspring.com Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnldj27353 for ; Fri, 18 Oct 2002 18:49:39 GMT Received: from mclean.mail.mindspring.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mclean.mail.mindspring.net [207.69.200.57]) id QQnldj27341 for ; Fri, 18 Oct 2002 18:49:39 GMT Received: from dialup-63.214.105.230.dial1.boston1.level3.net ([63.214.105.230] helo=jluciani-laptop) by mclean.mail.mindspring.net with smtp (Exim 3.33 #1) id 182cBd-0004kr-00; Fri, 18 Oct 2002 14:49:29 -0400 Message-Id: <3.0.1.32.20021018145912.0071c010@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 18 Oct 2002 14:59:12 -0400 To: "Yuan Gu" , "Thomas D. Nadeau" , , , Subject: RE: FW: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt Cc: "mpls group" In-Reply-To: References: <3.0.1.32.20021017164954.007170f0@pop.mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hi Yuan, At 01:56 PM 10/17/02 -0700, Yuan Gu wrote: > >>Although, it may be necessary to clarify this a tad, I don't >>believe there is a conflict. Perhaps, this description >>should simply state: >>For RSVP, the MplsLSPId is the "LSP ID" as defined in RFC3209. > >Then for RSVP-TE, what's the sense to define LSP ID in XC table? This two >bytes LSPID can't identify an unique LSP. Don't need to mention transit >node, even within single ingress node it's not unique right? > Okay, I think I see your point. The object does allow an operator to configure the LSP-ID, (and show the LSPID in the transit situation). Also, this object is optional so doesn't need to be supported by the agent. Do you think this object is not worth having in this table at all, even optionally? Thanks, Joan From owner-mpls@UU.NET Fri Oct 18 15:24:50 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07722 for ; Fri, 18 Oct 2002 15:24:50 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnldl00213 for ; Fri, 18 Oct 2002 19:27:00 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnldl29029; Fri, 18 Oct 2002 19:26:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQnldl20122 for mpls-outgoing; Fri, 18 Oct 2002 19:26:02 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnldl20054 for ; Fri, 18 Oct 2002 19:25:44 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnldl04741 for ; Fri, 18 Oct 2002 19:23:25 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnldl14343 for ; Fri, 18 Oct 2002 19:23:24 GMT Received: from gateway.ipinfusion.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.ipinfusion.com [65.223.109.2]) id QQnldl14297 for ; Fri, 18 Oct 2002 19:23:23 GMT Received: from YuanHong (dhcp123.ipinfusion.com [10.10.0.123] (may be forged)) by gateway.ipinfusion.com (8.11.6/8.11.6) with SMTP id g9IJLpW09374; Fri, 18 Oct 2002 12:21:51 -0700 From: "Yuan Gu" To: , "Thomas D. Nadeau" , , , Cc: "mpls group" Subject: RE: FW: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt Date: Fri, 18 Oct 2002 12:22:40 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3.0.1.32.20021018145912.0071c010@pop.mindspring.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Joan: Thanks for you reply. For LspID which is defined in XC table, it's still worth to have it because some vendors might not support TE mib and want to show which LSP makes the cross connection. The problem is that the current MplsLSPId definition can't uniquely identify an LSP for RSVP-TE case. Then, we need to extend MplsLSPId concept to make it not limited by lspid defined in SenderTemple of RFC3209. For RSVP-TE case, I believe we can define MplsLSPId as ingressLSRID+egressLSRID+tunnelid+lspid (similar as CRLDP definition). By this way, LSR mib will have a unique identification of LSP which makes insegment, XC and outsegment entries. Please let me know your thought. Regards! Yuan -----Original Message----- From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com] Sent: Friday, October 18, 2002 11:59 AM To: Yuan Gu; Thomas D. Nadeau; cheenu@paramanet.com; arun@force10networks.com; hans@ipunplugged.com Cc: mpls group Subject: RE: FW: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt Hi Yuan, At 01:56 PM 10/17/02 -0700, Yuan Gu wrote: > >>Although, it may be necessary to clarify this a tad, I don't >>believe there is a conflict. Perhaps, this description >>should simply state: >>For RSVP, the MplsLSPId is the "LSP ID" as defined in RFC3209. > >Then for RSVP-TE, what's the sense to define LSP ID in XC table? This two >bytes LSPID can't identify an unique LSP. Don't need to mention transit >node, even within single ingress node it's not unique right? > Okay, I think I see your point. The object does allow an operator to configure the LSP-ID, (and show the LSPID in the transit situation). Also, this object is optional so doesn't need to be supported by the agent. Do you think this object is not worth having in this table at all, even optionally? Thanks, Joan From owner-mpls@UU.NET Fri Oct 18 16:25:30 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08991 for ; Fri, 18 Oct 2002 16:25:30 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnldp10860 for ; Fri, 18 Oct 2002 20:27:39 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnldp09101; Fri, 18 Oct 2002 20:26:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQnldp10901 for mpls-outgoing; Fri, 18 Oct 2002 20:26:04 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnldp10834 for ; Fri, 18 Oct 2002 20:25:57 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnldp01827 for ; Fri, 18 Oct 2002 20:24:48 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnldp04265 for ; Fri, 18 Oct 2002 20:24:47 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQnldp04244 for ; Fri, 18 Oct 2002 20:24:47 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA21357 for ; Fri, 18 Oct 2002 16:24:44 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA22889 for ; Fri, 18 Oct 2002 16:24:45 -0400 (EDT) Message-ID: <3DB06E15.6040102@marconi.com> Date: Fri, 18 Oct 2002 16:24:53 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: IETF MPLS List Subject: Re: Can anyone answer my questions? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hong Liao wrote: > > I have two questions for section 4.7.4. > > 1) if the three tests mentioned in this section fail, should router send a > patherr msg with the error code 'routing problem' or error code 'policy > control failure'? > I think it should be the error code 'routing problem'. That's what section 4.7.4 says: For a link to be acceptable, all three tests MUST pass. If the test fails, the node SHOULD send a PathErr message with an error code of "Routing Problem" and an error value of "no route available toward destination". > 2) In the spec and this section, it was not clear that what kind of value > should be put in the 'link-attr', 'exclude-any', > 'include-any','include-any' in order to trigger the router to generate the > patherr msg above. I would like to know how to set the value in this > field, and give me an example on how to create this scenario with what kind > of value in these fields? Every link has attributes configured. Other routers learn them through routing. If an ingress node cares about the attributes, it will generate an ERO that sends the LSP over links that match the required criteria. It will also set the resource affinities in the session attributes so that transit nodes can validate the locally-configured attributes against those requirements. When choosing an egress interface, a router must choose one such that none of the "exclude-any" bits correspond with the link's configured bits, at least one of the "include-any" bits corresponds with the link's configured bits, and all of the "include-all" bits correspond with the link's configured bits. Validating a link (fetched from an ERO or from routing) against an interface's attribute bits is easy. Using these bits as part of the criterial for choosing a link may be more complicated, depending on what kind of routing features your box supports. -- David From owner-mpls@UU.NET Fri Oct 18 22:09:01 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14907 for ; Fri, 18 Oct 2002 22:09:00 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlem27403 for ; Sat, 19 Oct 2002 02:11:09 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnlem26382; Sat, 19 Oct 2002 02:10:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQnlem09452 for mpls-outgoing; Sat, 19 Oct 2002 02:10:21 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnlem09443 for ; Sat, 19 Oct 2002 02:10:20 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnlem26060 for ; Sat, 19 Oct 2002 02:10:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlem19487 for ; Sat, 19 Oct 2002 02:10:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnlem19460 for ; Sat, 19 Oct 2002 02:10:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA11021 for ; Fri, 18 Oct 2002 22:10:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9J2A1G01038 for mpls@uu.net; Fri, 18 Oct 2002 22:10:01 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnlem08951 for ; Sat, 19 Oct 2002 02:06:50 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnlem20000 for ; Sat, 19 Oct 2002 02:02:44 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlem19246 for ; Sat, 19 Oct 2002 02:02:43 GMT Received: from web13506.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web13506.mail.yahoo.com [216.136.175.85]) id QQnlem19235 for ; Sat, 19 Oct 2002 02:02:43 GMT Message-ID: <20021019020242.50648.qmail@web13506.mail.yahoo.com> Received: from [63.67.101.5] by web13506.mail.yahoo.com via HTTP; Fri, 18 Oct 2002 19:02:42 PDT Date: Fri, 18 Oct 2002 19:02:42 -0700 (PDT) From: Vishal M Subject: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) To: mpls@UU.NET In-Reply-To: <20020821212735.52221.qmail@web13505.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, If someone wants to use MPLS over ethernet and support DiffServ extensions for MPLS (i.e MPLS DS TE), can one still choose between using E-LSP or L-LSPs ? The reason for the doubt is: The Ethernet header (like ATM) doesn't have any QoS information field (unless 802.1q is supported). So does that imply that E-LSP can't be used when ethernet is the underlying media (and 802.1q is not supported). Is L-LSP the only choice then? Thanks for your inputs, Regards, Vishal. __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ From owner-mpls@UU.NET Fri Oct 18 22:37:16 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15448 for ; Fri, 18 Oct 2002 22:37:16 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnleo22471 for ; Sat, 19 Oct 2002 02:39:26 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnleo21326; Sat, 19 Oct 2002 02:38:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQnleo12292 for mpls-outgoing; Sat, 19 Oct 2002 02:38:36 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnleo12287 for ; Sat, 19 Oct 2002 02:38:28 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnleo25026 for ; Sat, 19 Oct 2002 02:37:02 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnleo20216 for ; Sat, 19 Oct 2002 02:37:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnleo20210 for ; Sat, 19 Oct 2002 02:37:01 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA11878 for ; Fri, 18 Oct 2002 22:37:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9J2b1202934 for mpls@uu.net; Fri, 18 Oct 2002 22:37:01 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnleo12066 for ; Sat, 19 Oct 2002 02:35:15 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnleo09122 for ; Sat, 19 Oct 2002 02:34:49 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnleo22590 for ; Sat, 19 Oct 2002 02:34:49 GMT Received: from web13504.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web13504.mail.yahoo.com [216.136.175.83]) id QQnleo22586 for ; Sat, 19 Oct 2002 02:34:49 GMT Message-ID: <20021019023448.54902.qmail@web13504.mail.yahoo.com> Received: from [63.67.101.6] by web13504.mail.yahoo.com via HTTP; Fri, 18 Oct 2002 19:34:48 PDT Date: Fri, 18 Oct 2002 19:34:48 -0700 (PDT) From: Vishal M Subject: Ques on RFC 3270 (MPLS Support for DiffServ) To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hello, Question on RFC 3270 (MPLS Support for DiffServ), Section 1.5: The second paragraph explains about the relationship between FEC and set of BAs... Why don't we consider the concept of packet ordering constaint (i.e. OA) for an E-LSP (say, E-LSP1 and E-LSP2) ? Assuming we have two E-LSPs from the same source (S) to the same destination (D). Now if an incoming multimedia packet stream from single source (of voice and video traffic) is to be sent to destination (D), is it possible to send voice traffic onto E-LSP1 and video onto E-LSP2 ? Why in this section, we have associated OAs with L-LSPs only (and not with E-LSPs)? Thanks for all the inputs and pointers, Regards, Vishal. __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ From owner-mpls@UU.NET Mon Oct 21 01:20:52 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09206 for ; Mon, 21 Oct 2002 01:20:52 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlmj01925 for ; Mon, 21 Oct 2002 05:23:04 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnlmj01255; Mon, 21 Oct 2002 05:22:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQnlmj11512 for mpls-outgoing; Mon, 21 Oct 2002 05:22:26 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnlmj11507 for ; Mon, 21 Oct 2002 05:22:19 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnlmj14782 for ; Mon, 21 Oct 2002 05:21:36 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlmj00568 for ; Mon, 21 Oct 2002 05:21:36 GMT Received: from ganesh.ctd.hctech.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQnlmj00552 for ; Mon, 21 Oct 2002 05:21:34 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id <48ZCAKGR>; Mon, 21 Oct 2002 10:52:07 +0530 Message-ID: <55E277B99171E041ABF5F4B1C6DDCA06AAFB2C@haritha.hclt.com> From: "Vijayanand C - CTD, Chennai." To: Yuan Gu Cc: mpls group Subject: RE: FW: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt Date: Mon, 21 Oct 2002 10:53:44 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Yuan, The LSP Identifier for RSVP-TE is considered to be a 5 tuple - ingressLSRID+egressLSRID+tunnelid+lspid+ Extended tunnel ID. Though the extended tunnel ID is usually zero or the ingress LSRID, it could be any IP address of the ingress LSR. Discussions on this have happened in this list. Regards, Vijay -----Original Message----- From: Yuan Gu [mailto:YuanGu@ipinfusion.com] Sent: Saturday, October 19, 2002 12:53 AM To: jcucchiara@mindspring.com; Thomas D. Nadeau; cheenu@paramanet.com; arun@force10networks.com; hans@ipunplugged.com Cc: mpls group Subject: RE: FW: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt Joan: Thanks for you reply. For LspID which is defined in XC table, it's still worth to have it because some vendors might not support TE mib and want to show which LSP makes the cross connection. The problem is that the current MplsLSPId definition can't uniquely identify an LSP for RSVP-TE case. Then, we need to extend MplsLSPId concept to make it not limited by lspid defined in SenderTemple of RFC3209. For RSVP-TE case, I believe we can define MplsLSPId as ingressLSRID+egressLSRID+tunnelid+lspid (similar as CRLDP definition). By this way, LSR mib will have a unique identification of LSP which makes insegment, XC and outsegment entries. Please let me know your thought. Regards! Yuan -----Original Message----- From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com] Sent: Friday, October 18, 2002 11:59 AM To: Yuan Gu; Thomas D. Nadeau; cheenu@paramanet.com; arun@force10networks.com; hans@ipunplugged.com Cc: mpls group Subject: RE: FW: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt Hi Yuan, At 01:56 PM 10/17/02 -0700, Yuan Gu wrote: > >>Although, it may be necessary to clarify this a tad, I don't >>believe there is a conflict. Perhaps, this description >>should simply state: >>For RSVP, the MplsLSPId is the "LSP ID" as defined in RFC3209. > >Then for RSVP-TE, what's the sense to define LSP ID in XC table? This two >bytes LSPID can't identify an unique LSP. Don't need to mention transit >node, even within single ingress node it's not unique right? > Okay, I think I see your point. The object does allow an operator to configure the LSP-ID, (and show the LSPID in the transit situation). Also, this object is optional so doesn't need to be supported by the agent. Do you think this object is not worth having in this table at all, even optionally? Thanks, Joan From owner-mpls@UU.NET Mon Oct 21 02:21:51 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19349 for ; Mon, 21 Oct 2002 02:21:51 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlmn22510 for ; Mon, 21 Oct 2002 06:24:03 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnlmn21692; Mon, 21 Oct 2002 06:23:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQnlmn02022 for mpls-outgoing; Mon, 21 Oct 2002 06:22:45 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnlmn02017 for ; Mon, 21 Oct 2002 06:22:33 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnlmn09650 for ; Mon, 21 Oct 2002 06:22:31 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlmn20434 for ; Mon, 21 Oct 2002 06:22:31 GMT Received: from wiprom2mx1.wipro.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQnlmn20382 for ; Mon, 21 Oct 2002 06:22:28 GMT Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g9L6MPn09101 for ; Mon, 21 Oct 2002 11:52:26 +0530 (IST) Received: from soflt.ipneg.wipro.com ([10.117.3.193]) by kmglmail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id H4BJ1D00.60X; Mon, 21 Oct 2002 11:52:25 +0530 Date: Mon, 21 Oct 2002 11:50:02 +0530 (IST) From: "chetan kumar s" X-X-Sender: Reply-To: To: David Charlap cc: IETF MPLS List Subject: Re: Can anyone answer my questions? In-Reply-To: <3DB06E15.6040102@marconi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Fri, 18 Oct 2002, David Charlap wrote: > Hong Liao wrote: > > Hi, This question has arised due to the fact that RFC has both errors mentioned in the section 4.7.4. But however many ppl follow the most obvious error "Routing Problem". I do not understand why authors had mentioned both the error in this section.. Well is there any implementation that use "policy control failure" Thanks Chetan S > > I have two questions for section 4.7.4. > > > > 1) if the three tests mentioned in this section fail, should router send a > > patherr msg with the error code 'routing problem' or error code 'policy > > control failure'? > > I think it should be the error code 'routing problem'. > > That's what section 4.7.4 says: > > For a link to be acceptable, all three tests MUST pass. If > the test fails, the node SHOULD send a PathErr message with > an error code of "Routing Problem" and an error value of > "no route available toward destination". > > > 2) In the spec and this section, it was not clear that what kind of value > > should be put in the 'link-attr', 'exclude-any', > > 'include-any','include-any' in order to trigger the router to generate the > > patherr msg above. I would like to know how to set the value in this > > field, and give me an example on how to create this scenario with what kind > > of value in these fields? > > Every link has attributes configured. Other routers learn them through > routing. > > If an ingress node cares about the attributes, it will generate an ERO > that sends the LSP over links that match the required criteria. It will > also set the resource affinities in the session attributes so that > transit nodes can validate the locally-configured attributes against > those requirements. > > When choosing an egress interface, a router must choose one such that > none of the "exclude-any" bits correspond with the link's configured > bits, at least one of the "include-any" bits corresponds with the link's > configured bits, and all of the "include-all" bits correspond with the > link's configured bits. > > Validating a link (fetched from an ERO or from routing) against an > interface's attribute bits is easy. Using these bits as part of the > criterial for choosing a link may be more complicated, depending on what > kind of routing features your box supports. > > -- David > -- ------------ Thinking is progress, non thinking is destruction of individual, organization and nation -Abdul Kalam From owner-mpls@UU.NET Mon Oct 21 08:11:32 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24825 for ; Mon, 21 Oct 2002 08:11:32 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlnk14778 for ; Mon, 21 Oct 2002 12:13:45 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnlnk13408; Mon, 21 Oct 2002 12:13:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQnlnk04890 for mpls-outgoing; Mon, 21 Oct 2002 12:12:46 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnlnk04881 for ; Mon, 21 Oct 2002 12:12:32 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnlnk21786 for ; Mon, 21 Oct 2002 12:11:04 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlnk12403 for ; Mon, 21 Oct 2002 12:11:04 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnlnk12378 for ; Mon, 21 Oct 2002 12:11:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA03846 for ; Mon, 21 Oct 2002 08:11:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9LCB2A07647 for mpls@uu.net; Mon, 21 Oct 2002 08:11:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnlnk03979 for ; Mon, 21 Oct 2002 12:10:08 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnlnk18550 for ; Mon, 21 Oct 2002 12:07:58 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlnk09052 for ; Mon, 21 Oct 2002 12:07:58 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQnlnk08978 for ; Mon, 21 Oct 2002 12:07:52 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24381; Mon, 21 Oct 2002 08:05:31 -0400 (EDT) Message-Id: <200210211205.IAA24381@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; CC: mpls@UU.NET, ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ash-e2e-crtp-hdr-compress-00.txt Date: Mon, 21 Oct 2002 08:05:31 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : End-to-End VoIP Header Compression Using cRTP Author(s) : J. Ash, B. Goode, J. Hand Filename : draft-ash-e2e-crtp-hdr-compress-00.txt Pages : 9 Date : 2002-10-18 VoIP typically uses the encapsulation voice/RTP/UDP/IP, wherein the packet header is at least 40 bytes, while the voice payload is typically no more than 30 bytes. VoIP header compression can significantly reduce the VoIP overhead through various compression mechanisms. This is important on access links where bandwidth is scarce, and can be important on backbone facilities, especially where costs are high (e.g., some global cross-sections). In this draft we propose to re-use the methods in cRTP to determine the header compression context and to use the cRTP session context ID to route a compressed packet between the ingress and egress routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ash-e2e-crtp-hdr-compress-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ash-e2e-crtp-hdr-compress-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-ash-e2e-crtp-hdr-compress-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: <2002-10-18132118.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ash-e2e-crtp-hdr-compress-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ash-e2e-crtp-hdr-compress-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-18132118.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Oct 21 08:13:34 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24865 for ; Mon, 21 Oct 2002 08:13:33 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlnl22684 for ; Mon, 21 Oct 2002 12:15:48 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnlnk12985; Mon, 21 Oct 2002 12:11:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQnlnk04677 for mpls-outgoing; Mon, 21 Oct 2002 12:11:26 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnlnk04672 for ; Mon, 21 Oct 2002 12:11:22 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnlnk22330 for ; Mon, 21 Oct 2002 12:11:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlnk12390 for ; Mon, 21 Oct 2002 12:11:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnlnk12373 for ; Mon, 21 Oct 2002 12:11:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA03842 for ; Mon, 21 Oct 2002 08:11:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9LCB2107637 for mpls@uu.net; Mon, 21 Oct 2002 08:11:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnlnk03898 for ; Mon, 21 Oct 2002 12:09:45 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnlnk18518 for ; Mon, 21 Oct 2002 12:08:27 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlnk09526 for ; Mon, 21 Oct 2002 12:08:26 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQnlnk09522 for ; Mon, 21 Oct 2002 12:08:26 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24541; Mon, 21 Oct 2002 08:06:10 -0400 (EDT) Message-Id: <200210211206.IAA24541@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-rsvp-unnum-08.txt Date: Mon, 21 Oct 2002 08:06:10 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --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 : Signalling Unnumbered Links in RSVP-TE Author(s) : K. Kompella, Y. Rekhter Filename : draft-ietf-mpls-rsvp-unnum-08.txt Pages : 9 Date : 2002-10-18 Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) doesn't provide support for unnumbered links. This document defines procedures and extensions to Extensions to RSVP for Label Switched Path (LSP) Tunnels (RSVP-TE), one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-unnum-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-unnum-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-rsvp-unnum-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-18132246.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-rsvp-unnum-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-rsvp-unnum-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-18132246.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Oct 21 10:19:58 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29790 for ; Mon, 21 Oct 2002 10:19:58 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlnt07374 for ; Mon, 21 Oct 2002 14:22:11 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnlnt06281; Mon, 21 Oct 2002 14:21:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQnlnt16574 for mpls-outgoing; Mon, 21 Oct 2002 14:21:07 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnlnt16566 for ; Mon, 21 Oct 2002 14:20:54 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnlnt16926 for ; Mon, 21 Oct 2002 14:15:59 GMT From: jcucchiara@mindspring.com Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlnt22821 for ; Mon, 21 Oct 2002 14:15:59 GMT Received: from mclean.mail.mindspring.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mclean.mail.mindspring.net [207.69.200.57]) id QQnlnt22816 for ; Mon, 21 Oct 2002 14:15:58 GMT Received: from dialup-63.214.124.5.dial1.boston1.level3.net ([63.214.124.5] helo=jluciani-laptop) by mclean.mail.mindspring.net with smtp (Exim 3.33 #1) id 183dL7-0008TO-00; Mon, 21 Oct 2002 10:15:30 -0400 Message-Id: <3.0.1.32.20021021101808.007213b4@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 21 Oct 2002 10:18:08 -0400 To: "Yuan Gu" , "Thomas D. Nadeau" , , , Subject: RE: FW: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt Cc: "mpls group" In-Reply-To: References: <3.0.1.32.20021018145912.0071c010@pop.mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hi Yuan, I will take your suggestion and discuss it with the co-authors of the LSR MIB. Thanks, Joan At 12:22 PM 10/18/02 -0700, Yuan Gu wrote: >Joan: > >Thanks for you reply. > >For LspID which is defined in XC table, it's still worth to have it because >some vendors might not support TE mib and want to show which LSP makes the >cross connection. The problem is that the current MplsLSPId definition can't >uniquely identify an LSP for RSVP-TE case. Then, we need to extend MplsLSPId >concept to make it not limited by lspid defined in SenderTemple of RFC3209. >For RSVP-TE case, I believe we can define MplsLSPId as >ingressLSRID+egressLSRID+tunnelid+lspid (similar as CRLDP definition). By >this way, LSR mib will have a unique identification of LSP which makes >insegment, XC and outsegment entries. > >Please let me know your thought. > >Regards! >Yuan > >-----Original Message----- >From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com] >Sent: Friday, October 18, 2002 11:59 AM >To: Yuan Gu; Thomas D. Nadeau; cheenu@paramanet.com; >arun@force10networks.com; hans@ipunplugged.com >Cc: mpls group >Subject: RE: FW: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt > > > >Hi Yuan, > >At 01:56 PM 10/17/02 -0700, Yuan Gu wrote: >> >>>Although, it may be necessary to clarify this a tad, I don't >>>believe there is a conflict. Perhaps, this description >>>should simply state: >>>For RSVP, the MplsLSPId is the "LSP ID" as defined in RFC3209. >> >>Then for RSVP-TE, what's the sense to define LSP ID in XC table? This two >>bytes LSPID can't identify an unique LSP. Don't need to mention transit >>node, even within single ingress node it's not unique right? >> > >Okay, I think I see your point. >The object does allow an operator to configure the >LSP-ID, (and show the LSPID in the transit situation). >Also, this object is optional so doesn't need to be supported by >the agent. > >Do you think this object is not worth having in this table at all, >even optionally? > > Thanks, Joan > > > > > From owner-mpls@UU.NET Mon Oct 21 10:42:50 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01215 for ; Mon, 21 Oct 2002 10:42:49 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlnu22135 for ; Mon, 21 Oct 2002 14:44:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnlnu20175; Mon, 21 Oct 2002 14:43:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQnlnu17906 for mpls-outgoing; Mon, 21 Oct 2002 14:43:03 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnlnu17899 for ; Mon, 21 Oct 2002 14:42:50 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnlnu04146 for ; Mon, 21 Oct 2002 14:40:10 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlnu17879 for ; Mon, 21 Oct 2002 14:40:10 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnlnu17857 for ; Mon, 21 Oct 2002 14:40:09 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA13863 for ; Mon, 21 Oct 2002 10:40:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9LEe3e16331 for mpls@uu.net; Mon, 21 Oct 2002 10:40:03 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnlnu17677 for ; Mon, 21 Oct 2002 14:39:36 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnlnu29358 for ; Mon, 21 Oct 2002 14:33:15 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlnu13649 for ; Mon, 21 Oct 2002 14:33:15 GMT Received: from mother.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQnlnu13643 for ; Mon, 21 Oct 2002 14:33:15 GMT Received: (qmail 21436 invoked by uid 104); 21 Oct 2002 14:32:46 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4229. . Clean. Processed in 0.513317 secs); 21 Oct 2002 14:32:46 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 21 Oct 2002 14:32:45 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g9LEWiQ04325; Mon, 21 Oct 2002 07:32:45 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id <40J3G5XF>; Mon, 21 Oct 2002 07:32:44 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB039FD@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Vishal M'" , mpls@UU.NET Subject: RE: Ques on RFC 3270 (MPLS Support for DiffServ) Date: Mon, 21 Oct 2002 07:32:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk The label in L-LSP represents only a single OA, while the label in E-LSP may represent: - A single BA - A single OA - A number of BAs - A number of OAs - A number of BAs and OAs " A set of BAs" is a generic term that applies to all the above cases. -Shahram > -----Original Message----- > From: Vishal M [mailto:vishal_study@yahoo.com] > Sent: Friday, October 18, 2002 10:35 PM > To: mpls@UU.NET > Subject: Ques on RFC 3270 (MPLS Support for DiffServ) > > > > Hello, > > Question on RFC 3270 (MPLS Support for DiffServ), > Section 1.5: > > The second paragraph explains about the relationship > between FEC and set of BAs... > > Why don't we consider the concept of packet ordering > constaint (i.e. OA) for an E-LSP (say, E-LSP1 and > E-LSP2) ? > > Assuming we have two E-LSPs from the same source (S) > to the same destination (D). Now if an incoming > multimedia packet stream from single source (of voice > and video traffic) is to be sent to destination (D), > is it possible to send voice traffic onto E-LSP1 and > video onto E-LSP2 ? > > Why in this section, we have associated OAs with > L-LSPs only (and not with E-LSPs)? > > Thanks for all the inputs and pointers, > > Regards, > Vishal. > > > > __________________________________________________ > Do you Yahoo!? > Y! Web Hosting - Let the expert host your web site > http://webhosting.yahoo.com/ > From owner-mpls@UU.NET Mon Oct 21 11:11:13 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02250 for ; Mon, 21 Oct 2002 11:11:08 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlnw28698 for ; Mon, 21 Oct 2002 15:13:16 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnlnw26788; Mon, 21 Oct 2002 15:12:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQnlnw07752 for mpls-outgoing; Mon, 21 Oct 2002 15:11:43 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnlnw07744 for ; Mon, 21 Oct 2002 15:11:26 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnlnw21669 for ; Mon, 21 Oct 2002 15:10:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlnw06452 for ; Mon, 21 Oct 2002 15:10:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnlnw06441 for ; Mon, 21 Oct 2002 15:10:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA18111 for ; Mon, 21 Oct 2002 11:10:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9LFA2m19557 for mpls@uu.net; Mon, 21 Oct 2002 11:10:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnlnw07181 for ; Mon, 21 Oct 2002 15:08:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnlnw22762 for ; Mon, 21 Oct 2002 15:06:12 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlnw20987 for ; Mon, 21 Oct 2002 15:06:12 GMT Received: from mother.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQnlnw20979 for ; Mon, 21 Oct 2002 15:06:11 GMT Received: (qmail 28490 invoked by uid 104); 21 Oct 2002 14:46:10 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4229. . Clean. Processed in 1.674604 secs); 21 Oct 2002 14:46:10 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 21 Oct 2002 14:46:08 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g9LEk8Q08609; Mon, 21 Oct 2002 07:46:08 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id <40J3G50X>; Mon, 21 Oct 2002 07:46:08 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB039FE@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Vishal M'" , mpls@UU.NET Subject: RE: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) Date: Mon, 21 Oct 2002 07:45:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Diffserv is not supported for non-802.1q networks. -Shahram > -----Original Message----- > From: Vishal M [mailto:vishal_study@yahoo.com] > Sent: Friday, October 18, 2002 10:03 PM > To: mpls@UU.NET > Subject: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) > > > > Hi, > > If someone wants to use MPLS over ethernet and support > DiffServ extensions for MPLS (i.e MPLS DS TE), can one > still choose between using E-LSP or L-LSPs ? > > The reason for the doubt is: > The Ethernet header (like ATM) doesn't have any QoS > information field (unless 802.1q is supported). So > does that imply that E-LSP can't be used when ethernet > is the underlying media (and 802.1q is not supported). > > Is L-LSP the only choice then? > > Thanks for your inputs, > > Regards, > Vishal. > > > __________________________________________________ > Do you Yahoo!? > Y! Web Hosting - Let the expert host your web site > http://webhosting.yahoo.com/ > From owner-mpls@UU.NET Mon Oct 21 11:20:19 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02590 for ; Mon, 21 Oct 2002 11:20:19 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlnx19753 for ; Mon, 21 Oct 2002 15:22:33 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnlnx18576; Mon, 21 Oct 2002 15:22:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQnlnx09241 for mpls-outgoing; Mon, 21 Oct 2002 15:21:19 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnlnx09231 for ; Mon, 21 Oct 2002 15:21:05 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnlnx25386 for ; Mon, 21 Oct 2002 15:20:32 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlnx18971 for ; Mon, 21 Oct 2002 15:20:31 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQnlnx18967 for ; Mon, 21 Oct 2002 15:20:31 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT8Q3B>; Mon, 21 Oct 2002 11:20:31 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B0267EC02@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'Shahram Davari'" , mpls@UU.NET Subject: RE: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) Date: Mon, 21 Oct 2002 11:20:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Shahram, I am not sure why you say this. Certainly we can support Differentiated IP services, over MPLS, without the need to rely on Layer 2 priority or VLAN capability. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Monday, October 21, 2002 10:46 AM > To: 'Vishal M'; mpls@UU.NET > Subject: RE: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) > > Diffserv is not supported for non-802.1q networks. > > -Shahram > > > -----Original Message----- > > From: Vishal M [mailto:vishal_study@yahoo.com] > > Sent: Friday, October 18, 2002 10:03 PM > > To: mpls@UU.NET > > Subject: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) > > > > > > > > Hi, > > > > If someone wants to use MPLS over ethernet and support > > DiffServ extensions for MPLS (i.e MPLS DS TE), can one > > still choose between using E-LSP or L-LSPs ? > > > > The reason for the doubt is: > > The Ethernet header (like ATM) doesn't have any QoS > > information field (unless 802.1q is supported). So > > does that imply that E-LSP can't be used when ethernet > > is the underlying media (and 802.1q is not supported). > > > > Is L-LSP the only choice then? > > > > Thanks for your inputs, > > > > Regards, > > Vishal. > > > > > > __________________________________________________ > > Do you Yahoo!? > > Y! Web Hosting - Let the expert host your web site > > http://webhosting.yahoo.com/ > > From owner-mpls@UU.NET Mon Oct 21 11:37:25 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03261 for ; Mon, 21 Oct 2002 11:37:25 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlny09607 for ; Mon, 21 Oct 2002 15:39:35 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnlny07710; Mon, 21 Oct 2002 15:38:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQnlny11295 for mpls-outgoing; Mon, 21 Oct 2002 15:37:58 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnlny11288 for ; Mon, 21 Oct 2002 15:37:48 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnlny00345 for ; Mon, 21 Oct 2002 15:33:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlny03663 for ; Mon, 21 Oct 2002 15:33:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnlny03656 for ; Mon, 21 Oct 2002 15:33:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA19846 for ; Mon, 21 Oct 2002 11:33:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9LFX2O22346 for mpls@uu.net; Mon, 21 Oct 2002 11:33:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnlny10078 for ; Mon, 21 Oct 2002 15:31:31 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnlnx08702 for ; Mon, 21 Oct 2002 15:27:47 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlnx28911 for ; Mon, 21 Oct 2002 15:27:47 GMT Received: from father.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQnlnx28897 for ; Mon, 21 Oct 2002 15:27:46 GMT Received: (qmail 4668 invoked by uid 104); 21 Oct 2002 15:27:46 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4229. . Clean. Processed in 0.499792 secs); 21 Oct 2002 15:27:45 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 21 Oct 2002 15:27:45 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g9LFRiQ22681; Mon, 21 Oct 2002 08:27:45 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id <40J3G6XW>; Mon, 21 Oct 2002 08:27:44 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03A00@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Gray, Eric'" , mpls@UU.NET Subject: RE: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) Date: Mon, 21 Oct 2002 08:27:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Eric, There are 2 types of MPLS over Ethernet: 1) The LSRs are routers but happen to have Ethernet interfaces, in that case what you said is correct, we don't need the 802.1q since the MPLS label carries all the Diffserv Info. 2) The LSRs are Ethernet switches loaded with MPLS control-plane, (like ATM-LSRs). In that case the Ethernet switches need to have the capability for Diffserv queuing (aka 802.1q). -Shahram > -----Original Message----- > From: Gray, Eric [mailto:egray@celoxnetworks.com] > Sent: Monday, October 21, 2002 11:20 AM > To: Shahram Davari; mpls@UU.NET > Subject: RE: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) > > > Shahram, > > I am not sure why you say this. Certainly we > can support Differentiated IP services, over MPLS, > without the need to rely on Layer 2 priority or VLAN > capability. > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Monday, October 21, 2002 10:46 AM > > To: 'Vishal M'; mpls@UU.NET > > Subject: RE: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) > > > > Diffserv is not supported for non-802.1q networks. > > > > -Shahram > > > > > -----Original Message----- > > > From: Vishal M [mailto:vishal_study@yahoo.com] > > > Sent: Friday, October 18, 2002 10:03 PM > > > To: mpls@UU.NET > > > Subject: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) > > > > > > > > > > > > Hi, > > > > > > If someone wants to use MPLS over ethernet and support > > > DiffServ extensions for MPLS (i.e MPLS DS TE), can one > > > still choose between using E-LSP or L-LSPs ? > > > > > > The reason for the doubt is: > > > The Ethernet header (like ATM) doesn't have any QoS > > > information field (unless 802.1q is supported). So > > > does that imply that E-LSP can't be used when ethernet > > > is the underlying media (and 802.1q is not supported). > > > > > > Is L-LSP the only choice then? > > > > > > Thanks for your inputs, > > > > > > Regards, > > > Vishal. > > > > > > > > > __________________________________________________ > > > Do you Yahoo!? > > > Y! Web Hosting - Let the expert host your web site > > > http://webhosting.yahoo.com/ > > > > From owner-mpls@UU.NET Mon Oct 21 12:57:24 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05877 for ; Mon, 21 Oct 2002 12:57:23 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlod24048 for ; Mon, 21 Oct 2002 16:59:34 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnlod22626; Mon, 21 Oct 2002 16:58:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQnlod03192 for mpls-outgoing; Mon, 21 Oct 2002 16:58:18 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnlod03186 for ; Mon, 21 Oct 2002 16:58:08 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnlod25197 for ; Mon, 21 Oct 2002 16:55:08 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlod15583 for ; Mon, 21 Oct 2002 16:55:08 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnlod15569 for ; Mon, 21 Oct 2002 16:55:07 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA26609 for ; Mon, 21 Oct 2002 12:55:07 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9LGt6c28170 for mpls@uu.net; Mon, 21 Oct 2002 12:55:06 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnlod02837 for ; Mon, 21 Oct 2002 16:54:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnlod23412 for ; Mon, 21 Oct 2002 16:53:15 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlod17823 for ; Mon, 21 Oct 2002 16:53:15 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnlod17798 for ; Mon, 21 Oct 2002 16:53:14 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA16144; Mon, 21 Oct 2002 12:51:36 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200210211651.MAA16144@workhorse.fictitious.org> To: Shahram Davari cc: "'Vishal M'" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) In-reply-to: Your message of "Mon, 21 Oct 2002 07:45:56 PDT." <4B6D09F3B826D411A67300D0B706EFDEB039FE@nt-exch-yow.pmc-sierra.bc.ca> Date: Mon, 21 Oct 2002 12:51:35 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4B6D09F3B826D411A67300D0B706EFDEB039FE@nt-exch-yow.pmc-sierra.bc.ca >, Shahram Davari writes: > Diffserv is not supported for non-802.1q networks. > > -Shahram Shahram, Diffserv works perfectly fine on non-802.1q point to point links (which is quite common in ISP POPs). It also happens to work if you are using GbE or 10GbE in a aggregation or access application where the circuits feeding in are lower speed. This only works because the sum of all feeds is significantly less than the GbE/10GbE bandwidth. This is just a minor clarification and generally your statement "Diffserv is not supported for non-802.1q networks" is true. Point to point ethernet links and constrained feed bandwidth in ISP aggregation or access POPs can be considered special cases. The point is that some ISPs are using GbE/10GbE with diffserv and without 802.1q, though admitedly in special situations. Curtis > > -----Original Message----- > > From: Vishal M [mailto:vishal_study@yahoo.com] > > Sent: Friday, October 18, 2002 10:03 PM > > To: mpls@UU.NET > > Subject: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) > > > > > > > > Hi, > > > > If someone wants to use MPLS over ethernet and support > > DiffServ extensions for MPLS (i.e MPLS DS TE), can one > > still choose between using E-LSP or L-LSPs ? > > > > The reason for the doubt is: > > The Ethernet header (like ATM) doesn't have any QoS > > information field (unless 802.1q is supported). So > > does that imply that E-LSP can't be used when ethernet > > is the underlying media (and 802.1q is not supported). > > > > Is L-LSP the only choice then? > > > > Thanks for your inputs, > > > > Regards, > > Vishal. > > > > > > __________________________________________________ > > Do you Yahoo!? > > Y! Web Hosting - Let the expert host your web site > > http://webhosting.yahoo.com/ From owner-mpls@UU.NET Mon Oct 21 13:06:13 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06077 for ; Mon, 21 Oct 2002 13:06:13 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnloe06803 for ; Mon, 21 Oct 2002 17:08:25 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnloe05124; Mon, 21 Oct 2002 17:07:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQnloe19630 for mpls-outgoing; Mon, 21 Oct 2002 17:07:00 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnloe19599 for ; Mon, 21 Oct 2002 17:06:51 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnloe03173 for ; Mon, 21 Oct 2002 17:03:04 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnloe22577 for ; Mon, 21 Oct 2002 17:03:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnloe22567 for ; Mon, 21 Oct 2002 17:03:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA27265 for ; Mon, 21 Oct 2002 13:03:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9LH32628728 for mpls@uu.net; Mon, 21 Oct 2002 13:03:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnloe08679 for ; Mon, 21 Oct 2002 17:01:08 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnlod27685 for ; Mon, 21 Oct 2002 16:57:52 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlod23186 for ; Mon, 21 Oct 2002 16:57:51 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnlod23167 for ; Mon, 21 Oct 2002 16:57:50 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA16163; Mon, 21 Oct 2002 12:56:15 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200210211656.MAA16163@workhorse.fictitious.org> To: "Gray, Eric" cc: "'Shahram Davari'" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) In-reply-to: Your message of "Mon, 21 Oct 2002 11:20:28 EDT." <1117F7D44159934FB116E36F4ABF221B0267EC02@celox-ma1-ems1.celoxnetworks.com> Date: Mon, 21 Oct 2002 12:56:13 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <1117F7D44159934FB116E36F4ABF221B0267EC02@celox-ma1-ems1.celoxnetwor ks.com>, "Gray, Eric" writes: > Shahram, > > I am not sure why you say this. Certainly we > can support Differentiated IP services, over MPLS, > without the need to rely on Layer 2 priority or VLAN > capability. > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 It works fine until you put an ethernet switch in place and try to put more than 1 Gb over a 1 GbE. This is true for any situation where more than one ingress going through the switch to one egreess. If there are no ethernet switches (that being layer2 devices, don't do MPLS) then you don't need Layer 2 priority. That would be true for point to point ethernets between LSR. Curtis > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Monday, October 21, 2002 10:46 AM > > To: 'Vishal M'; mpls@UU.NET > > Subject: RE: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) > > > > Diffserv is not supported for non-802.1q networks. > > > > -Shahram > > > > > -----Original Message----- > > > From: Vishal M [mailto:vishal_study@yahoo.com] > > > Sent: Friday, October 18, 2002 10:03 PM > > > To: mpls@UU.NET > > > Subject: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) > > > > > > > > > > > > Hi, > > > > > > If someone wants to use MPLS over ethernet and support > > > DiffServ extensions for MPLS (i.e MPLS DS TE), can one > > > still choose between using E-LSP or L-LSPs ? > > > > > > The reason for the doubt is: > > > The Ethernet header (like ATM) doesn't have any QoS > > > information field (unless 802.1q is supported). So > > > does that imply that E-LSP can't be used when ethernet > > > is the underlying media (and 802.1q is not supported). > > > > > > Is L-LSP the only choice then? > > > > > > Thanks for your inputs, > > > > > > Regards, > > > Vishal. > > > > > > > > > __________________________________________________ > > > Do you Yahoo!? > > > Y! Web Hosting - Let the expert host your web site > > > http://webhosting.yahoo.com/ > > > > From owner-mpls@UU.NET Mon Oct 21 13:10:15 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06225 for ; Mon, 21 Oct 2002 13:10:14 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnloe12238 for ; Mon, 21 Oct 2002 17:12:26 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnloe10954; Mon, 21 Oct 2002 17:11:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQnloe20869 for mpls-outgoing; Mon, 21 Oct 2002 17:11:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnloe20852 for ; Mon, 21 Oct 2002 17:11:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnloe10903 for ; Mon, 21 Oct 2002 17:11:00 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnloe10033 for ; Mon, 21 Oct 2002 17:11:00 GMT Received: from antivir1 by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [192.114.163.163]) id QQnloe09978 for ; Mon, 21 Oct 2002 17:10:57 GMT Received: from 192.168.254.14 by antivir1 (InterScan E-Mail VirusWall NT); Mon, 21 Oct 2002 19:10:48 +0200 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id <469H3AJZ>; Mon, 21 Oct 2002 19:09:40 +0200 Message-ID: From: Sasha Vainshtein To: "'curtis@fictitious.org'" Cc: "'Vishal M'" , mpls@UU.NET, Shahram Davari Subject: RE: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) Date: Mon, 21 Oct 2002 19:09:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-8" Sender: owner-mpls@UU.NET Precedence: bulk Curtis and all, Can you provide any suggestions/pointers as to how DiffServ and 802.1q markings should be mapped? Because, IMHO, just having 802.1q is not enough, you should decide how to use it. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > Sent: Monday, October 21, 2002 6:52 PM > To: Shahram Davari > Cc: 'Vishal M'; mpls@UU.NET > Subject: Re: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) > > > > In message > <4B6D09F3B826D411A67300D0B706EFDEB039FE@nt-exch-yow.pmc-sierra.bc.ca > >, Shahram Davari writes: > > Diffserv is not supported for non-802.1q networks. > > > > -Shahram > > > Shahram, > > Diffserv works perfectly fine on non-802.1q point to point links > (which is quite common in ISP POPs). It also happens to work if you > are using GbE or 10GbE in a aggregation or access application where > the circuits feeding in are lower speed. This only works because the > sum of all feeds is significantly less than the GbE/10GbE bandwidth. > > This is just a minor clarification and generally your statement > "Diffserv is not supported for non-802.1q networks" is true. Point to > point ethernet links and constrained feed bandwidth in ISP aggregation > or access POPs can be considered special cases. > > The point is that some ISPs are using GbE/10GbE with diffserv and > without 802.1q, though admitedly in special situations. > > Curtis > > > > > -----Original Message----- > > > From: Vishal M [mailto:vishal_study@yahoo.com] > > > Sent: Friday, October 18, 2002 10:03 PM > > > To: mpls@UU.NET > > > Subject: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) > > > > > > > > > > > > Hi, > > > > > > If someone wants to use MPLS over ethernet and support > > > DiffServ extensions for MPLS (i.e MPLS DS TE), can one > > > still choose between using E-LSP or L-LSPs ? > > > > > > The reason for the doubt is: > > > The Ethernet header (like ATM) doesn't have any QoS > > > information field (unless 802.1q is supported). So > > > does that imply that E-LSP can't be used when ethernet > > > is the underlying media (and 802.1q is not supported). > > > > > > Is L-LSP the only choice then? > > > > > > Thanks for your inputs, > > > > > > Regards, > > > Vishal. > > > > > > > > > __________________________________________________ > > > Do you Yahoo!? > > > Y! Web Hosting - Let the expert host your web site > > > http://webhosting.yahoo.com/ > From owner-mpls@UU.NET Mon Oct 21 13:15:54 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06545 for ; Mon, 21 Oct 2002 13:15:54 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlof10314 for ; Mon, 21 Oct 2002 17:18:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnlof09115; Mon, 21 Oct 2002 17:17:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQnlof21657 for mpls-outgoing; Mon, 21 Oct 2002 17:17:12 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnlof21652 for ; Mon, 21 Oct 2002 17:17:09 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnlof25486 for ; Mon, 21 Oct 2002 17:16:30 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlof20321 for ; Mon, 21 Oct 2002 17:16:30 GMT Received: from gateway.ipinfusion.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.ipinfusion.com [65.223.109.2]) id QQnlof20310 for ; Mon, 21 Oct 2002 17:16:29 GMT Received: from YuanHong (dhcp123.ipinfusion.com [10.10.0.123] (may be forged)) by gateway.ipinfusion.com (8.11.6/8.11.6) with SMTP id g9LHFKW03781; Mon, 21 Oct 2002 10:15:20 -0700 From: "Yuan Gu" To: "Vijayanand C - CTD, Chennai." Cc: "mpls group" Subject: RE: FW: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt Date: Mon, 21 Oct 2002 10:15:53 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-4" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <55E277B99171E041ABF5F4B1C6DDCA06AAFB2C@haritha.hclt.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Vijay: Thanks for you response. I understand your point. Please notice that current MPLS MIB definition does not make distinguish between ingressLSRID and Extended tunnelID. This might be inappropriate but it's been decided by the MIB authors. I make this proposal from MIB stand point of view. Regards! Yuan -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Vijayanand C - CTD, Chennai. Sent: Sunday, October 20, 2002 10:24 PM To: Yuan Gu Cc: mpls group Subject: RE: FW: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt Yuan, The LSP Identifier for RSVP-TE is considered to be a 5 tuple - ingressLSRID+egressLSRID+tunnelid+lspid+ Extended tunnel ID. Though the extended tunnel ID is usually zero or the ingress LSRID, it could be any IP address of the ingress LSR. Discussions on this have happened in this list. Regards, Vijay -----Original Message----- From: Yuan Gu [mailto:YuanGu@ipinfusion.com] Sent: Saturday, October 19, 2002 12:53 AM To: jcucchiara@mindspring.com; Thomas D. Nadeau; cheenu@paramanet.com; arun@force10networks.com; hans@ipunplugged.com Cc: mpls group Subject: RE: FW: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt Joan: Thanks for you reply. For LspID which is defined in XC table, it's still worth to have it because some vendors might not support TE mib and want to show which LSP makes the cross connection. The problem is that the current MplsLSPId definition can't uniquely identify an LSP for RSVP-TE case. Then, we need to extend MplsLSPId concept to make it not limited by lspid defined in SenderTemple of RFC3209. For RSVP-TE case, I believe we can define MplsLSPId as ingressLSRID+egressLSRID+tunnelid+lspid (similar as CRLDP definition). By this way, LSR mib will have a unique identification of LSP which makes insegment, XC and outsegment entries. Please let me know your thought. Regards! Yuan -----Original Message----- From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com] Sent: Friday, October 18, 2002 11:59 AM To: Yuan Gu; Thomas D. Nadeau; cheenu@paramanet.com; arun@force10networks.com; hans@ipunplugged.com Cc: mpls group Subject: RE: FW: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt Hi Yuan, At 01:56 PM 10/17/02 -0700, Yuan Gu wrote: > >>Although, it may be necessary to clarify this a tad, I don't >>believe there is a conflict. Perhaps, this description >>should simply state: >>For RSVP, the MplsLSPId is the "LSP ID" as defined in RFC3209. > >Then for RSVP-TE, what's the sense to define LSP ID in XC table? This two >bytes LSPID can't identify an unique LSP. Don't need to mention transit >node, even within single ingress node it's not unique right? > Okay, I think I see your point. The object does allow an operator to configure the LSP-ID, (and show the LSPID in the transit situation). Also, this object is optional so doesn't need to be supported by the agent. Do you think this object is not worth having in this table at all, even optionally? Thanks, Joan From owner-mpls@UU.NET Mon Oct 21 13:39:49 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07621 for ; Mon, 21 Oct 2002 13:39:48 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlog15350 for ; Mon, 21 Oct 2002 17:41:59 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnlog13852; Mon, 21 Oct 2002 17:41:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQnlog22909 for mpls-outgoing; Mon, 21 Oct 2002 17:40:51 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnlog22902 for ; Mon, 21 Oct 2002 17:40:45 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnlog23743 for ; Mon, 21 Oct 2002 17:38:35 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlog10908 for ; Mon, 21 Oct 2002 17:38:35 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQnlog10903 for ; Mon, 21 Oct 2002 17:38:34 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT8RG3>; Mon, 21 Oct 2002 13:38:34 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B0267EC04@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'curtis@fictitious.org'" Cc: "'Shahram Davari'" , mpls@UU.NET Subject: RE: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) Date: Mon, 21 Oct 2002 13:38:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Curtis, See below... Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 > --- [snip] --- > > > It works fine until you put an ethernet switch in place and try to put > more than 1 Gb over a 1 GbE. This is true for any situation where > more than one ingress going through the switch to one egreess. Realistically speaking, how often do you expect to see Ethernet switches being used between LSRs within an MPLS domain? In the (possibly rare) case where this occurs, how likely is it that such a switch is MPLS unaware? > > If there are no ethernet switches (that being layer2 devices, don't do > MPLS) then you don't need Layer 2 priority. That would be true for > point to point ethernets between LSR. > > Curtis > > > > > --- [snip] --- From owner-mpls@UU.NET Mon Oct 21 13:44:34 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07784 for ; Mon, 21 Oct 2002 13:44:34 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnloh11022 for ; Mon, 21 Oct 2002 17:46:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnloh09425; Mon, 21 Oct 2002 17:45:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQnloh23473 for mpls-outgoing; Mon, 21 Oct 2002 17:45:28 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnloh23454 for ; Mon, 21 Oct 2002 17:45:12 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnlog15948 for ; Mon, 21 Oct 2002 17:44:14 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlog07904 for ; Mon, 21 Oct 2002 17:44:13 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnlog07890 for ; Mon, 21 Oct 2002 17:44:13 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA00852 for ; Mon, 21 Oct 2002 13:44:12 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9LHiC202771 for mpls@uu.net; Mon, 21 Oct 2002 13:44:12 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnlog23096 for ; Mon, 21 Oct 2002 17:41:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnlog27654 for ; Mon, 21 Oct 2002 17:38:50 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlog03986 for ; Mon, 21 Oct 2002 17:38:50 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnlog03967 for ; Mon, 21 Oct 2002 17:38:49 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id NAA16422; Mon, 21 Oct 2002 13:37:10 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200210211737.NAA16422@workhorse.fictitious.org> To: Sasha Vainshtein cc: "'curtis@fictitious.org'" , "'Vishal M'" , mpls@UU.NET, Shahram Davari Reply-To: curtis@fictitious.org Subject: Re: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) In-reply-to: Your message of "Mon, 21 Oct 2002 19:09:37 +0200." Date: Mon, 21 Oct 2002 13:37:10 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , Sasha Vainshtein writ es: > Curtis and all, > Can you provide any suggestions/pointers as to how DiffServ and > 802.1q markings should be mapped? > Because, IMHO, just having 802.1q is not enough, you should decide > how to use it. I'm not a big fan of 802.1q. Mapping EXP into 802.1q signaling is straightforward. This mapping is sufficient for unsignaled E-LSP. The mapping of 802.1q priorities to packet treatment is not straightforward. I'd argue that what most switches are capable of doing with 802.1q priorities does not support diffserv, particularly AF, L-LSPs, or signaled E-LSPs. For AF service, the EXP bits must be modified even for unsignaled E-LSPs so any switch relying solely on 802.1q signaling is inherently broken wrt AF service. > With best regards, > Sasha Vainshtein I haven't kept up with what ethernet switches are doing in this regard. Shahram may be better able to answer this. Curtis From owner-mpls@UU.NET Mon Oct 21 13:56:46 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08197 for ; Mon, 21 Oct 2002 13:56:46 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnloh18883 for ; Mon, 21 Oct 2002 17:58:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnloh16446; Mon, 21 Oct 2002 17:57:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQnloh24777 for mpls-outgoing; Mon, 21 Oct 2002 17:57:11 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnloh24772 for ; Mon, 21 Oct 2002 17:57:10 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnloh26912 for ; Mon, 21 Oct 2002 17:57:05 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnloh23551 for ; Mon, 21 Oct 2002 17:57:05 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnloh23542 for ; Mon, 21 Oct 2002 17:57:04 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA02310 for ; Mon, 21 Oct 2002 13:57:04 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9LHv4N04440 for mpls@uu.net; Mon, 21 Oct 2002 13:57:04 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnloh24545 for ; Mon, 21 Oct 2002 17:55:56 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnloh13181 for ; Mon, 21 Oct 2002 17:52:53 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnloh01228 for ; Mon, 21 Oct 2002 17:52:53 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnloh01215 for ; Mon, 21 Oct 2002 17:52:52 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id NAA16587; Mon, 21 Oct 2002 13:51:18 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200210211751.NAA16587@workhorse.fictitious.org> To: "Gray, Eric" cc: "'curtis@fictitious.org'" , "'Shahram Davari'" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) In-reply-to: Your message of "Mon, 21 Oct 2002 13:38:28 EDT." <1117F7D44159934FB116E36F4ABF221B0267EC04@celox-ma1-ems1.celoxnetworks.com> Date: Mon, 21 Oct 2002 13:51:16 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <1117F7D44159934FB116E36F4ABF221B0267EC04@celox-ma1-ems1.celoxnetwor ks.com>, "Gray, Eric" writes: > Curtis, > > See below... > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > > --- [snip] --- > > > > > > It works fine until you put an ethernet switch in place and try to put > > more than 1 Gb over a 1 GbE. This is true for any situation where > > more than one ingress going through the switch to one egreess. > > Realistically speaking, how often do you expect > to see Ethernet switches being used between LSRs > within an MPLS domain? In the (possibly rare) > case where this occurs, how likely is it that > such a switch is MPLS unaware? An ISP would be better at answering that. I know that ISPs have considered using GbE and 10GbE within POPs that have more than one router as a means to interconnect access routers that serve lots of low speed links. This keeps the interface count down on the core or aggregation routers instead using less expensive L2 switch interfaces and the access routers typically do not source/sink enough bandwidth to exceed the ethernet. I'm quite sure some have done this and are using MPLS over some of these ethernets. I don't work for a ethernet switch vendor and I also don't hear all of the requirements that come to my employer, but so far I haven't heard anything from ISPs that would indicate that they are using MPLS capable ethernet switches. I must admit that could also be because I never asked about this and our equipment is more core oriented so it was never mentioned. AFAIK the ethernet switches are not MPLS capable. Curtis From owner-mpls@UU.NET Mon Oct 21 14:26:04 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09376 for ; Mon, 21 Oct 2002 14:26:04 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnloj19244 for ; Mon, 21 Oct 2002 18:28:17 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnloj17781; Mon, 21 Oct 2002 18:27:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQnloj13960 for mpls-outgoing; Mon, 21 Oct 2002 18:27:19 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnloj13953 for ; Mon, 21 Oct 2002 18:27:17 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnloj10307 for ; Mon, 21 Oct 2002 18:18:44 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnloj25081 for ; Mon, 21 Oct 2002 18:18:44 GMT Received: from antivir1 by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [192.114.163.163]) id QQnloj25057 for ; Mon, 21 Oct 2002 18:18:43 GMT Received: from 192.168.254.14 by antivir1 (InterScan E-Mail VirusWall NT); Mon, 21 Oct 2002 20:18:58 +0200 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id <469H3ALY>; Mon, 21 Oct 2002 20:17:50 +0200 Message-ID: From: Sasha Vainshtein To: "'curtis@fictitious.org'" Cc: "'Vishal M'" , mpls@UU.NET, Shahram Davari Subject: RE: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) Date: Mon, 21 Oct 2002 20:17:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-8" Sender: owner-mpls@UU.NET Precedence: bulk Curtis and all, Can you please explain what you mean when you say that mapping EXP-->802.1q is straighforward? The only reference I have found in RFC 3270 states: 3. Detailed Operations of E-LSPs ... skipped ... 3.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing E-LSP ... skipped ... 3.4.4 `PHB-->802.1 mapping' If the LSP is egressing over a LAN interface on which multiple 802.1 Traffic Classes are supported as per [IEEE_802.1], then one `PHB-->802.1 mapping' is added to the `Set of PHB-->Encaps mappings' for this outgoing LSP. This `PHB-->802.1 mapping' is populated in the following way: - it is a function of the PHBs supported on this LSP, and uses the relevant mapping entries for these PHBs from the Preconfigured `PHB-->802.1 mapping' defined in section 3.4.4.1. Notice that the `Set of PHB-->Encaps mappings' then contains both a `PHB-->EXP mapping' and a `PHB-->802.1 mapping'. 3.4.4.1 Preconfigured `PHB-->802.1 Mapping' At the time of producing this specification, there are no standardized mapping from PHBs to 802.1 Traffic Classes. Consequently, an LSR supporting multiple 802.1 Traffic Classes over LAN interfaces must allow local configuration of a `PHB-->802.1 mapping'. This mapping applies to all the outgoing LSPs established by the LSR on such LAN interfaces. It seems to me that the use case is exactly one you have mentioned (i.e. EXP-->802.1q for unsignaled E-LSPs), but no standardized mapping is defined, and a local defintion is left to the network administrator. One can probably add some limitations, e.g., AF for a fixed x MUST be mapped to the same 802.1q traffic class since AF is an ordered aggregate for any given x. CS should be probably mapped to Pri = n for n=1, ..., 7, and the default PHB should be mapped to the Pri = 0. Is there anything beyound these (and some other, equally naive) considerations? With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > Sent: Monday, October 21, 2002 7:37 PM > To: Sasha Vainshtein > Cc: 'curtis@fictitious.org'; 'Vishal M'; mpls@uu.net; Shahram Davari > Subject: Re: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) > > > > In message , > Sasha Vainshtein writ > es: > > Curtis and all, > > Can you provide any suggestions/pointers as to how DiffServ and > > 802.1q markings should be mapped? > > Because, IMHO, just having 802.1q is not enough, you should decide > > how to use it. > > I'm not a big fan of 802.1q. > > Mapping EXP into 802.1q signaling is straightforward. This mapping is > sufficient for unsignaled E-LSP. > > The mapping of 802.1q priorities to packet treatment is not > straightforward. I'd argue that what most switches are capable of > doing with 802.1q priorities does not support diffserv, particularly > AF, L-LSPs, or signaled E-LSPs. For AF service, the EXP bits must be > modified even for unsignaled E-LSPs so any switch relying solely on > 802.1q signaling is inherently broken wrt AF service. > > > With best regards, > > Sasha Vainshtein > > I haven't kept up with what ethernet switches are doing in this > regard. Shahram may be better able to answer this. > > Curtis > From owner-mpls@UU.NET Mon Oct 21 14:50:36 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10275 for ; Mon, 21 Oct 2002 14:50:35 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlol11106 for ; Mon, 21 Oct 2002 18:52:47 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnlol09359; Mon, 21 Oct 2002 18:51:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQnlol15905 for mpls-outgoing; Mon, 21 Oct 2002 18:51:19 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnlol15804 for ; Mon, 21 Oct 2002 18:51:07 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnlol23568 for ; Mon, 21 Oct 2002 18:49:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlol09564 for ; Mon, 21 Oct 2002 18:49:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnlol09548 for ; Mon, 21 Oct 2002 18:49:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA07233 for ; Mon, 21 Oct 2002 14:49:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9LIn2808650 for mpls@uu.net; Mon, 21 Oct 2002 14:49:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnlol15588 for ; Mon, 21 Oct 2002 18:48:09 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnlol11332 for ; Mon, 21 Oct 2002 18:46:16 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlol03441 for ; Mon, 21 Oct 2002 18:46:15 GMT Received: from web13506.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web13506.mail.yahoo.com [216.136.175.85]) id QQnlol03433 for ; Mon, 21 Oct 2002 18:46:15 GMT Message-ID: <20021021184613.92281.qmail@web13506.mail.yahoo.com> Received: from [63.67.101.6] by web13506.mail.yahoo.com via HTTP; Mon, 21 Oct 2002 11:46:13 PDT Date: Mon, 21 Oct 2002 11:46:13 -0700 (PDT) From: Vishal M Subject: RE: Ques on RFC 3270 (MPLS Support for DiffServ) To: Shahram Davari , mpls@UU.NET Cc: vishal_study@yahoo.com In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB039FD@nt-exch-yow.pmc-sierra.bc.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi Shahram, Thanks for the clarification. I re-read the relevant sections of RFC 3270 and have some confusion trying to understand the concept of Ordering Constraint and its usage. How does an ingress LSR decide if there is any ordering constraint between various packet flows it receives. i.e. in Section 1.4 (last para), it says that in order to preserve the ordering constraint, all possible BAs of a given OA must be sent over same LSP. This looks fine, but I have a doubt: The question is: How does an LSR decide if incoming packets of same micro-flow have some ordering constraint? Where is this info (of ordering constraint) carried? Assuming an video-on-demand application running on a host connected to an ingress LSR (doing MPLS DS TE). This ingress LSR would receive both voice and video packets (destined to different ports) on same destination IP Address. Since its a video-on-demand application, one would expect ordering constraint to synchronize the video with voice contents. Now can these video and voice packets be redirected to different L-LSPs? Could you/someone please clarify this? thanks for your time, regards, Vishal. PS: I'm not familiar with video/voice DSPs...the above example just tries to provide an example of two different classes (i.e. BAs) arriving at an ingress LSR destined to same destination. --- Shahram Davari wrote: > The label in L-LSP represents only a single OA, > while the label in E-LSP may represent: > > - A single BA > - A single OA > - A number of BAs > - A number of OAs > - A number of BAs and OAs > > " A set of BAs" is a generic term that applies to > all the above cases. > > -Shahram > > > -----Original Message----- > > From: Vishal M [mailto:vishal_study@yahoo.com] > > Sent: Friday, October 18, 2002 10:35 PM > > To: mpls@UU.NET > > Subject: Ques on RFC 3270 (MPLS Support for > DiffServ) > > > > > > > > Hello, > > > > Question on RFC 3270 (MPLS Support for DiffServ), > > Section 1.5: > > > > The second paragraph explains about the > relationship > > between FEC and set of BAs... > > > > Why don't we consider the concept of packet > ordering > > constaint (i.e. OA) for an E-LSP (say, E-LSP1 and > > E-LSP2) ? > > > > Assuming we have two E-LSPs from the same source > (S) > > to the same destination (D). Now if an incoming > > multimedia packet stream from single source (of > voice > > and video traffic) is to be sent to destination > (D), > > is it possible to send voice traffic onto E-LSP1 > and > > video onto E-LSP2 ? > > > > Why in this section, we have associated OAs with > > L-LSPs only (and not with E-LSPs)? > > > > Thanks for all the inputs and pointers, > > > > Regards, > > Vishal. > > > > > > > > __________________________________________________ > > Do you Yahoo!? > > Y! Web Hosting - Let the expert host your web site > > http://webhosting.yahoo.com/ > > __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ From owner-mpls@UU.NET Mon Oct 21 15:00:00 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10759 for ; Mon, 21 Oct 2002 15:00:00 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlom21002 for ; Mon, 21 Oct 2002 19:02:12 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnlom19653; Mon, 21 Oct 2002 19:01:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQnlom21686 for mpls-outgoing; Mon, 21 Oct 2002 19:01:05 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnlom21396 for ; Mon, 21 Oct 2002 19:01:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnlom25277 for ; Mon, 21 Oct 2002 19:00:16 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlom16702 for ; Mon, 21 Oct 2002 19:00:15 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnlom16679 for ; Mon, 21 Oct 2002 19:00:15 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA08295 for ; Mon, 21 Oct 2002 15:00:14 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9LJ0EK09888 for mpls@uu.net; Mon, 21 Oct 2002 15:00:14 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnlol16399 for ; Mon, 21 Oct 2002 18:59:16 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnlol23647 for ; Mon, 21 Oct 2002 18:58:41 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlol14761 for ; Mon, 21 Oct 2002 18:58:40 GMT Received: from mother.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQnlol14754 for ; Mon, 21 Oct 2002 18:58:40 GMT Received: (qmail 24438 invoked by uid 104); 21 Oct 2002 18:58:39 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4229. . Clean. Processed in 0.510243 secs); 21 Oct 2002 18:58:39 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 21 Oct 2002 18:58:39 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g9LIwcQ08798; Mon, 21 Oct 2002 11:58:38 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id <40J3HCAQ>; Mon, 21 Oct 2002 11:58:22 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03A03@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Vishal M'" , mpls@UU.NET Subject: RE: Ques on RFC 3270 (MPLS Support for DiffServ) Date: Mon, 21 Oct 2002 11:58:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Vishal, What you are asking is outside the scope of RFC3270 and even out side the scope of Diffserv and MPLS WGs. RFC3270 just tells you that you could use an L-LSP to carry a single OA. Whether that single OA consists of voice, or video or voice+video is irrelevant. -Shahram > -----Original Message----- > From: Vishal M [mailto:vishal_study@yahoo.com] > Sent: Monday, October 21, 2002 2:46 PM > To: Shahram Davari; mpls@UU.NET > Cc: vishal_study@yahoo.com > Subject: RE: Ques on RFC 3270 (MPLS Support for DiffServ) > > > > Hi Shahram, > > Thanks for the clarification. > > I re-read the relevant sections of RFC 3270 and have > some confusion trying to understand the concept of > Ordering Constraint and its usage. > > How does an ingress LSR decide if there is any > ordering constraint between various packet flows it > receives. i.e. in Section 1.4 (last para), it says > that in order to preserve the ordering constraint, all > possible BAs of a given OA must be sent over same LSP. > This looks fine, but I have a doubt: > > The question is: > How does an LSR decide if incoming packets of same > micro-flow have some ordering constraint? Where is > this info (of ordering constraint) carried? > > Assuming an video-on-demand application running on a > host connected to an ingress LSR (doing MPLS DS TE). > This ingress LSR would receive both voice and video > packets (destined to different ports) on same > destination IP Address. Since its a video-on-demand > application, one would expect ordering constraint to > synchronize the video with voice contents. > Now can these video and voice packets be redirected to > different L-LSPs? > > Could you/someone please clarify this? > > thanks for your time, > > regards, > Vishal. > PS: I'm not familiar with video/voice DSPs...the above > example just tries to provide an example of two > different classes (i.e. BAs) arriving at an ingress > LSR destined to same destination. > > --- Shahram Davari > wrote: > > The label in L-LSP represents only a single OA, > > while the label in E-LSP may represent: > > > > - A single BA > > - A single OA > > - A number of BAs > > - A number of OAs > > - A number of BAs and OAs > > > > " A set of BAs" is a generic term that applies to > > all the above cases. > > > > -Shahram > > > > > -----Original Message----- > > > From: Vishal M [mailto:vishal_study@yahoo.com] > > > Sent: Friday, October 18, 2002 10:35 PM > > > To: mpls@UU.NET > > > Subject: Ques on RFC 3270 (MPLS Support for > > DiffServ) > > > > > > > > > > > > Hello, > > > > > > Question on RFC 3270 (MPLS Support for DiffServ), > > > Section 1.5: > > > > > > The second paragraph explains about the > > relationship > > > between FEC and set of BAs... > > > > > > Why don't we consider the concept of packet > > ordering > > > constaint (i.e. OA) for an E-LSP (say, E-LSP1 and > > > E-LSP2) ? > > > > > > Assuming we have two E-LSPs from the same source > > (S) > > > to the same destination (D). Now if an incoming > > > multimedia packet stream from single source (of > > voice > > > and video traffic) is to be sent to destination > > (D), > > > is it possible to send voice traffic onto E-LSP1 > > and > > > video onto E-LSP2 ? > > > > > > Why in this section, we have associated OAs with > > > L-LSPs only (and not with E-LSPs)? > > > > > > Thanks for all the inputs and pointers, > > > > > > Regards, > > > Vishal. > > > > > > > > > > > > __________________________________________________ > > > Do you Yahoo!? > > > Y! Web Hosting - Let the expert host your web site > > > http://webhosting.yahoo.com/ > > > > > > __________________________________________________ > Do you Yahoo!? > Y! Web Hosting - Let the expert host your web site > http://webhosting.yahoo.com/ > From owner-mpls@UU.NET Mon Oct 21 16:21:32 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13883 for ; Mon, 21 Oct 2002 16:21:32 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlor15147 for ; Mon, 21 Oct 2002 20:23:45 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnlor13866; Mon, 21 Oct 2002 20:23:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQnlor25850 for mpls-outgoing; Mon, 21 Oct 2002 20:22:46 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnlor25845 for ; Mon, 21 Oct 2002 20:22:40 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnlor11284 for ; Mon, 21 Oct 2002 20:22:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlor28762 for ; Mon, 21 Oct 2002 20:22:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnlor28758 for ; Mon, 21 Oct 2002 20:22:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA15147 for ; Mon, 21 Oct 2002 16:22:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9LKM2p16241 for mpls@uu.net; Mon, 21 Oct 2002 16:22:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnlor25748 for ; Mon, 21 Oct 2002 20:20:58 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnlor03731 for ; Mon, 21 Oct 2002 20:20:37 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlor24618 for ; Mon, 21 Oct 2002 20:20:37 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnlor24600 for ; Mon, 21 Oct 2002 20:20:36 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id QAA17013; Mon, 21 Oct 2002 16:18:59 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200210212018.QAA17013@workhorse.fictitious.org> To: Sasha Vainshtein cc: "'curtis@fictitious.org'" , "'Vishal M'" , mpls@UU.NET, Shahram Davari Reply-To: curtis@fictitious.org Subject: Re: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) In-reply-to: Your message of "Mon, 21 Oct 2002 20:17:49 +0200." Date: Mon, 21 Oct 2002 16:18:59 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , Sasha Vainshtein writ es: > Curtis and all, > Can you please explain what you mean when you say > that mapping EXP-->802.1q is straighforward? > > The only reference I have found in RFC 3270 states: > > 3. Detailed Operations of E-LSPs > ... skipped ... > 3.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing E-LSP > ... skipped ... > 3.4.4 `PHB-->802.1 mapping' > > If the LSP is egressing over a LAN interface on which multiple 802.1 > Traffic Classes are supported as per [IEEE_802.1], then one > `PHB-->802.1 mapping' is added to the `Set of PHB-->Encaps mappings' > for this outgoing LSP. This `PHB-->802.1 mapping' is populated in > the following way: > > - it is a function of the PHBs supported on this LSP, and uses the > relevant mapping entries for these PHBs from the Preconfigured > `PHB-->802.1 mapping' defined in section 3.4.4.1. > > Notice that the `Set of PHB-->Encaps mappings' then contains both a > `PHB-->EXP mapping' and a `PHB-->802.1 mapping'. > > 3.4.4.1 Preconfigured `PHB-->802.1 Mapping' > > At the time of producing this specification, there are no > standardized mapping from PHBs to 802.1 Traffic Classes. > Consequently, an LSR supporting multiple 802.1 Traffic Classes over > LAN interfaces must allow local configuration of a `PHB-->802.1 > mapping'. This mapping applies to all the outgoing LSPs established > by the LSR on such LAN interfaces. > > > It seems to me that the use case is exactly one you have mentioned > (i.e. EXP-->802.1q for unsignaled E-LSPs), but no standardized mapping > is defined, and a local defintion is left to the network administrator. > > One can probably add some limitations, e.g., AF for a fixed x > MUST be mapped to the same 802.1q traffic class since AF is an > ordered aggregate for any given x. CS should be > probably mapped to Pri = n for n=1, ..., 7, and the default > PHB should be mapped to the Pri = 0. > > Is there anything beyound these (and some other, equally > naive) considerations? > > With best regards, > Sasha Vainshtein > email: sasha@axerra.com > tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) Someone building an LSR just implements the ability to enable a default E-LSP EXP->802.1q mapping and offers the ability to configure mappings. Whether this proves adequate and if so, the configuration is up to the ISP (or other user). Curtis > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > > Sent: Monday, October 21, 2002 7:37 PM > > To: Sasha Vainshtein > > Cc: 'curtis@fictitious.org'; 'Vishal M'; mpls@uu.net; Shahram Davari > > Subject: Re: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) > > > > > > > > In message , > > Sasha Vainshtein writ > > es: > > > Curtis and all, > > > Can you provide any suggestions/pointers as to how DiffServ and > > > 802.1q markings should be mapped? > > > Because, IMHO, just having 802.1q is not enough, you should decide > > > how to use it. > > > > I'm not a big fan of 802.1q. > > > > Mapping EXP into 802.1q signaling is straightforward. This mapping is > > sufficient for unsignaled E-LSP. > > > > The mapping of 802.1q priorities to packet treatment is not > > straightforward. I'd argue that what most switches are capable of > > doing with 802.1q priorities does not support diffserv, particularly > > AF, L-LSPs, or signaled E-LSPs. For AF service, the EXP bits must be > > modified even for unsignaled E-LSPs so any switch relying solely on > > 802.1q signaling is inherently broken wrt AF service. > > > > > With best regards, > > > Sasha Vainshtein > > > > I haven't kept up with what ethernet switches are doing in this > > regard. Shahram may be better able to answer this. > > > > Curtis > > > From owner-mpls@UU.NET Mon Oct 21 16:35:58 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14496 for ; Mon, 21 Oct 2002 16:35:57 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlos11809 for ; Mon, 21 Oct 2002 20:38:09 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnlos10586; Mon, 21 Oct 2002 20:37:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQnlos26947 for mpls-outgoing; Mon, 21 Oct 2002 20:37:06 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnlos26938 for ; Mon, 21 Oct 2002 20:36:53 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnlos26803 for ; Mon, 21 Oct 2002 20:36:24 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlos05768 for ; Mon, 21 Oct 2002 20:36:23 GMT Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQnlos05756 for ; Mon, 21 Oct 2002 20:36:23 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9LKaMm78401; Mon, 21 Oct 2002 13:36:22 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id g9LKaME54135; Mon, 21 Oct 2002 13:36:22 -0700 (PDT) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Mon, 21 Oct 2002 13:36:22 -0700 (PDT) From: Kireeti Kompella To: Brian Hassink cc: Subject: Re: Latest MPLS Ping draft... In-Reply-To: <8052E2EA753D144EB906B7A7AA3997140E9445@mailserv.hatteras.com> Message-ID: <20021021132335.U53941-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Tue, 15 Oct 2002, Brian Hassink wrote: > I'm wondering if it wouldn't be better to move the return code from the > main header to the TLV header, or add a return code to the TLV header? I > think there may be a couple of good reasons for doing this... Read section 3.4, and the documentation for value 0 for the return code. > Also, couldn't a (optional) "timestamp" TLV be defined rather than > having this information as mandatory fields in the main header? Any particular reason? One could make TLVs of all fields, not just the timestamp fields. > Lastly, it's not clear to me which FEC applies to a tunnel that has > been setup manually (i.e. static tunnels)? There isn't one at present. One could add one, if it is deemed useful. As for checksums, UDP does have a checksum; most underlying transport does as well. If some new reply mode is introduced which doesn't have a native checksum, a checksum TLV can be added -- however, I would wait until a concrete reason is given, so that the figh ... um, discussions about which particular checksum methodology be used can have a concrete basis. Kireeti. From owner-mpls@UU.NET Mon Oct 21 17:07:45 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15621 for ; Mon, 21 Oct 2002 17:07:44 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlou02785 for ; Mon, 21 Oct 2002 21:09:59 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnlou01400; Mon, 21 Oct 2002 21:09:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQnlou16306 for mpls-outgoing; Mon, 21 Oct 2002 21:08:54 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnlou16301 for ; Mon, 21 Oct 2002 21:08:50 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnlou19343 for ; Mon, 21 Oct 2002 21:08:41 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlou00633 for ; Mon, 21 Oct 2002 21:08:40 GMT Received: from mailserv.hatteras.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailserv.hatterasnetworks.com [63.89.58.4]) id QQnlou00625 for ; Mon, 21 Oct 2002 21:08:40 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Latest MPLS Ping draft... Date: Mon, 21 Oct 2002 17:08:36 -0400 Message-ID: <8052E2EA753D144EB906B7A7AA3997140E9459@mailserv.hatteras.com> Thread-Topic: Latest MPLS Ping draft... Thread-Index: AcJ5QYXPZ0ZROwHNQc+dqkso50GU4wAAcLrw From: "Brian Hassink" To: "Kireeti Kompella" Cc: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA15621 Please see followup comments inline below... Cheers, Brian Hassink --- bhassink@hatterasnetworks.com -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Monday, October 21, 2002 4:36 PM To: Brian Hassink Cc: mpls@UU.NET Subject: Re: Latest MPLS Ping draft... On Tue, 15 Oct 2002, Brian Hassink wrote: > I'm wondering if it wouldn't be better to move the return code from the > main header to the TLV header, or add a return code to the TLV header? I > think there may be a couple of good reasons for doing this... Read section 3.4, and the documentation for value 0 for the return code. [BH] Ok, I'll buy that. I think that if this "protocol" evolves to support other inband OAM functions, that a more granular error reporting mechanism will be required. However the "error" TLV ends up getting defined, there will likely be a result per TLV, or set of associated TLVs, and I figured allowing for a return code within the TLV may result in less correlation and processing overhead. > Also, couldn't a (optional) "timestamp" TLV be defined rather than > having this information as mandatory fields in the main header? Any particular reason? One could make TLVs of all fields, not just the timestamp fields. [BH] I think that measuring delay/RTT is not necessarily something you want to combine with testing/validating connectivity. And again, if this "protocol" evolves to support other inband OAM functions, then it may become even less relevant to a given function. > Lastly, it's not clear to me which FEC applies to a tunnel that has > been setup manually (i.e. static tunnels)? There isn't one at present. One could add one, if it is deemed useful. [BH] Seems like at pretty useful thing to be able to do. Static tunnels are used in networks and I would think the reasons for monitoring them would be the same as if they were signaled. As for checksums, UDP does have a checksum; most underlying transport does as well. If some new reply mode is introduced which doesn't have a native checksum, a checksum TLV can be added -- however, I would wait until a concrete reason is given, so that the figh ... um, discussions about which particular checksum methodology be used can have a concrete basis. [BH] Fair enough. Kireeti. From owner-mpls@UU.NET Mon Oct 21 23:07:41 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22899 for ; Mon, 21 Oct 2002 23:07:41 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlps27936 for ; Tue, 22 Oct 2002 03:09:53 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnlps26000; Tue, 22 Oct 2002 03:09:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQnlps25305 for mpls-outgoing; Tue, 22 Oct 2002 03:08:39 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnlps25300 for ; Tue, 22 Oct 2002 03:08:33 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnlps08457 for ; Tue, 22 Oct 2002 03:08:26 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlps16161 for ; Tue, 22 Oct 2002 03:08:26 GMT Received: from vivacenetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.221.212.131]) id QQnlps16150 for ; Tue, 22 Oct 2002 03:08:25 GMT Received: from AMALIS.vivacenetworks.com ([10.120.0.2] RDNS failed) by vivacenetworks.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 21 Oct 2002 20:07:38 -0700 Message-Id: <5.1.0.14.2.20021021230239.04bbc0d0@po1.vivacenetworks.com> X-Sender: vivacenet\amalis@po1.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 21 Oct 2002 23:07:34 -0400 To: curtis@fictitious.org From: "Andrew G. Malis" Subject: Re: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) Cc: "Gray, Eric" , "'Shahram Davari'" , mpls@UU.NET In-Reply-To: <200210211656.MAA16163@workhorse.fictitious.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 22 Oct 2002 03:07:38.0943 (UTC) FILETIME=[2DB15CF0:01C27978] Sender: owner-mpls@UU.NET Precedence: bulk Curtis, >It works fine until you put an ethernet switch in place and try to put >more than 1 Gb over a 1 GbE. This is true for any situation where >more than one ingress going through the switch to one egreess. Even this case works fine if you have LSRs that can do per-LSP (or at the very least per-DSCP) policing, queuing, and shaping into the GE. I agree that in general, Ethernet switches don't have the necessary QoS mechanisms. Cheers, Andy From owner-mpls@UU.NET Tue Oct 22 02:21:52 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06897 for ; Tue, 22 Oct 2002 02:21:52 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlqf18930 for ; Tue, 22 Oct 2002 06:24:05 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnlqf17849; Tue, 22 Oct 2002 06:23:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQnlqf00324 for mpls-outgoing; Tue, 22 Oct 2002 06:23:18 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnlqf00319 for ; Tue, 22 Oct 2002 06:23:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnlqf01142 for ; Tue, 22 Oct 2002 06:21:52 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlqf16128 for ; Tue, 22 Oct 2002 06:21:51 GMT Received: from smtp01.wlv.untd.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: smtp01.wlv.untd.com [209.247.163.57]) id QQnlqf16107 for ; Tue, 22 Oct 2002 06:21:51 GMT Received: (qmail 16438 invoked from network); 22 Oct 2002 06:21:49 -0000 Received: from host-66-81-155-253.rev.o1.com (HELO studydesktop) (66.81.155.253) by smtp01.wlv.untd.com with SMTP; 22 Oct 2002 06:21:49 -0000 Message-ID: <011001c27993$863467d0$0100a8c0@studydesktop> From: "mark seery" To: "Vishal M" Cc: References: <20021019020242.50648.qmail@web13506.mail.yahoo.com> Subject: Re: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) Date: Mon, 21 Oct 2002 23:23:22 -0700 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.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Vishal M" To: Sent: Friday, October 18, 2002 7:02 PM Subject: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) > The reason for the doubt is: > The Ethernet header (like ATM) doesn't have any QoS > information field (unless 802.1q is supported). So > does that imply that E-LSP can't be used when ethernet > is the underlying media (and 802.1q is not supported). > > Is L-LSP the only choice then? Vishal, the option to use E-LSP or L-LSP comes down to whether the MPLS "shim" is used on the interface in question - or not. For FR/ATM it was decided not to use the shim, and reuse the existing headers. I can't see any standard covering Ethernet per se, but always assumed when MPLS runs over Ethernet it uses the shim (which is different than mapping a native Ethernet interface to a MPLS service), and http://www.ietf.org/internet-drafts/draft-martini-ethernet-encap-mpls-01.txt seems to infer MPLS shim can be used over Ethernet. At any rate, unless there is a draft/standard which specifies reuse of Ethernet headers for L-LSP in the same fashions as FR/ATM, then perhaps the question you ask should be the other way around ;-) Seriously, shim or no-shim is the crux of the issue - I haven't followed it close enough recently to give u a definitive answer. -mark ------------------------------------------- Introducing NetZero Long Distance Unlimited Long Distance only $29.95/ month! Sign Up Today! www.netzerolongdistance.com From owner-mpls@UU.NET Tue Oct 22 04:29:22 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08834 for ; Tue, 22 Oct 2002 04:29:21 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlqo03435 for ; Tue, 22 Oct 2002 08:31:34 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnlqo01843; Tue, 22 Oct 2002 08:30:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQnlqo12563 for mpls-outgoing; Tue, 22 Oct 2002 08:30:19 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnlqo12553 for ; Tue, 22 Oct 2002 08:30:07 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnlqn02087 for ; Tue, 22 Oct 2002 08:29:04 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlqn16311 for ; Tue, 22 Oct 2002 08:29:04 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnlqn16305 for ; Tue, 22 Oct 2002 08:29:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id EAA24584 for ; Tue, 22 Oct 2002 04:29:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9M8T3b28598 for mpls@uu.net; Tue, 22 Oct 2002 04:29:03 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnlqn12492 for ; Tue, 22 Oct 2002 08:28:17 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnlqn20556 for ; Tue, 22 Oct 2002 08:27:45 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlqn29183 for ; Tue, 22 Oct 2002 08:27:44 GMT Received: from ams-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ams-msg-core-1.cisco.com [144.254.74.60]) id QQnlqn29157 for ; Tue, 22 Oct 2002 08:27:44 GMT Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9M8Q5GB013291; Tue, 22 Oct 2002 10:26:10 +0200 (MET DST) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 22 Oct 2002 10:27:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) Date: Tue, 22 Oct 2002 09:27:18 +0100 Message-ID: Thread-Topic: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) Thread-Index: AcJ5P72pMv6Tg7AMQhGmY9MoLJz2mAAYWTYg From: "Francois Le Faucheur (flefauch)" To: , "Sasha Vainshtein" Cc: "Vishal M" , , "Shahram Davari" X-OriginalArrivalTime: 22 Oct 2002 08:27:19.0138 (UTC) FILETIME=[D5FADC20:01C279A4] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA08834 Hello, Here's my take on "MPLS Diff-Serv over Ethernet" (includes paraphrasing some of what has been said already): There are indeed different cases to consider: - Two adjacent LSRs are interconnected via a pt-to-pt Ethernet segment. MPLS Diff-Serv works beautifully. You can use preconfigured mapping E-LSPs, Signalled E-LSPs, L-LSPs. LSRs would be doing PHB enforcement (queuing/drop) based on EXP (or EXP+label). 802.1 Q does not really have any role to play in that case and 802.1 Q markings need not be used. - Two adjacent LSRs are interconnected via 802.1Q-capable Ethernet Switch. MPLS Diff-Serv works beautifully. You can use preconfigured mapping E-LSPs, Signalled E-LSPs, L-LSP. LSRs would be doing PHB enforcement (queuing/drop) based on EXP (or EXP+label). LSRs would be doing a PHB-->802.1Q mapping (eg RFC3270 section 3.4.4 and 3.4.5). This mapping has actually nothing to do with MPLS per say (you should be using the same mapping as used when doing non-MPLS Diff-Serv IP over 802.1Q. In general it is desirable to have a configurable mapping because there are less 802.1Q values than potential PHBs, different network may support differnet subset of PHBs, differnet 802.1Q switches may have differnet capabilities (eg 2/4/8 queues),...etc. The Etherent switch is completely unaware of the MPLS-Shim header and of EXP bits and of course does its scheduling/dropping based on 802.1Q values. (note that an ethernet switch which would be running and MPLS control plane, is an LSR so it is covered by the previous case). - Two adjacant LSRs are interconnected via Ethernet switch which is not 802.1Q capable (bought it second-hand, I guess ;^) or the LSR is not capable of doing PHB-->802.1Q mapping. Then, your Diff-Serv is jeopardised (unless you can be sure by capacity planning that you will never see any congestion on an egress port of the LAN switch, of course). Cheers Francois PS: A few clarifications, addressing some comments in the thread: - the Shim header is absolutely always used on Ethernet - DSTE is not the same thing as MPLS Diff-Serv (RFC3270). RFC3270 defines how to support Diff-Serv over MPLS (which are data path mechanisms independent of Path computation). DSTE refers to Diff-Serv-aware MPLS Traffic Engineering (see draft-tewg-diff-te-reqts and draft-tewg-diff-te-proto) which deals with control plane mechansism for Diff-Serv aware Path computation. >> -----Original Message----- >> From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] >> Sent: 21 October 2002 22:19 >> To: Sasha Vainshtein >> Cc: 'curtis@fictitious.org'; 'Vishal M'; mpls@UU.NET; Shahram Davari >> Subject: Re: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) >> >> >> >> In message , >> Sasha Vainshtein writ >> es: >> > Curtis and all, >> > Can you please explain what you mean when you say >> > that mapping EXP-->802.1q is straighforward? >> > >> > The only reference I have found in RFC 3270 states: >> > >> > 3. Detailed Operations of E-LSPs >> > ... skipped ... >> > 3.4 Populating the `Set of PHB-->Encaps mappings' for an >> outgoing E-LSP >> > ... skipped ... >> > 3.4.4 `PHB-->802.1 mapping' >> > >> > If the LSP is egressing over a LAN interface on which >> multiple 802.1 >> > Traffic Classes are supported as per [IEEE_802.1], then one >> > `PHB-->802.1 mapping' is added to the `Set of >> PHB-->Encaps mappings' >> > for this outgoing LSP. This `PHB-->802.1 mapping' is >> populated in >> > the following way: >> > >> > - it is a function of the PHBs supported on this LSP, >> and uses the >> > relevant mapping entries for these PHBs from the >> Preconfigured >> > `PHB-->802.1 mapping' defined in section 3.4.4.1. >> > >> > Notice that the `Set of PHB-->Encaps mappings' then >> contains both a >> > `PHB-->EXP mapping' and a `PHB-->802.1 mapping'. >> > >> > 3.4.4.1 Preconfigured `PHB-->802.1 Mapping' >> > >> > At the time of producing this specification, there are no >> > standardized mapping from PHBs to 802.1 Traffic Classes. >> > Consequently, an LSR supporting multiple 802.1 Traffic >> Classes over >> > LAN interfaces must allow local configuration of a `PHB-->802.1 >> > mapping'. This mapping applies to all the outgoing >> LSPs established >> > by the LSR on such LAN interfaces. >> > >> > >> > It seems to me that the use case is exactly one you have mentioned >> > (i.e. EXP-->802.1q for unsignaled E-LSPs), but no >> standardized mapping >> > is defined, and a local defintion is left to the network >> administrator. >> > >> > One can probably add some limitations, e.g., AF for a fixed x >> > MUST be mapped to the same 802.1q traffic class since >> AF is an >> > ordered aggregate for any given x. CS should be >> > probably mapped to Pri = n for n=1, ..., 7, and the default >> > PHB should be mapped to the Pri = 0. >> > >> > Is there anything beyound these (and some other, equally >> > naive) considerations? >> > >> > With best regards, >> > Sasha Vainshtein >> > email: sasha@axerra.com >> > tel: +972-3-7659993 (office) >> > +972-8-9254948 (res.) >> > +972-58-674833 (cell.) >> >> >> Someone building an LSR just implements the ability to enable a >> default E-LSP EXP->802.1q mapping and offers the ability to configure >> mappings. Whether this proves adequate and if so, the configuration >> is up to the ISP (or other user). >> >> Curtis >> >> >> > > -----Original Message----- >> > > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] >> > > Sent: Monday, October 21, 2002 7:37 PM >> > > To: Sasha Vainshtein >> > > Cc: 'curtis@fictitious.org'; 'Vishal M'; mpls@uu.net; >> Shahram Davari >> > > Subject: Re: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) >> > > >> > > >> > > >> > > In message , >> > > Sasha Vainshtein writ >> > > es: >> > > > Curtis and all, >> > > > Can you provide any suggestions/pointers as to how >> DiffServ and >> > > > 802.1q markings should be mapped? >> > > > Because, IMHO, just having 802.1q is not enough, you >> should decide >> > > > how to use it. >> > > >> > > I'm not a big fan of 802.1q. >> > > >> > > Mapping EXP into 802.1q signaling is straightforward. >> This mapping is >> > > sufficient for unsignaled E-LSP. >> > > >> > > The mapping of 802.1q priorities to packet treatment is not >> > > straightforward. I'd argue that what most switches are >> capable of >> > > doing with 802.1q priorities does not support diffserv, >> particularly >> > > AF, L-LSPs, or signaled E-LSPs. For AF service, the EXP >> bits must be >> > > modified even for unsignaled E-LSPs so any switch >> relying solely on >> > > 802.1q signaling is inherently broken wrt AF service. >> > > >> > > > With best regards, >> > > > Sasha Vainshtein >> > > >> > > I haven't kept up with what ethernet switches are doing in this >> > > regard. Shahram may be better able to answer this. >> > > >> > > Curtis >> > > >> > >> >> From owner-mpls@UU.NET Tue Oct 22 08:46:37 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14303 for ; Tue, 22 Oct 2002 08:46:37 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlrf19145 for ; Tue, 22 Oct 2002 12:48:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnlrf18461; Tue, 22 Oct 2002 12:48:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQnlrf08501 for mpls-outgoing; Tue, 22 Oct 2002 12:48:03 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnlrf08474 for ; Tue, 22 Oct 2002 12:47:52 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnlrf08431 for ; Tue, 22 Oct 2002 12:47:48 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlrf28909 for ; Tue, 22 Oct 2002 12:47:48 GMT Received: from mail8.wlv.netzero.net by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: mail8.wlv.netzero.net [209.247.163.58]) id QQnlrf28898 for ; Tue, 22 Oct 2002 12:47:47 GMT Received: (qmail 9834 invoked from network); 22 Oct 2002 12:47:23 -0000 Received: from host-66-81-155-146.rev.o1.com (HELO studydesktop) (66.81.155.146) by mail8.wlv.netzero.net with SMTP; 22 Oct 2002 12:47:23 -0000 Message-ID: <001301c279c9$653a6b70$0100a8c0@studydesktop> From: "mark seery" To: "Francois Le Faucheur \(flefauch\)" Cc: "Vishal M" , References: Subject: Re: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) Date: Tue, 22 Oct 2002 05:47:33 -0700 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.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Thanks Francois, >> [snip] PS: A few clarifications, addressing some comments in the thread: - the Shim header is absolutely always used on Ethernet << So to answer the original question, if a shim is always used, then both E-LSP and L-LSP can be supported. In a non-shim scenario, E-LSP could only be supported if the equivalent (shim header) bits were available in existing/other (layer2?) headers. -mark ------------------------------------------- Introducing NetZero Long Distance Unlimited Long Distance only $29.95/ month! Sign Up Today! www.netzerolongdistance.com From owner-mpls@UU.NET Wed Oct 23 08:30:55 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15713 for ; Wed, 23 Oct 2002 08:30:55 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnluw19053 for ; Wed, 23 Oct 2002 12:33:09 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnluw17599; Wed, 23 Oct 2002 12:32:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQnluw23631 for mpls-outgoing; Wed, 23 Oct 2002 12:32:08 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnluw23626 for ; Wed, 23 Oct 2002 12:32:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnluw09620 for ; Wed, 23 Oct 2002 12:31:35 GMT From: neil.2.harrison@bt.com Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnluw16630 for ; Wed, 23 Oct 2002 12:31:35 GMT Received: from mbibipnt08.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQnluw16616 for ; Wed, 23 Oct 2002 12:31:34 GMT Received: by mbibipnt08.nat.bt.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Oct 2002 13:31:40 +0100 Message-ID: To: BHassink@HatterasNetworks.com, kireeti@juniper.net Cc: mpls@UU.NET Subject: RE: Latest MPLS Ping draft... Date: Wed, 23 Oct 2002 13:31:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Brian/Kireeti, Please see my observations below. regards, Neil Brian Hassink wrote 21 October 2002 22:09 > >[BH] Also, couldn't a (optional) "timestamp" TLV be defined rather than > > having this information as mandatory fields in the main header? > > [KK]Any particular reason? One could make TLVs of all fields, > not just the > timestamp fields. > > [BH] I think that measuring delay/RTT is not necessarily > something you want to combine with testing/validating > connectivity. And again, if this "protocol" evolves to > support other inband OAM functions, then it may become even > less relevant to a given function. NH=> I agree. It's a sensible idea to decouple performance metric measurements from defect detection/handling.....where the latter essentially boils down to some *standardised* test of connectivity. The reason why the defect/connectivity testing needs to be 'standardised' is so that we can compare apples with apples.....obviously important when running services across multiple operator networks. Similarly, it is also important to standardise the definition of the performance metrics too, and also their end-end and partitioned objective allowances so that operator's can set fair allocations. However, the specification of performance metrics and their objective allocations can't be really addressed until the basic defect detection/handling mechanisms are sorted. There are further practical reasons for decoupling performance metrics from defect detection/handling: - the one Brian has pointed out, ie it's not usual to to measure performance metrics as a continuous-time function (80/20 rule). The ability to have on-demand performance metric measurements is useful for situations like: * ad hoc trouble-shooting/diagnostics at a finer level than the basic defect detection/handling; * on important paths where it is deemed important to have such measurements running continuously; * sampling of network paths (according to some population selection method) in order to get a feel for the general performance (of some metric x say) of the network. - to make the definition of defect entry/exit criteria as simple as possible. If we do not do this then we can end up with complex combinatorial problems of defining 'up' and 'down' states of a path/network, ie as some aggregate function of varying levels of degradation across a set performance metrics x, y, z say. From owner-mpls@UU.NET Wed Oct 23 08:40:06 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16166 for ; Wed, 23 Oct 2002 08:40:05 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnluw25123 for ; Wed, 23 Oct 2002 12:42:20 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnluw24153; Wed, 23 Oct 2002 12:41:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQnluw23973 for mpls-outgoing; Wed, 23 Oct 2002 12:41:26 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnluw23958 for ; Wed, 23 Oct 2002 12:41:15 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnluw19766 for ; Wed, 23 Oct 2002 12:40:40 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnluw23290 for ; Wed, 23 Oct 2002 12:40:40 GMT Received: from ganesh.ctd.hctech.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQnluw23281 for ; Wed, 23 Oct 2002 12:40:38 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id <48ZCCRYJ>; Wed, 23 Oct 2002 18:12:00 +0530 Message-ID: <55E277B99171E041ABF5F4B1C6DDCA06AF2A4F@haritha.hclt.com> From: "Vijayanand C - CTD, Chennai." To: mpls@UU.NET Subject: Signalling across FA-LSPs in RSVP-TE Date: Wed, 23 Oct 2002 18:12:49 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hello all, I have a query in RSVP-TE. When using FA-LSPs for tunneling/label stacking how will the signalling for the bottom label be done. WIll the path message be sent through the FA-LSP itself or through the normal interfaces to the tunnel egress In the former case how will the bandwidth for signalling refreshes be accounted for in the FA-LSPs bandwidth ?In the latter case how can it be ensured that the path message does not create path state in the intermediate nodes. Thanks in advance. Vijay From owner-mpls@UU.NET Wed Oct 23 10:46:44 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08160 for ; Wed, 23 Oct 2002 10:46:44 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnlux08323; Wed, 23 Oct 2002 12:53:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQnlux24999 for mpls-outgoing; Wed, 23 Oct 2002 12:53:03 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnlux24994 for ; Wed, 23 Oct 2002 12:52:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnlux18736 for ; Wed, 23 Oct 2002 12:50:41 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlux07017 for ; Wed, 23 Oct 2002 12:50:40 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnlux07004 for ; Wed, 23 Oct 2002 12:50:39 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA10478 for ; Wed, 23 Oct 2002 08:50:39 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9NCo2O07709 for mpls@uu.net; Wed, 23 Oct 2002 08:50:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnlst13797 for ; Tue, 22 Oct 2002 22:48:22 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnlst15950 for ; Tue, 22 Oct 2002 22:48:02 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlst05311 for ; Tue, 22 Oct 2002 22:48:02 GMT Received: from sparky.afc.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: mail.afc.com [207.104.129.12]) id QQnlst05307 for ; Tue, 22 Oct 2002 22:48:01 GMT Received: (qmail 20549 invoked from network); 22 Oct 2002 22:48:06 -0000 Received: from zzzconn03.afc.com (HELO zzzconn03.fibre.com) (10.1.4.53) by mailhost.fibre.com with SMTP; 22 Oct 2002 22:48:06 -0000 Received: FROM xconn01.fibre.com BY zzzconn03.fibre.com ; Tue Oct 22 15:49:01 2002 -0700 Received: by xconn01.fibre.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Oct 2002 15:47:41 -0700 Message-ID: From: Sanjay Nayak To: mpls@UU.NET Subject: RE: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) Date: Tue, 22 Oct 2002 15:45:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, Any draft/Rfc which talks about diff-serv over Ethernet. Thanks -sanjay -----Original Message----- From: mark seery [mailto:mseery@ix.netcom.com] Sent: Tuesday, October 22, 2002 5:48 AM To: Francois Le Faucheur (flefauch) Cc: Vishal M; mpls@UU.NET Subject: Re: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) Thanks Francois, >> [snip] PS: A few clarifications, addressing some comments in the thread: - the Shim header is absolutely always used on Ethernet << So to answer the original question, if a shim is always used, then both E-LSP and L-LSP can be supported. In a non-shim scenario, E-LSP could only be supported if the equivalent (shim header) bits were available in existing/other (layer2?) headers. -mark ------------------------------------------- Introducing NetZero Long Distance Unlimited Long Distance only $29.95/ month! Sign Up Today! www.netzerolongdistance.com From owner-mpls@UU.NET Wed Oct 23 15:44:24 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02844 for ; Wed, 23 Oct 2002 15:44:24 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlvz05622 for ; Wed, 23 Oct 2002 19:46:37 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnlvz04639; Wed, 23 Oct 2002 19:46:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQnlvz24799 for mpls-outgoing; Wed, 23 Oct 2002 19:45:52 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnlvz24792 for ; Wed, 23 Oct 2002 19:45:49 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnlvy07476 for ; Wed, 23 Oct 2002 19:44:22 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlvy03407 for ; Wed, 23 Oct 2002 19:44:22 GMT Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQnlvy03400 for ; Wed, 23 Oct 2002 19:44:21 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9NJiKm52921; Wed, 23 Oct 2002 12:44:20 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id g9NJiKE61892; Wed, 23 Oct 2002 12:44:20 -0700 (PDT) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Wed, 23 Oct 2002 12:44:20 -0700 (PDT) From: Kireeti Kompella To: David Allan cc: Subject: RE: RE: Latest MPLS Ping draft... In-Reply-To: <9FBD322B7824D511B36900508BF93C9C05A23FD7@zcard031.ca.nortel.com> Message-ID: <20021023120707.C61742-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi David, On Wed, 16 Oct 2002, David Allan wrote: > section 4.5: Non-compliant routers. In general the topic of TTL came up > earlier, as there is no explicit mention of that happens when testing a path > that uses the uniform instead of the pipe model. Consistent with the > expectation of non-compliant routers, shouldn't any LSP PING request that > TTL exhausts and is not payload of the top label simply be discarded. The most common instantiation of a non-compliant router is one whose software hasn't been upgraded to know about LSP ping. It doesn't seem reasonable to make requests of such routers to know enough about LSP ping to discard LSP ping packets whose TTL has expired. On the other hand, for a router that knows about LSP ping but say doesn't implement the traceroute mode, it may make sense to say what to do with ping packets whose TTL expired. But since senders have to deal with TTL-expired ICMP anyway, it seems to somewhat redundant (IMO). It would make sense to state that *compliant* routers that reply to a LSP "traceroute" SHOULD NOT also send a TTL-expired ICMP. That work for you? > Section 2: Motivations: A bit more discussion of what consistutes a > "reasonable time" and what factors affect this would be useful. In some > applications such as LDP/ECMP etc. detection time would appear to be in > proportion to network diameter. What constitutes "reasonable time" depends entirely on the SP and their customers. I'd personally rather not go down that rathole. If you have text, you can bounce it off the mailing list and we can try to incorporate it. > Section 3: When discussing "no reply" processing, the suggestion is that the > egress router may track sequence numbers etc. This looks rather optimistic > and is not exactly consistent with the application of port rate limiting at > the egress and how use of LSP ping with MP2P will work when deployed. > Similarly, the ingress issuing multiple messages with the same sequence > number in hope that the egress will respond to one of them seems rather > perverse. Presumably the egress can similarly reply to all of them hoping > the ingress will see one of them. How does one track this (lets see, I got 3 > fives and 2 sevens) Actually, "I got an answer to five and an answer to seven" is sufficient (where "an" means at least one). > Seems to me that a superior approach (and one that does > not welcome really dumb replay attacks at some point in the future) is that > the sequence number always increments, and the receivers discard duplicates. An unstated goal is that (as far as possible) the receiver keep as little state as possible. The sender needs to keep state, so the sender can discard duplicates. Note that the technique of sending multiple pings with the same sequence number is not mandatory. > The reply codes still strike me as incomplete as an ENUM instead of a bit > map or some other format that allows multiple outcomes for a probe. See reply to other email. > Section 4.1: It seems to be a bit of a misnomer to call an RSVP Session ID > object an FEC. Could we user another term if it is simply any configuration > or administered attribute of an LSP that should be verified? Note that LDP FECs are not FECs, but names of FECs (reminiscent of Alice's conversation with Tweedle-dee? the Caterpillar? on names vs. what things are called). > I presume the use of internal loopback address range is to address ECMP, and > anything periodically pinging should be monotonically increasing the > address. Yup. > This is great if there is only one instance of ECMP downstream of > the ping source. Any comments on when multiple ECMP points are traversed by > the PING packet. Actually, this works (to the extent it works at all) with any number of ECMP points. Do you have a counter-example? > Currently ECMP is proprietary, so I am not sure if this can > be characterized or one can be sure that this will actually test everything. I am sure this won't test everything. I am equally certain that the IETF is not the place to standardise ECMP (IMO) -- in fact, I don't personally believe that ECMP should be standardized. > Section 4.3: Some useful guidelines as to IP addresses NOT to respond to > might be a good idea. ? > Section 5.3: Other than being modelled on ICMP, it has otherwise not been > mentioned. Why the reference to using explicit NULL with ICMP here? Will fix. Thanks! Kireeti. From owner-mpls@UU.NET Wed Oct 23 16:34:31 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04567 for ; Wed, 23 Oct 2002 16:34:31 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlwc09187 for ; Wed, 23 Oct 2002 20:36:45 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnlwc07602; Wed, 23 Oct 2002 20:36:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQnlwc15293 for mpls-outgoing; Wed, 23 Oct 2002 20:35:47 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnlwc15284 for ; Wed, 23 Oct 2002 20:35:34 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnlwc21608 for ; Wed, 23 Oct 2002 20:34:42 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlwc15743 for ; Wed, 23 Oct 2002 20:34:42 GMT Received: from zcars04f.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQnlwc15738 for ; Wed, 23 Oct 2002 20:34:41 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9NKYdN07669; Wed, 23 Oct 2002 16:34:39 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Oct 2002 16:34:39 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C05BC3910@zcard031.ca.nortel.com> From: "David Allan" To: Kireeti Kompella Cc: mpls@UU.NET Subject: RE: RE: Latest MPLS Ping draft... Date: Wed, 23 Oct 2002 16:34:38 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Hi Kireeti: > > section 4.5: Non-compliant routers. In general the topic of TTL came up > > earlier, as there is no explicit mention of that happens when testing a path > > that uses the uniform instead of the pipe model. Consistent with the > > expectation of non-compliant routers, shouldn't any LSP PING request that > > TTL exhausts and is not payload of the top label simply be discarded. > > The most common instantiation of a non-compliant router is one whose > software hasn't been upgraded to know about LSP ping. It doesn't seem > reasonable to make requests of such routers to know enough about LSP > ping to discard LSP ping packets whose TTL has expired. > > On the other hand, for a router that knows about LSP ping but say doesn't > implement the traceroute mode, it may make sense to say what to do with > ping packets whose TTL expired. But since senders have to deal with > TTL-expired ICMP anyway, it seems to somewhat redundant (IMO). > > It would make sense to state that *compliant* routers that reply to > a LSP "traceroute" SHOULD NOT also send a TTL-expired ICMP. That work > for you? yes, that works... however I wasn't clear in that I munged two thoughts together. IMHO an LSP PING PDU that is not associated with the top label should be discarded when TTL expires (and that can happen in uniform model), unless folks think we are doing GTTP as well here. > > Section 2: Motivations: A bit more discussion of what consistutes a > > "reasonable time" and what factors affect this would be > useful. In some > > applications such as LDP/ECMP etc. detection time would > appear to be in > > proportion to network diameter. > > What constitutes "reasonable time" depends entirely on the SP and > their customers. I'd personally rather not go down that rathole. > If you have text, you can bounce it off the mailing list and we can > try to incorporate it. I'll think about it. IMHO, the combination of ECMP, rate of change of the 127. address, number of sources pinging away, amount of ECMP encountered, rate limiting at receivers etc. manifests itself in an unbounded detection time for some problems. You are right that text to describe it is a rat hole, so is bounding the detection time (which fits my definition of reasonable). > > Section 3: When discussing "no reply" processing, the suggestion is that the > > egress router may track sequence numbers etc. This looks rather optimistic > > and is not exactly consistent with the application of port rate limiting at > > the egress and how use of LSP ping with MP2P will work when deployed. > > Similarly, the ingress issuing multiple messages with the same sequence > > number in hope that the egress will respond to one of them seems rather > > perverse. Presumably the egress can similarly reply to all of them hoping > > the ingress will see one of them. How does one track this (lets see, I got 3 > > fives and 2 sevens) > > Actually, "I got an answer to five and an answer to seven" is > sufficient (where "an" means at least one). Understood ;-), but it still seems rather redundant, I can also just increment and say I got answers to 6,7,8,12 and 15. > > > Seems to me that a superior approach (and one that does > > not welcome really dumb replay attacks at some point in the > future) is that > > the sequence number always increments, and the receivers > discard duplicates. > > An unstated goal is that (as far as possible) the receiver keep as > little state as possible. The sender needs to keep state, so > the sender can discard duplicates. Note that the technique of sending > multiple pings with the same sequence number is not mandatory. And in no reply mode, the receiver presumably may track sequence numbers, and without a history of how many duplicates the sender sent, cannot infer anything meaningful. IMHO use of duplicates inherently loses useful information. > > > The reply codes still strike me as incomplete as an ENUM > instead of a bit > > map or some other format that allows multiple outcomes for a probe. > > See reply to other email. OK, missed that. > > Section 4.1: It seems to be a bit of a misnomer to call an > RSVP Session ID > > object an FEC. Could we user another term if it is simply > any configuration > > or administered attribute of an LSP that should be verified? > > Note that LDP FECs are not FECs, but names of FECs (reminiscent of > Alice's conversation with Tweedle-dee? the Caterpillar? on names vs. > what things are called). You seem to be suggesting that in the LDP case the actual name of an LSP is the specification of forwarding rules associated with it (or more directly, the cumulative specification of forwarding rules that the sender chooses to use), OK for LDP. So then what LSP-PING sends is not the FEC but the name of the LSP, in the RSVP case it is sending the name. So the logic appears to be reversed and the term should not be FEC but "name". Shakespeare's rose is a rose is fine by me, if we are consistent. If we want to call names FECs fine by me, but lets pin down one immutable definition for this document at the beginning that identifies the current interpretation of the term FEC at the time of writing. > > > I presume the use of internal loopback address range is to > address ECMP, and > > anything periodically pinging should be monotonically increasing the > > address. > > Yup. > > > This is great if there is only one instance of ECMP downstream of > > the ping source. Any comments on when multiple ECMP points are traversed by > > the PING packet. > > Actually, this works (to the extent it works at all) with any number > of ECMP points. Do you have a counter-example? The example that came to mind, is that I have multiple ECMP points I traverse in sequence, and they have the same fan out, then what hashes to choice "two" after the first, will pathologically hash to choice "two" at all subsequent ECMP points. Mind you, if they all implement unique algorithms or use additional local information to ensure a unique result, this problem doesn't exist, but proving you actually can exercise all potential paths from a single upstream point is a bit tricky. > > > Currently ECMP is proprietary, so I am not sure if this can > > be characterized or one can be sure that this will actually > test everything. > > I am sure this won't test everything. I am equally certain that the > IETF is not the place to standardise ECMP (IMO) -- in fact, I don't > personally believe that ECMP should be standardized. I think some degree of specification (at least with respect to behavioural properties) that vendors may choose to support or not support is useful for providers. In particular when it impacts the testability of their network. Thats the goal of the load balancing guidelines draft I posted not that long ago. Folks who want certain testability may wish to cap the open endedness of ECMP behavior, some may not. > > > Section 4.3: Some useful guidelines as to IP addresses NOT > to respond to > > might be a good idea. > > ? There are no representations as to source addresses that should be inadmissable, while we have lots of experience with ICMP on things that are currently filtered (such as smurf attacks and the like). Current security concerns seem to simply focus on DOS attacks associated with volume of messaging and not attacks that get the network to actually generate that volume.... > > > Section 5.3: Other than being modelled on ICMP, it has > otherwise not been > > mentioned. Why the reference to using explicit NULL with ICMP here? > > Will fix. OK thanks Dave From owner-mpls@UU.NET Wed Oct 23 23:56:56 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16178 for ; Wed, 23 Oct 2002 23:56:56 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlxf04634 for ; Thu, 24 Oct 2002 03:59:07 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnlxf02766; Thu, 24 Oct 2002 03:58:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQnlxf25544 for mpls-outgoing; Thu, 24 Oct 2002 03:57:54 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnlxf25539 for ; Thu, 24 Oct 2002 03:57:48 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnlxf26311 for ; Thu, 24 Oct 2002 03:57:16 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlxf19338 for ; Thu, 24 Oct 2002 03:57:16 GMT Received: from wiprom2mx1.wipro.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQnlxf19303 for ; Thu, 24 Oct 2002 03:57:14 GMT Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g9O3uin07465 for ; Thu, 24 Oct 2002 09:27:04 +0530 (IST) Received: from soflt.ipneg.wipro.com ([10.117.3.193]) by kmglmail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id H4GWAJ00.M7K; Thu, 24 Oct 2002 09:26:43 +0530 Date: Thu, 24 Oct 2002 09:24:09 +0530 (IST) From: "chetan kumar s" X-X-Sender: Reply-To: To: "Vijayanand C - CTD Chennai." cc: Subject: Re: Signalling across FA-LSPs in RSVP-TE In-Reply-To: <55E277B99171E041ABF5F4B1C6DDCA06AF2A4F@haritha.hclt.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Wed, 23 Oct 2002, Vijayanand C - CTD, Chennai. wrote: > When using FA-LSPs for tunneling/label stacking how will the signalling for > the bottom label be done. WIll the path message be sent through the FA-LSP > itself or through the normal interfaces to the tunnel egress Hi Vijay One has two options to do this (similar to what U have said). One can send this over normal interface, and in case of control and data plane separation, set NHOP to the control plane address. And make sure that U do not set the "IP Router Alert" option. Thus U can stop PSB creation at intermediate routers. Alternative option would be to tunnel to the FA LSP tail-end, in this case no one stops from using FA LSP itself. How to account for path message refreshes is, by making sure that some bandwidth is set aside for control plane data traffic. Thanks Chetan S > > In the former case how will the bandwidth for signalling refreshes be > accounted for in the FA-LSPs bandwidth ?In the latter case how can it be > ensured that the path message does not create path state in the intermediate > nodes. > > Thanks in advance. > Vijay > -- ------------ Thinking is progress, non thinking is destruction of individual, organization and nation -Abdul Kalam From owner-mpls@UU.NET Thu Oct 24 12:01:18 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13571 for ; Thu, 24 Oct 2002 12:01:18 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlzc18907 for ; Thu, 24 Oct 2002 16:03:33 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnlzc13835; Thu, 24 Oct 2002 16:01:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQnlzc12601 for mpls-outgoing; Thu, 24 Oct 2002 16:00:57 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnlzc11700 for ; Thu, 24 Oct 2002 16:00:42 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnlzc18090 for ; Thu, 24 Oct 2002 16:00:32 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlzc22401 for ; Thu, 24 Oct 2002 16:00:31 GMT Received: from smtp1.opnet.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp1.opnet.com [141.156.71.6]) id QQnlzc22393 for ; Thu, 24 Oct 2002 16:00:31 GMT Received: from wtn10216.opnet.com (unverified) by smtp1.opnet.com (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Thu, 24 Oct 2002 11:59:30 -0400 Message-Id: <5.0.0.25.2.20021024115939.02ce6d50@mail.opnet.com> X-Sender: skalra@mail.opnet.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 24 Oct 2002 12:02:18 -0400 To: mpls@UU.NET From: Sachin Kalra Subject: Does a labeled packet go through "Packet Filtering/Policy Routing/Filter Based Forwarding"? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Dear MPLS Community: A quick question. Does a labeled packet go through "Packet Filtering/Policy Routing/Filter Based Forwarding"? Thanks, Sachin Kalra From owner-mpls@UU.NET Thu Oct 24 12:40:28 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15228 for ; Thu, 24 Oct 2002 12:40:27 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlze08224 for ; Thu, 24 Oct 2002 16:42:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnlze07276; Thu, 24 Oct 2002 16:42:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQnlze27820 for mpls-outgoing; Thu, 24 Oct 2002 16:42:03 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnlze27804 for ; Thu, 24 Oct 2002 16:41:52 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnlze23714 for ; Thu, 24 Oct 2002 16:41:32 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlze01350 for ; Thu, 24 Oct 2002 16:41:32 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQnlze01343 for ; Thu, 24 Oct 2002 16:41:31 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA06542 for ; Thu, 24 Oct 2002 12:41:30 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA15172 for ; Thu, 24 Oct 2002 12:41:30 -0400 (EDT) Message-ID: <3DB822D8.3000400@marconi.com> Date: Thu, 24 Oct 2002 12:42:00 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: IETF MPLS List Subject: Re: Does a labeled packet go through "Packet Filtering/Policy Routing/Filter Based Forwarding"? References: <5.0.0.25.2.20021024115939.02ce6d50@mail.opnet.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Sachin Kalra wrote: > > A quick question. Does a labeled packet go through "Packet > Filtering/Policy Routing/Filter Based Forwarding"? What would you have it filter on? A transit router should not make forwarding decisions based on anything other than the topmost label. If you start drilling down into the packet payload to make these decisions, then why bother using MPLS at all? One of the key reasons for MPLS these days is the ability to optimize traffic engineering. You will decide your route through the network when you set up the LSP. The node at the LSP's ingress will decide which packets to forward into which LSP. Once that decision is made, the packets should not be examined again until they emerge from the other end of the LSP. -- David From owner-mpls@UU.NET Thu Oct 24 15:19:01 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20398 for ; Thu, 24 Oct 2002 15:19:01 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlzp08749 for ; Thu, 24 Oct 2002 19:21:18 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnlzp07512; Thu, 24 Oct 2002 19:20:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQnlzp00677 for mpls-outgoing; Thu, 24 Oct 2002 19:20:20 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnlzp00672 for ; Thu, 24 Oct 2002 19:20:19 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnlzp01064 for ; Thu, 24 Oct 2002 19:19:14 GMT From: jsullivan@quarrytech.com Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlzp14896 for ; Thu, 24 Oct 2002 19:19:14 GMT Received: from qtech1.quarrytech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQnlzp14889 for ; Thu, 24 Oct 2002 19:19:14 GMT Received: by email.quarrytech.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Oct 2002 15:19:12 -0400 Message-ID: <496A8683261CD211BF6C0008C733261A01AB373E@email.quarrytech.com> To: mpls@UU.NET Cc: jsullivan@quarrytech.com Subject: LDP support for deaggregation as described in MPLS Arch MPLS an d Hop by Hop Routed Traffic Date: Thu, 24 Oct 2002 15:19:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk This is a question regarding LDP, which supports MPLS forwarding along normally routed paths, and sections 4.1.3. and 4.1.4 of the MPLS architecture spec which describe the rules for using the Hop by Hop path as the LSP, and when an LSR is considered to be an LSP Egress for an address prefix respectively. Section 4.1.3 includes the following example: (assume that LDP running on R1, R2, R3) Suppose, for example, that packet P, with destination address 10.2.153.178 needs to go from R1 to R2 to R3. Suppose also that R2 advertises address prefix 10.2/16 to R1, but R3 advertises 10.2.153/23, 10.2.154/23, and 10.2/16 to R2. That is, R2 is advertising an "aggregated route" to R1. In this situation, packet P can be label Switched until it reaches R2, but since R2 has performed route aggregation, it must execute the best match algorithm to find P's FEC. 1. This example implies to me that an LSR must be able to support the ability to be both an egress and an ingress for the same FEC, in this case 10.2/16. For example R2 must be the deaggregation point and thus the egress for 10.2/16, which will force a BMP lookup which may then match 10.2/16(because it didn't match either of the more specific routes), causing a labeled packet to be sent to R3. Is my understanding of this correct ? 2. As a practical consideration it is worth asking under what conditions is it reasonable to expect an LSR to have knowledge of the routes in upstream LSRs, that would allow it to make the correct decision regarding deaggregation for a particular FEC. I would be interested in hearing what consideration was given to this issue in real product implementations. Possible Strategies: a) Assume all LSRs have the exact same set of routes and don't worry about deaggregation. b) Use route summary information to affect the deaggregation decision. Is this practical to implement ? c) other considerations ? thanks Jim From owner-mpls@UU.NET Thu Oct 24 17:48:45 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24928 for ; Thu, 24 Oct 2002 17:48:45 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlzz04892 for ; Thu, 24 Oct 2002 21:50:58 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnlzz03392; Thu, 24 Oct 2002 21:50:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQnlzz15570 for mpls-outgoing; Thu, 24 Oct 2002 21:49:39 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnlzz15561 for ; Thu, 24 Oct 2002 21:49:27 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnlzz12766 for ; Thu, 24 Oct 2002 21:48:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlzz19128 for ; Thu, 24 Oct 2002 21:48:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnlzz19122 for ; Thu, 24 Oct 2002 21:48:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA07598 for ; Thu, 24 Oct 2002 17:48:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9OLm1T17752 for mpls@uu.net; Thu, 24 Oct 2002 17:48:01 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnlzz15454 for ; Thu, 24 Oct 2002 21:46:37 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnlzz26026 for ; Thu, 24 Oct 2002 21:46:32 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnlzz18286 for ; Thu, 24 Oct 2002 21:46:32 GMT Received: from father.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQnlzz18280 for ; Thu, 24 Oct 2002 21:46:31 GMT Received: (qmail 21113 invoked by uid 104); 24 Oct 2002 21:46:31 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4230. . Clean. Processed in 0.498466 secs); 24 Oct 2002 21:46:31 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 24 Oct 2002 21:46:30 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g9OLkGQ12774; Thu, 24 Oct 2002 14:46:16 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id <40J3JGCP>; Thu, 24 Oct 2002 14:46:15 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03A24@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'jsullivan@quarrytech.com'" , mpls@UU.NET Subject: RE: LDP support for deaggregation as described in MPLS Arch MPLS an d Hop by Hop Routed Traffic Date: Thu, 24 Oct 2002 14:46:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > 1. This example implies to me that an LSR must be able to support the > ability to be both an egress and an ingress for the same FEC, in > this case 10.2/16. For example R2 must be the deaggregation > point and thus the egress for 10.2/16, which will force a BMP > lookup which may then match 10.2/16(because it didn't match > either of the more specific routes), causing a labeled packet > to be sent to R3. > Is my understanding of this correct ? Yes. R2 must terminate the incoming LSP, do an IP lookup and forward the packet in a new LSP. > > > 2. As a practical consideration it is worth asking under what > conditions is it reasonable to expect an LSR to have knowledge of > the routes in upstream LSRs, that would allow it to make the > correct decision regarding deaggregation for a particular FEC. > I would be interested in hearing what consideration was > given to this issue in real product implementations. LSR2 does not need any knowledge of upstream LSRs. The decision to aggregate/de-aggregate the routes is local to R2. -Shahram > > Possible Strategies: > a) Assume all LSRs have the exact same set of routes and > don't worry about deaggregation. > > b) Use route summary information to affect the deaggregation > decision. > Is this practical to implement ? > > c) other considerations ? > > > > thanks Jim > > > > > > > > > From owner-mpls@UU.NET Thu Oct 24 18:23:54 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25725 for ; Thu, 24 Oct 2002 18:23:53 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmab07497 for ; Thu, 24 Oct 2002 22:26:05 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnmab05823; Thu, 24 Oct 2002 22:25:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQnmab05277 for mpls-outgoing; Thu, 24 Oct 2002 22:25:01 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnmab05263 for ; Thu, 24 Oct 2002 22:24:55 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnmab20262 for ; Thu, 24 Oct 2002 22:24:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmab13359 for ; Thu, 24 Oct 2002 22:24:07 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQnmab13354 for ; Thu, 24 Oct 2002 22:24:07 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA02568; Thu, 24 Oct 2002 18:24:04 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA00833; Thu, 24 Oct 2002 18:24:05 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <4W8KBXDJ>; Thu, 24 Oct 2002 18:24:05 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55763413@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Shahram Davari'" , "'jsullivan@quarrytech.com'" , mpls@UU.NET Subject: RE: LDP support for deaggregation as described in MPLS Arch MPLS an d Hop by Hop Routed Traffic Date: Thu, 24 Oct 2002 18:23:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Jim, -> > 1. This example implies to me that an LSR must be able to -> support the -> > ability to be both an egress and an ingress for the same FEC, in -> > this case 10.2/16. For example R2 must be the deaggregation -> > point and thus the egress for 10.2/16, which will force a BMP -> > lookup which may then match 10.2/16(because it didn't match -> > either of the more specific routes), causing a labeled packet -> > to be sent to R3. -> > Is my understanding of this correct ? -> -> Yes. R2 must terminate the incoming LSP, do an IP lookup and -> forward the packet in a new LSP. Addition to what Shahram said, this is "a kind of" LSP stitching. As the LDP and RSVP-TE standards stands, LDP can establish a single LSP (with out stitched) from one routing to another domain (for example, different ISIS levels or OSPF areas). But when it comes to aggregation (here in the above example) if R2 is an L1/2 or ABR router then the LSR is internally split into egress LER and ingress LER to stitch the LSP across routing domains. It is a normal convention, at least people think, that the LSP stitching is applicable only in TE environments only using RSVP-TE (again, because, RSVP-TE as it stands now can't do TE across different TE domains) Cheers. -- Venkata From owner-mpls@UU.NET Fri Oct 25 02:35:52 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14080 for ; Fri, 25 Oct 2002 02:35:52 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmbi11661 for ; Fri, 25 Oct 2002 06:38:08 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnmbi10332; Fri, 25 Oct 2002 06:37:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQnmbi26167 for mpls-outgoing; Fri, 25 Oct 2002 06:37:15 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnmbi26160 for ; Fri, 25 Oct 2002 06:37:05 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnmbi05600 for ; Fri, 25 Oct 2002 06:36:31 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmbi09150 for ; Fri, 25 Oct 2002 06:36:31 GMT Received: from wiprom2mx1.wipro.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQnmbi09119 for ; Fri, 25 Oct 2002 06:36:28 GMT Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g9P6aIm20450 for ; Fri, 25 Oct 2002 12:06:25 +0530 (IST) Received: from soflt.ipneg.wipro.com ([10.117.3.193]) by kmglmail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id H4IYCH00.08X; Fri, 25 Oct 2002 12:06:17 +0530 Date: Fri, 25 Oct 2002 12:03:39 +0530 (IST) From: "chetan kumar s" X-X-Sender: Reply-To: To: Sachin Kalra cc: Subject: Re: Does a labeled packet go through "Packet Filtering/Policy Routing/Filter Based Forwarding"? In-Reply-To: <5.0.0.25.2.20021024115939.02ce6d50@mail.opnet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Thu, 24 Oct 2002, Sachin Kalra wrote: > Dear MPLS Community: > > A quick question. Does a labeled packet go through "Packet Filtering/Policy > Routing/Filter Based Forwarding"? Yes, the labeled packets go through "Packet Filtering/Policy Routing/Filter Based Forwarding". But unlike regular IP forwarding that requires these rules to be applied at every nodes, in case of MPLS these rules can be applied at one single node. And rest is done by the MPLS network. In MPLS each packet is assigned to an FEC (Forward Equivalent Class). Once this is done, only at the ingress, the packets are labled and rest of the network identifies the packet based on this label. One can assign packet to a FEC based on IP dest address combined with Filtering/Policy based rules. Thanks Chetan S > > Thanks, > Sachin Kalra > -- ------------ Thinking is progress, non thinking is destruction of individual, organization and nation -Abdul Kalam From owner-mpls@UU.NET Fri Oct 25 05:26:02 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16754 for ; Fri, 25 Oct 2002 05:26:01 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmbt17052 for ; Fri, 25 Oct 2002 09:28:18 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnmbt16010; Fri, 25 Oct 2002 09:27:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQnmbt28691 for mpls-outgoing; Fri, 25 Oct 2002 09:27:35 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnmbt28686 for ; Fri, 25 Oct 2002 09:27:23 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnmbt12485 for ; Fri, 25 Oct 2002 09:26:40 GMT From: neil.2.harrison@bt.com Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmbt10398 for ; Fri, 25 Oct 2002 09:26:39 GMT Received: from cbibipnt05.hc.bt.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQnmbt10383 for ; Fri, 25 Oct 2002 09:26:39 GMT Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Fri, 25 Oct 2002 10:26:40 +0100 Message-ID: To: chetan.kumar@wipro.com Cc: mpls@UU.NET Subject: RE: Does a labeled packet go through "Packet Filtering/Policy Rou ting/Filter Based Forwarding"? Date: Fri, 25 Oct 2002 10:26:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Chetan, What about LDP and the desire to do a sort-of TE function using ECMP? This would seem to somewhat negate the intention of ingress 1-shot route/policy selection. Also check out LSP-Ping which changes an IP address in an attempt to exercise the different ECMP-selected routings. regards, Neil > -----Original Message----- > From: chetan kumar s [mailto:chetan.kumar@wipro.com] > Sent: 25 October 2002 07:34 > To: Sachin Kalra > Cc: mpls > Subject: Re: Does a labeled packet go through "Packet Filtering/Policy > Routing/Filter Based Forwarding"? > > > On Thu, 24 Oct 2002, Sachin Kalra wrote: > > > Dear MPLS Community: > > > > A quick question. Does a labeled packet go through "Packet > Filtering/Policy > > Routing/Filter Based Forwarding"? > > Yes, the labeled packets go through "Packet Filtering/Policy > Routing/Filter Based Forwarding". But unlike regular IP > forwarding that > requires these rules to be applied at every nodes, in case of > MPLS these > rules can be applied at one single node. And rest is done by the MPLS > network. > In MPLS each packet is assigned to an FEC (Forward Equivalent > Class). Once this is done, only at the ingress, the packets are labled > and rest of the network identifies the packet based on this > label. One can > assign packet to a FEC based on IP dest address combined > with Filtering/Policy based rules. > > Thanks > Chetan S > > > > > > Thanks, > > Sachin Kalra > > > > -- > ------------ > Thinking is progress, non thinking is destruction of > individual, organization > and nation > > -Abdul Kalam > From owner-mpls@UU.NET Fri Oct 25 09:28:47 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24144 for ; Fri, 25 Oct 2002 09:28:46 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmck02720 for ; Fri, 25 Oct 2002 13:31:02 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnmck01486; Fri, 25 Oct 2002 13:30:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQnmck23005 for mpls-outgoing; Fri, 25 Oct 2002 13:30:17 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnmck22999 for ; Fri, 25 Oct 2002 13:30:04 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnmcj28763 for ; Fri, 25 Oct 2002 13:29:42 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmcj22671 for ; Fri, 25 Oct 2002 13:29:42 GMT Received: from xover.netplane.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fwout.maker.com [12.27.183.253] (may be forged)) id QQnmcj22656 for ; Fri, 25 Oct 2002 13:29:41 GMT Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HPHL5>; Fri, 25 Oct 2002 09:29:42 -0400 Message-ID: <076236BAE727D611943F00508BA0F95914E471@XOVER.dedham.mindspeed.com> From: "Barnett, Joe" To: "'mpls@UU.NET'" Subject: Concerns regarding draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt Date: Fri, 25 Oct 2002 09:29:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > Group, > > I have a concern about some portions of > draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt. My concerns revolve around > the following network topology: > > ---g--- > / \ > a---b---c----d---e---f > > > Where a protected LSP using the detour method would be routed > [a,b,c,d,e,f], and a detour would be generated at [b](PLR) to avoid node > [c]. There would be an expected merge at node [d](MP). > > The basis for my concern is that the draft specifies in section 5: > "Upon receiving the local protection requests for a protected LSP, > the PLRs must try to establish the detour LSPs immediately." > > Furthermore, what if at [c] the protected path message was delayed for > some unknow reason which caused the detour path to reach [d] first causing > the detour's path message to propagate downstream. According to section 7, > it is stated: > > "The source address of the backup LSP is the current PLR, > For setting detours (Section 5), the destination MUST be > the tail-end of the protected LSP" > > What this indicates to me is that the detours explicit path generated by > CSPF(perhaps) would be [b,g,d,e,f], and if the delay actaully occured on > as described, wouldn't the detour path message be propagated all the way > to [f]? If this was to occur, and just for argument's sake, that node [d] > was able to merge the protected path state and the detour path state, and > then send on only the protected path message after the merge, how would > node [e] recognize that the subsequent path message containing the > FASTREROUTE object was in relation with the previously received path > message with a DETOUR object? I ask this due to the fact that if using the > Sender-Template Specific method, wouldn't the IP address differ in the > SENDER_TEMPLATE? > > Knowing this, the identification information presented in the draft > (Sender,Session) could not be used at [e], since in the protected path > message's SENDER_TEMPLATE will contain the IP address of [a]. Am I missing > something? (IMHO) Wouldn't it be better for all PLRs to wait for the RESV > of the protected LSP before creating a detour? Or at least specify a way > for CSPF to generate an ERO that ends at [d] and that the MP must not > propagate the detour path message on downstream? > > Kind regards, > Joseph Barnett From owner-mpls@UU.NET Fri Oct 25 09:31:32 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24244 for ; Fri, 25 Oct 2002 09:31:32 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmck08892 for ; Fri, 25 Oct 2002 13:33:48 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnmck02412; Fri, 25 Oct 2002 13:30:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQnmck23010 for mpls-outgoing; Fri, 25 Oct 2002 13:30:22 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnmck23000 for ; Fri, 25 Oct 2002 13:30:07 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnmcj27703 for ; Fri, 25 Oct 2002 13:29:24 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmcj00501 for ; Fri, 25 Oct 2002 13:29:24 GMT Received: from xover.netplane.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fwout.maker.com [12.27.183.253] (may be forged)) id QQnmcj00483 for ; Fri, 25 Oct 2002 13:29:23 GMT Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HPHLY>; Fri, 25 Oct 2002 09:29:23 -0400 Message-ID: <076236BAE727D611943F00508BA0F95914E470@XOVER.dedham.mindspeed.com> From: "Barnett, Joe" To: "'mpls@UU.NET'" Subject: Concerns regarding draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt Date: Fri, 25 Oct 2002 09:29:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > Group, > > I have a concern about some portions of > draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt. My concerns revolve around > the following network topology: > > ---g--- > / \ > a---b---c----d---e---f > > > Where a protected LSP using the detour method would be routed > [a,b,c,d,e,f], and a detour would be generated at [b](PLR) to avoid node > [c]. There would be an expected merge at node [d](MP). > > The basis for my concern is that the draft specifies in section 5: > "Upon receiving the local protection requests for a protected LSP, > the PLRs must try to establish the detour LSPs immediately." > > Furthermore, what if at [c] the protected path message was delayed for > some unknow reason which caused the detour path to reach [d] first causing > the detour's path message to propagate downstream. According to section 7, > it is stated: > > "The source address of the backup LSP is the current PLR, > For setting detours (Section 5), the destination MUST be > the tail-end of the protected LSP" > > What this indicates to me is that the detours explicit path generated by > CSPF(perhaps) would be [b,g,d,e,f], and if the delay actually occured on > the protected path between b and d , wouldn't the detour path message be > propagated all the way to [f]? If this was to occur, and just for > argument's sake, that node [d] was able to merge the protected path state > and the detour path state, and then send on only the protected path > message after the merge, how would node [e] recognize that the subsequent > path message containing the FASTREROUTE object was in relation with the > previously received path message with a DETOUR object? I ask this due to > the fact that if using the Sender-Template Specific method, wouldn't the > IP address differ in the SENDER_TEMPLATE? > > Knowing this, the identification information presented in the draft > (Sender,Session) could not be used at [e], since in the protected path > message's SENDER_TEMPLATE will contain the IP address of [a]. Am I missing > something? (IMHO) Wouldn't it be better for all PLRs to wait for the RESV > of the protected LSP before creating a detour? Or at least specify a way > for CSPF to generate an ERO that ends at [d] and that the MP must not > propagate the detour path message on downstream? > > Kind regards, > Joseph Barnett From owner-mpls@UU.NET Fri Oct 25 09:50:08 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24906 for ; Fri, 25 Oct 2002 09:50:08 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmcl06903 for ; Fri, 25 Oct 2002 13:52:26 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnmcl25614; Fri, 25 Oct 2002 13:48:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQnmcl24675 for mpls-outgoing; Fri, 25 Oct 2002 13:47:55 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnmcl24666 for ; Fri, 25 Oct 2002 13:47:41 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnmcl21892 for ; Fri, 25 Oct 2002 13:47:21 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmcl24772 for ; Fri, 25 Oct 2002 13:47:21 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnmcl24767 for ; Fri, 25 Oct 2002 13:47:20 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA24494 for ; Fri, 25 Oct 2002 09:47:20 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9PDlKW14114 for mpls@uu.net; Fri, 25 Oct 2002 09:47:20 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnmcc10845 for ; Fri, 25 Oct 2002 11:31:53 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnmcc18378 for ; Fri, 25 Oct 2002 11:31:35 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmcc06750 for ; Fri, 25 Oct 2002 11:31:35 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQnmcc06716 for ; Fri, 25 Oct 2002 11:31:30 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20293; Fri, 25 Oct 2002 07:29:10 -0400 (EDT) Message-Id: <200210251129.HAA20293@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-recovery-frmwrk-08.txt Date: Fri, 25 Oct 2002 07:29:10 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --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 : Framework for MPLS-based Recovery Author(s) : V. Sharma, F. Hellstrand Filename : draft-ietf-mpls-recovery-frmwrk-08.txt Pages : 34 Date : 2002-10-24 Multi-protocol label switching (MPLS) integrates the label swapping forwarding paradigm with network layer routing. To deliver reliable service, MPLS requires a set of procedures to provide protection of the traffic carried on different paths. This requires that the label switching routers (LSRs) support fault detection, fault notification, and fault recovery mechanisms, and that MPLS signaling supports the configuration of recovery. With these objectives in mind, this document specifies a framework for MPLS based recovery. Restart issues are not included in this framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-recovery-frmwrk-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-recovery-frmwrk-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-recovery-frmwrk-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-24142350.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-recovery-frmwrk-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-recovery-frmwrk-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-24142350.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Oct 25 11:38:53 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28760 for ; Fri, 25 Oct 2002 11:38:52 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmcs27887 for ; Fri, 25 Oct 2002 15:41:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnmcs26846; Fri, 25 Oct 2002 15:40:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQnmcs06972 for mpls-outgoing; Fri, 25 Oct 2002 15:40:19 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnmcs06962 for ; Fri, 25 Oct 2002 15:40:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnmcs06519 for ; Fri, 25 Oct 2002 15:37:52 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmcs25800 for ; Fri, 25 Oct 2002 15:37:52 GMT Received: from bridge.axiowave.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) id QQnmcs25788 for ; Fri, 25 Oct 2002 15:37:52 GMT Message-ID: From: Ling Li To: "'Barnett, Joe'" , "'mpls@UU.NET'" Subject: RE: Concerns regarding draft-ietf-mpls-rsvp-lsp-fastreroute-00.tx t Date: Fri, 25 Oct 2002 11:37:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, Joe, Section 7 of the same draft says: "To setup the detours described in Section 5 and the bypass tunnels in Section 6, CSPF may be used to find the optimal route. Before CSPF computation, the following information should be collected at a PLR: - The list of downstream nodes that the protected LSP passes through. This information is readily available from the RECORD_ROUTE objects during LSP setup. Note, a protected LSP's ERO may not provide adequate information since the LSP could be a loose routed path." Although the draft also says in Section 5.2. that "Upon receiving a Path message that contains a FAST_REROUTE object, a PLR needs to run CPSF based on the information provided", I think this is somehow misleading. The PLR has to wait patiently for the RRO in Resv message to run CSPF. My suggestion is please do not bother about "the PLRs must try to establish the detour LSPs immediately". Hope the authors will clarify your concerns in the next revision. Thanks, Ling Li Axiowave Networks, Inc. 200 Nickerson Road Marlborough, MA 01752 ======================== > -----Original Message----- > From: Barnett, Joe [mailto:joe.barnett@netplane.com] > Sent: Friday, October 25, 2002 9:29 AM > To: 'mpls@UU.NET' > Subject: Concerns regarding > draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt > > > > Group, > > > > I have a concern about some portions of > > draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt. My concerns > revolve around > > the following network topology: > > > > ---g--- > > / \ > > a---b---c----d---e---f > > > > > > Where a protected LSP using the detour method would be routed > > [a,b,c,d,e,f], and a detour would be generated at [b](PLR) > to avoid node > > [c]. There would be an expected merge at node [d](MP). > > > > The basis for my concern is that the draft specifies in section 5: > > "Upon receiving the local protection requests for a > protected LSP, > > the PLRs must try to establish the detour LSPs immediately." > > > > Furthermore, what if at [c] the protected path message was > delayed for > > some unknow reason which caused the detour path to reach > [d] first causing > > the detour's path message to propagate downstream. > According to section 7, > > it is stated: > > > > "The source address of the backup LSP is the current PLR, > > For setting detours (Section 5), the destination MUST be > > the tail-end of the protected LSP" > > > > What this indicates to me is that the detours explicit path > generated by > > CSPF(perhaps) would be [b,g,d,e,f], and if the delay > actually occured on > > the protected path between b and d , wouldn't the detour > path message be > > propagated all the way to [f]? If this was to occur, and just for > > argument's sake, that node [d] was able to merge the > protected path state > > and the detour path state, and then send on only the protected path > > message after the merge, how would node [e] recognize that > the subsequent > > path message containing the FASTREROUTE object was in > relation with the > > previously received path message with a DETOUR object? I > ask this due to > > the fact that if using the Sender-Template Specific method, > wouldn't the > > IP address differ in the SENDER_TEMPLATE? > > > > Knowing this, the identification information presented in the draft > > (Sender,Session) could not be used at [e], since in the > protected path > > message's SENDER_TEMPLATE will contain the IP address of > [a]. Am I missing > > something? (IMHO) Wouldn't it be better for all PLRs to > wait for the RESV > > of the protected LSP before creating a detour? Or at least > specify a way > > for CSPF to generate an ERO that ends at [d] and that the > MP must not > > propagate the detour path message on downstream? > > > > Kind regards, > > Joseph Barnett > From owner-mpls@UU.NET Fri Oct 25 14:30:57 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05797 for ; Fri, 25 Oct 2002 14:30:57 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmde24347 for ; Fri, 25 Oct 2002 18:33:14 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnmde23360; Fri, 25 Oct 2002 18:32:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQnmde10993 for mpls-outgoing; Fri, 25 Oct 2002 18:32:32 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnmde10988 for ; Fri, 25 Oct 2002 18:32:24 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnmde12215 for ; Fri, 25 Oct 2002 18:32:18 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmde22985 for ; Fri, 25 Oct 2002 18:32:18 GMT Received: from ihemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQnmde22951 for ; Fri, 25 Oct 2002 18:32:14 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g9PIWCU01883 for ; Fri, 25 Oct 2002 14:32:13 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Oct 2002 20:32:11 +0200 Message-ID: From: "Wijnen, Bert (Bert)" To: jcucchiara@mindspring.com, Yuan Gu , "Thomas D. Nadeau" , cheenu@paramanet.com, arun@force10networks.com, hans@ipunplugged.com Cc: mpls group Subject: Reminder: we need the MPLS TE MIB revision before the deadline Date: Fri, 25 Oct 2002 20:32:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Please make sure we get a new rev ASAP so people can prepare Thanks, Bert From owner-mpls@UU.NET Mon Oct 28 01:52:07 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19274 for ; Mon, 28 Oct 2002 01:52:07 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmml10945 for ; Mon, 28 Oct 2002 06:54:23 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnmml09760; Mon, 28 Oct 2002 06:53:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQnmml19726 for mpls-outgoing; Mon, 28 Oct 2002 06:53:23 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnmml19721 for ; Mon, 28 Oct 2002 06:53:07 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnmml22890 for ; Mon, 28 Oct 2002 06:52:58 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmml07863 for ; Mon, 28 Oct 2002 06:52:57 GMT Received: from wiprom2mx1.wipro.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQnmml07826 for ; Mon, 28 Oct 2002 06:52:56 GMT Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g9S6qrm02271 for ; Mon, 28 Oct 2002 12:22:54 +0530 (IST) Received: from soflt.ipneg.wipro.com ([10.117.3.193]) by kmglmail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id H4OJ4400.G2G; Mon, 28 Oct 2002 12:22:52 +0530 Date: Mon, 28 Oct 2002 12:20:02 +0530 (IST) From: "chetan kumar s" X-X-Sender: Reply-To: To: cc: Subject: RE: Does a labeled packet go through "Packet Filtering/Policy Rou ting/Filter Based Forwarding"? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Fri, 25 Oct 2002 neil.2.harrison@bt.com wrote: > Chetan, > > What about LDP and the desire to do a sort-of TE function using ECMP? This > would seem to somewhat negate the intention of ingress 1-shot route/policy Neil, In understand these points (which are expectional for EC TE functionalities). My response was *in principle* how packet filtering/policy routing gets translates to LSP's in MPLS network.. Thanks Chetan S > selection. Also check out LSP-Ping which changes an IP address in an > attempt to exercise the different ECMP-selected routings. > > regards, Neil > > > -----Original Message----- > > From: chetan kumar s [mailto:chetan.kumar@wipro.com] > > Sent: 25 October 2002 07:34 > > To: Sachin Kalra > > Cc: mpls > > Subject: Re: Does a labeled packet go through "Packet Filtering/Policy > > Routing/Filter Based Forwarding"? > > > > > > On Thu, 24 Oct 2002, Sachin Kalra wrote: > > > > > Dear MPLS Community: > > > > > > A quick question. Does a labeled packet go through "Packet > > Filtering/Policy > > > Routing/Filter Based Forwarding"? > > > > Yes, the labeled packets go through "Packet Filtering/Policy > > Routing/Filter Based Forwarding". But unlike regular IP > > forwarding that > > requires these rules to be applied at every nodes, in case of > > MPLS these > > rules can be applied at one single node. And rest is done by the MPLS > > network. > > In MPLS each packet is assigned to an FEC (Forward Equivalent > > Class). Once this is done, only at the ingress, the packets are labled > > and rest of the network identifies the packet based on this > > label. One can > > assign packet to a FEC based on IP dest address combined > > with Filtering/Policy based rules. > > > > Thanks > > Chetan S > > > > > > > > > > Thanks, > > > Sachin Kalra > > > > > > > -- > > ------------ > > Thinking is progress, non thinking is destruction of > > individual, organization > > and nation > > > > -Abdul Kalam > > > -- ------------ Thinking is progress, non thinking is destruction of individual, organization and nation -Abdul Kalam From owner-mpls@UU.NET Mon Oct 28 15:26:48 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28356 for ; Mon, 28 Oct 2002 15:26:47 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmon19993 for ; Mon, 28 Oct 2002 20:29:04 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnmon18024; Mon, 28 Oct 2002 20:27:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQnmon27323 for mpls-outgoing; Mon, 28 Oct 2002 20:27:31 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnmon27314 for ; Mon, 28 Oct 2002 20:27:29 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnmon05198 for ; Mon, 28 Oct 2002 20:27:04 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmon17780 for ; Mon, 28 Oct 2002 20:27:04 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnmon17769 for ; Mon, 28 Oct 2002 20:27:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA27513 for ; Mon, 28 Oct 2002 15:27:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9SKR2G10014 for mpls@uu.net; Mon, 28 Oct 2002 15:27:02 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnmon27284 for ; Mon, 28 Oct 2002 20:26:24 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnmon18427 for ; Mon, 28 Oct 2002 20:26:08 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmon22962 for ; Mon, 28 Oct 2002 20:26:07 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnmon22946 for ; Mon, 28 Oct 2002 20:26:07 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9SJIcvP026567; Mon, 28 Oct 2002 14:18:39 -0500 (EST) Received: from tnadeau-w2k.cisco.com (che-vpn1-84.cisco.com [10.86.240.84]) by bucket.cisco.com (Mirapoint) with ESMTP id ACA28380; Mon, 28 Oct 2002 14:18:08 -0500 (EST) Message-Id: <4.3.2.7.2.20021028141714.05410d88@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 28 Oct 2002 14:18:06 -0400 To: "Wijnen, Bert (Bert)" From: "Thomas D. Nadeau" Subject: Re: Reminder: we need the MPLS TE MIB revision before the deadline Cc: jcucchiara@mindspring.com, Yuan Gu , cheenu@paramanet.com, arun@force10networks.com, hans@ipunplugged.com, mpls group In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk I just returned from paternity leave, so a new revision will probably not be ready for at least a week. I am finishing up the FTN MIB in the next few days, and am targeting Friday for publication. --Tom >Please make sure we get a new rev ASAP so people can prepare > >Thanks, >Bert Success is relative; the more success, the more relatives. -Anonymous From owner-mpls@UU.NET Mon Oct 28 15:53:18 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29530 for ; Mon, 28 Oct 2002 15:53:18 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmop16455 for ; Mon, 28 Oct 2002 20:55:34 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnmop14812; Mon, 28 Oct 2002 20:54:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQnmop29671 for mpls-outgoing; Mon, 28 Oct 2002 20:54:31 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnmop29666 for ; Mon, 28 Oct 2002 20:54:25 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnmop16036 for ; Mon, 28 Oct 2002 20:54:04 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmop07328 for ; Mon, 28 Oct 2002 20:54:03 GMT Received: from hoemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQnmop07313 for ; Mon, 28 Oct 2002 20:54:03 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g9SKs1B16136 for ; Mon, 28 Oct 2002 15:54:01 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Oct 2002 21:54:00 +0100 Message-ID: From: "Wijnen, Bert (Bert)" To: "Thomas D. Nadeau" , "Wijnen, Bert (Bert)" Cc: jcucchiara@mindspring.com, Yuan Gu , cheenu@paramanet.com, arun@force10networks.com, hans@ipunplugged.com, mpls group Subject: RE: Reminder: we need the MPLS TE MIB revision before the deadlin e Date: Mon, 28 Oct 2002 21:53:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk This is not good. Can anyone help? Thanks, Bert > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: maandag 28 oktober 2002 19:18 > To: Wijnen, Bert (Bert) > Cc: jcucchiara@mindspring.com; Yuan Gu; cheenu@paramanet.com; > arun@force10networks.com; hans@ipunplugged.com; mpls group > Subject: Re: Reminder: we need the MPLS TE MIB revision before the > deadline > > > > I just returned from paternity leave, so a new revision will > probably not be ready for at least a week. I am finishing up > the FTN MIB in the next few days, and am targeting Friday > for publication. > > --Tom > > >Please make sure we get a new rev ASAP so people can prepare > > > >Thanks, > >Bert > > Success is relative; the more success, the more relatives. -Anonymous > From owner-mpls@UU.NET Tue Oct 29 09:52:28 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06939 for ; Tue, 29 Oct 2002 09:52:28 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmrj16654 for ; Tue, 29 Oct 2002 14:54:46 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnmrj15242; Tue, 29 Oct 2002 14:54:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQnmrj14302 for mpls-outgoing; Tue, 29 Oct 2002 14:53:43 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnmrj14290 for ; Tue, 29 Oct 2002 14:53:39 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnmrj00445 for ; Tue, 29 Oct 2002 14:52:57 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmrj14089 for ; Tue, 29 Oct 2002 14:52:56 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnmrj14061 for ; Tue, 29 Oct 2002 14:52:55 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA25846 for ; Tue, 29 Oct 2002 09:52:54 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9TEqsf01665 for mpls@uu.net; Tue, 29 Oct 2002 09:52:54 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnmqr16483 for ; Tue, 29 Oct 2002 10:15:44 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnmqr27697 for ; Tue, 29 Oct 2002 10:15:00 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmqq13231 for ; Tue, 29 Oct 2002 10:14:59 GMT Received: from tiger.seabridge.co.il by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.25.127.226]) id QQnmqq13206 for ; Tue, 29 Oct 2002 10:14:57 GMT Received: by tiger.seabridge.co.il with Internet Mail Service (5.5.2653.19) id <460XA727>; Tue, 29 Oct 2002 12:07:46 +0200 Message-ID: From: Yaron Nachman To: "'mpls@uu.net'" Cc: Yaron Nachman , Eli Angel Subject: MPLS Label value ranges? Date: Tue, 29 Oct 2002 12:07:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Sender: owner-mpls@UU.NET Precedence: bulk Hi, Does anyone familiar with some recommendation on, or de-facto use of, the MPLS Label value ranges for Static Labels vs. Dynamic Labels? Thanks, Yaron Nachman SEABRIDGE Ltd. Tel: 972-9-7751359 Fax: 972-9-7751212 E-mail: yaron.nachman@SeabridgeNetworks.com From owner-mpls@UU.NET Tue Oct 29 11:17:56 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11371 for ; Tue, 29 Oct 2002 11:17:56 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmrp12091 for ; Tue, 29 Oct 2002 16:20:15 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnmrp11170; Tue, 29 Oct 2002 16:19:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQnmrp25015 for mpls-outgoing; Tue, 29 Oct 2002 16:19:33 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnmrp24999 for ; Tue, 29 Oct 2002 16:19:32 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnmrp19817 for ; Tue, 29 Oct 2002 16:18:20 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmrp11589 for ; Tue, 29 Oct 2002 16:18:20 GMT Received: from dnsmx1rrc.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1rrc.telcordia.com [128.96.20.41]) id QQnmrp11535 for ; Tue, 29 Oct 2002 16:18:16 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with ESMTP id LAA10279 for ; Tue, 29 Oct 2002 11:17:45 -0500 (EST) Subject: rsvpte question for rfc3209 section 4.7.3 To: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Hong Liao" Date: Tue, 29 Oct 2002 11:17:45 -0500 X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 10/29/2002 11:17:46 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, For the spec 3209, section 4.7.3 "if the requested bandwidth is not available a Patherr message is returned with an error code of 01, admission control failure, and an error value of 0002" My question is that, if I send a first Path msg with a 100% BW, and then I send a second Path msg with 30% BW with the same lspid, then Question: if they add the bandwidth to the existing reserved bandwidth if the second Path message is sent on the same lsp?? Thanks for your help. Julia From owner-mpls@UU.NET Tue Oct 29 22:22:45 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06183 for ; Tue, 29 Oct 2002 22:22:45 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmth18267 for ; Wed, 30 Oct 2002 03:25:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnmth16835; Wed, 30 Oct 2002 03:24:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQnmth21220 for mpls-outgoing; Wed, 30 Oct 2002 03:23:56 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnmth21210 for ; Wed, 30 Oct 2002 03:23:51 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnmth00691 for ; Wed, 30 Oct 2002 03:23:18 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmth14951 for ; Wed, 30 Oct 2002 03:23:17 GMT Received: from wiprom2mx1.wipro.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQnmth14848 for ; Wed, 30 Oct 2002 03:23:02 GMT Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g9U3Mxm05725 for ; Wed, 30 Oct 2002 08:53:00 +0530 (IST) Received: from blr-m1-bh1.wipro.com ([10.115.50.91]) by ace.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id H4RYQA01.GJU; Wed, 30 Oct 2002 08:52:59 +0530 Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-m1-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 30 Oct 2002 08:52:58 +0530 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: rsvpte question for rfc3209 section 4.7.3 Date: Wed, 30 Oct 2002 08:52:58 +0530 Message-ID: <4D148FEC6C003445B94D5B264288DBE92F8FD7@blr-k1-msg.wipro.com> Thread-Topic: rsvpte question for rfc3209 section 4.7.3 Thread-Index: AcJ/Z4+JjzS8riiMRcqMSUPUT63MFAAXN/aA From: "Praveen" To: "Hong Liao" , X-OriginalArrivalTime: 30 Oct 2002 03:22:58.0887 (UTC) FILETIME=[A553AD70:01C27FC3] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA06183 Hi, LSP Set up will not be complete in the event of "Admission Control Failure". The PathErr which is generated eventually should remove all the reservation state till that point. So the bandwidth requested in the second attempt will not be added to the first request. I hope I am clear. Regards Praveen -----Original Message----- From: Hong Liao [mailto:hliao@telcordia.com] Sent: Tuesday, October 29, 2002 9:48 PM To: mpls@UU.NET Subject: rsvpte question for rfc3209 section 4.7.3 Hi, For the spec 3209, section 4.7.3 "if the requested bandwidth is not available a Patherr message is returned with an error code of 01, admission control failure, and an error value of 0002" My question is that, if I send a first Path msg with a 100% BW, and then I send a second Path msg with 30% BW with the same lspid, then Question: if they add the bandwidth to the existing reserved bandwidth if the second Path message is sent on the same lsp?? Thanks for your help. Julia From owner-mpls@UU.NET Wed Oct 30 10:33:53 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19985 for ; Wed, 30 Oct 2002 10:33:52 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmve14172 for ; Wed, 30 Oct 2002 15:36:01 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnmve13581; Wed, 30 Oct 2002 15:35:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQnmve04820 for mpls-outgoing; Wed, 30 Oct 2002 15:35:20 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnmve04814 for ; Wed, 30 Oct 2002 15:35:11 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnmve26834 for ; Wed, 30 Oct 2002 15:34:05 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmve11362 for ; Wed, 30 Oct 2002 15:34:05 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnmve11315 for ; Wed, 30 Oct 2002 15:34:04 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA28761 for ; Wed, 30 Oct 2002 10:34:03 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9UFY3g12453 for mpls@uu.net; Wed, 30 Oct 2002 10:34:03 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnmve04752 for ; Wed, 30 Oct 2002 15:33:00 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnmve15879 for ; Wed, 30 Oct 2002 15:32:39 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmve27897 for ; Wed, 30 Oct 2002 15:32:39 GMT Received: from coltrane.dataconnection.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.dataconnection.com [192.91.191.4]) id QQnmve27889 for ; Wed, 30 Oct 2002 15:32:38 GMT Received: by coltrane.datcon.co.uk with Internet Mail Service (5.5.2656.59) id ; Wed, 30 Oct 2002 15:32:36 -0000 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F817F260@baker.datcon.co.uk> From: Neil Jerram To: "'jcucchiara@crescentnetworks.com'" , "'hans@ipunplugged.com'" , "'jluciani@crescentnetworks.com'" Cc: "'mpls@uu.net'" Subject: Questions on LDP MIB v9 Date: Wed, 30 Oct 2002 15:32:25 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28029.8C153610" Sender: owner-mpls@UU.NET Precedence: bulk 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_01C28029.8C153610 Content-Type: text/plain; charset="iso-8859-1" The latest LDP MIB draft looks generally good, but I see three problems with the new mplsLdpLspTable, which could be genuine, or could indicate misunderstanding on my part -- so I would appreciate your thoughts on them. I also have one question. 1. It isn't possible to represent an egress or transit LSP (A) at the same time as an ingress LSP (B), if LSP A's incoming (interface, label) are the same as LSP B's outgoing (interface, label), because the index in both cases is the same: (i1, l1). The old XCMapTable could represent both at the same time, using indices (i1, l1, 0, 0) or (i1, l1, i2, l2) for LSP A and (0, 0, i1, l1) for LSP B. 2. There is no mplsLdpLspType value to indicate a liberally retained label. 3. In the description mplsLdpLspType, your uses of "ingress" and "egress" (as verbs describing the LSP's relationship to the LSR) are exactly opposite to the conventional usage (which describes a data packet's relationship to an LSP). This could be rather confusing! 4. Do you expect implicit and explicit null labels to appear in this table, and, if so, how? The point is that implicit and explicit null labels can be distributed multiple times for different FECs in the same session, and it isn't clear in this case how the MIB indexing will work. Best regards, Neil Neil Jerram Network Protocols Group Data Connection Ltd. www.dataconnection.com ------_=_NextPart_001_01C28029.8C153610 Content-Type: text/html; charset="iso-8859-1"
The latest LDP MIB draft looks generally good, but I see three problems with the new mplsLdpLspTable, which could be genuine, or could indicate misunderstanding on my part -- so I would appreciate your thoughts on them.  I also have one question.
 
1. It isn't possible to represent an egress or transit LSP (A) at the same time as an ingress LSP (B), if LSP A's incoming (interface, label) are the same as LSP B's outgoing (interface, label), because the index in both cases is the same: (i1, l1).  The old XCMapTable could represent both at the same time, using indices (i1, l1, 0, 0) or (i1, l1, i2, l2) for LSP A and (0, 0, i1, l1) for LSP B.
 
2. There is no mplsLdpLspType value to indicate a liberally retained label.
 
3. In the description mplsLdpLspType, your uses of "ingress" and "egress" (as verbs describing the LSP's relationship to the LSR) are exactly opposite to the conventional usage (which describes a data packet's relationship to an LSP).  This could be rather confusing!
 
4. Do you expect implicit and explicit null labels to appear in this table, and, if so, how?  The point is that implicit and explicit null labels can be distributed multiple times for different FECs in the same session, and it isn't clear in this case how the MIB indexing will work.
 
Best regards,
    Neil
 
Neil Jerram
Network Protocols Group
Data Connection Ltd.
 
------_=_NextPart_001_01C28029.8C153610-- From owner-mpls@UU.NET Wed Oct 30 12:06:16 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26046 for ; Wed, 30 Oct 2002 12:06:15 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmvk24286 for ; Wed, 30 Oct 2002 17:08:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnmvk23222; Wed, 30 Oct 2002 17:08:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQnmvk15073 for mpls-outgoing; Wed, 30 Oct 2002 17:07:41 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnmvk15058 for ; Wed, 30 Oct 2002 17:07:37 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnmvk10454 for ; Wed, 30 Oct 2002 17:07:26 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmvk22559 for ; Wed, 30 Oct 2002 17:07:26 GMT Received: from zcars04e.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQnmvk22549 for ; Wed, 30 Oct 2002 17:07:25 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9UH7EE19648 for ; Wed, 30 Oct 2002 12:07:14 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Oct 2002 12:07:15 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C05CF751A@zcard031.ca.nortel.com> From: "David Allan" To: mpls@UU.NET Subject: draft-allan-mpls-oam-frmwk-03 Date: Wed, 30 Oct 2002 12:07:14 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk FYI, I've reposted a revised version of the OAM framework draft (03). http://www.ietf.org/internet-drafts/draft-allan-mpls-oam-frmwk-03.txt For the time impaired, the changes are: - Addition of section on OAM state association. - Addition of section on the use of hierarchy to simplify OAM. - Enhanced security section. - Minor editorial changes. The document is pretty much as complete an exploration of the problem space as the authors can make it. At this point I'd like to suggest the WG consider making this draft as a WG document. comments? Dave From owner-mpls@UU.NET Wed Oct 30 14:35:51 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06175 for ; Wed, 30 Oct 2002 14:35:51 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmvu22086 for ; Wed, 30 Oct 2002 19:38:11 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnmvu20772; Wed, 30 Oct 2002 19:37:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQnmvu00551 for mpls-outgoing; Wed, 30 Oct 2002 19:37:01 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnmvu00546 for ; Wed, 30 Oct 2002 19:36:47 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnmvu09991 for ; Wed, 30 Oct 2002 19:35:35 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmvu22812 for ; Wed, 30 Oct 2002 19:35:35 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnmvu22806 for ; Wed, 30 Oct 2002 19:35:34 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA22718 for ; Wed, 30 Oct 2002 14:35:34 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9UJZYA26219 for mpls@uu.net; Wed, 30 Oct 2002 14:35:34 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnmvt00050 for ; Wed, 30 Oct 2002 19:28:10 GMT Received: from imr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmvt26263 for ; Wed, 30 Oct 2002 19:26:12 GMT Received: from dgismtp02.wcomnet.com by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dgismtp02.wcomnet.com [166.38.58.142]) id QQnmvt26172; Wed, 30 Oct 2002 19:26:11 GMT Received: from CONVERSION-DAEMON.dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) id <0H4T0070178PBN@dgismtp02.wcomnet.com>; Wed, 30 Oct 2002 19:26:10 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H4T007017AKGV@dgismtp02.wcomnet.com>; Wed, 30 Oct 2002 19:26:05 +0000 (GMT) Received: from ashsysenglt222 ([153.39.147.238]) by dgismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H4T004KK7AQXN@dgismtp02.wcomnet.com>; Wed, 30 Oct 2002 19:25:38 +0000 (GMT) Date: Wed, 30 Oct 2002 14:25:50 -0500 From: Amir Birjandi Subject: Decreasing TE-LSP bandwidth, "interoperability issue" X-Sender: Mohammad.Birjandi@pop.wcomnet.com To: mpls@UU.NET Cc: najam.ahmad@wcom.com, juzer.kopti@wcom.com, plahiri@UU.NET, blaine.christian@wcom.com Message-id: <3.0.32.20021030142549.027cb8b0@pop.wcomnet.com> MIME-version: 1.0 X-Mailer: Windows Eudora Pro Version 3.0 (32) Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, There are straight guide lines for increasing TE-LSP bandwidth in rfc-3209, however there are ambiguities in rfc3209 and rfc2205 for decreasing the TE-LSP bandwidth. It seems vendors can follow the spc if they change the LSP-ID or not change the LSP-ID, after the LSP bandwidth has been decreased. This ambiguity may causes some intereoperabilty issues. Perhaps verdors or authors "3209 or 2205 "should address this issue so every one comply to the same standard. Thanks A. From owner-mpls@UU.NET Wed Oct 30 18:45:10 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19061 for ; Wed, 30 Oct 2002 18:45:09 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmwl20534 for ; Wed, 30 Oct 2002 23:47:30 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnmwl19828; Wed, 30 Oct 2002 23:47:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQnmwl27550 for mpls-outgoing; Wed, 30 Oct 2002 23:46:44 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnmwl27533 for ; Wed, 30 Oct 2002 23:46:35 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnmwk25190 for ; Wed, 30 Oct 2002 23:44:52 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmwk16312 for ; Wed, 30 Oct 2002 23:44:51 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f78.sea2.hotmail.com [207.68.165.78]) id QQnmwk16308 for ; Wed, 30 Oct 2002 23:44:51 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 30 Oct 2002 15:44:50 -0800 Received: from 63.104.212.252 by sea2fd.sea2.hotmail.msn.com with HTTP; Wed, 30 Oct 2002 23:44:50 GMT X-Originating-IP: [63.104.212.252] From: "Sandeep B" To: mpls@UU.NET Subject: question on backup facility Date: Wed, 30 Oct 2002 23:44:50 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Oct 2002 23:44:50.0968 (UTC) FILETIME=[56BB7980:01C2806E] Sender: owner-mpls@UU.NET Precedence: bulk As per my understanding for backup path to work with global label space is to keep all path states intact on a downstream node (MP) when an intermediate link fails (between PLR and MP) With most of the implementations I see today all path states are removed once a upstream link failure is detected on a router and PATHTEAR is send downstream. So my statement would be correct that "only way for backup facility to work is to replace all nodes in the network". With even one intermediate node behaving to not keep its PSB states on upstream node/link failure would bring down the Lsp and potentially creating a black-hole for a while (as PLR would think that backup facility is still in use even though MP has removed its path/resv state on getting a PATHTEAR from NHOP with respect to PLR) Comments?? -Sandeep 4.5.1. Path state Path state for every locally repaired LSPs is refreshed downstream by the PLR. These Path messages use a new SENDER_TEMPLATE value (the IPv4 tunnel sender address is set to a PLR address), and are sent onto the bypass tunnel with changed PHOP, ERO and RRO. When a local link fails, there could be some protected LSPs using this link. >>>At this point, the LSR MUST NOT remove the state (Path and Resv) and send PathTear and ResvErr messages that are corresponding to these LSPs immediately. _________________________________________________________________ Unlimited Internet access -- and 2 months free!  Try MSN. http://resourcecenter.msn.com/access/plans/2monthsfree.asp From owner-mpls@UU.NET Wed Oct 30 21:08:30 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22298 for ; Wed, 30 Oct 2002 21:08:30 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmwu02854 for ; Thu, 31 Oct 2002 02:10:50 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnmwu01110; Thu, 31 Oct 2002 02:09:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQnmwu27603 for mpls-outgoing; Thu, 31 Oct 2002 02:09:23 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnmwu27598 for ; Thu, 31 Oct 2002 02:09:08 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnmwu11486 for ; Thu, 31 Oct 2002 02:08:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmwu22218 for ; Thu, 31 Oct 2002 02:08:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnmwu22210 for ; Thu, 31 Oct 2002 02:08:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA21352 for ; Wed, 30 Oct 2002 21:08:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9V282i17073 for mpls@uu.net; Wed, 30 Oct 2002 21:08:02 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnmwu27290 for ; Thu, 31 Oct 2002 02:06:51 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnmwu22875; Thu, 31 Oct 2002 02:06:41 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmwu21285; Thu, 31 Oct 2002 02:06:41 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: europe.cisco.com [144.254.52.73]) id QQnmwu21281; Thu, 31 Oct 2002 02:06:40 GMT Received: from JVASSEUR-W2K.cisco.com (rtp-vpn2-942.cisco.com [10.82.243.174]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id DAA25102; Thu, 31 Oct 2002 03:06:36 +0100 (MET) Message-Id: <4.3.2.7.2.20021030210555.08c11ec0@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 30 Oct 2002 21:06:34 -0400 To: Amir Birjandi From: Jean Philippe Vasseur Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" Cc: mpls@UU.NET, najam.ahmad@wcom.com, juzer.kopti@wcom.com, plahiri@UU.NET, blaine.christian@wcom.com In-Reply-To: <3.0.32.20021030142549.027cb8b0@pop.wcomnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi Amir, You're correct, there is an ambiguity in the RFCs that we need to address. This can clearly cause some interoperability issues. The simplest and more logical approach here is to proceed the same way whether the bandwidth is being increased or decreased, just increment the LSP-ID. Any other vendor opinion ? Thanks. JP. At 14:25 30/10/2002 -0500, Amir Birjandi wrote: >Hi, > >There are straight guide lines for increasing TE-LSP bandwidth in rfc-3209, >however there are ambiguities in rfc3209 and rfc2205 for decreasing the >TE-LSP bandwidth. > >It seems vendors can follow the spc if they change the LSP-ID or not change >the LSP-ID, after the LSP bandwidth has been decreased. > >This ambiguity may causes some intereoperabilty issues. > >Perhaps verdors or authors "3209 or 2205 "should address this issue so >every one comply to the same standard. > >Thanks > >A. From owner-mpls@UU.NET Wed Oct 30 21:18:11 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22504 for ; Wed, 30 Oct 2002 21:18:11 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmwv16055 for ; Thu, 31 Oct 2002 02:20:35 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnmwv14983; Thu, 31 Oct 2002 02:20:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQnmwv29351 for mpls-outgoing; Thu, 31 Oct 2002 02:19:57 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnmwv29346 for ; Thu, 31 Oct 2002 02:19:49 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnmwv02958 for ; Thu, 31 Oct 2002 02:19:05 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmwv00926 for ; Thu, 31 Oct 2002 02:19:05 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnmwv00919 for ; Thu, 31 Oct 2002 02:19:04 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA21852 for ; Wed, 30 Oct 2002 21:19:04 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9V2J4b18413 for mpls@uu.net; Wed, 30 Oct 2002 21:19:04 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnmwv29286 for ; Thu, 31 Oct 2002 02:17:44 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnmwv19257 for ; Thu, 31 Oct 2002 02:16:49 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmwv29422 for ; Thu, 31 Oct 2002 02:16:48 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: europe.cisco.com [144.254.52.73]) id QQnmwv29418 for ; Thu, 31 Oct 2002 02:16:48 GMT Received: from JVASSEUR-W2K.cisco.com (rtp-vpn2-942.cisco.com [10.82.243.174]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id DAA25581; Thu, 31 Oct 2002 03:16:45 +0100 (MET) Message-Id: <4.3.2.7.2.20021030210918.0829faf0@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 30 Oct 2002 21:16:43 -0400 To: "Sandeep B" From: Jean Philippe Vasseur Subject: Re: question on backup facility Cc: mpls@UU.NET In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_827584834==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_827584834==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Sanddep, At 23:44 30/10/2002 +0000, Sandeep B wrote: >As per my understanding for backup path to work with global label space is >to keep all path states intact on a downstream node (MP) when an >intermediate link fails (between PLR and MP) > >With most of the implementations I see today all path states are removed >once a upstream link failure is detected on a router and PATHTEAR is >send downstream. > >So my statement would be correct that "only way for backup facility to >work is to replace all nodes in the network". With even one intermediate >node behaving to not keep its PSB states on upstream node/link failure >would bring down the Lsp and potentially creating a black-hole for a while >(as PLR would think that backup facility is still in use even though MP >has removed its path/resv state on getting a PATHTEAR from NHOP with >respect to PLR) This case is covered in the draft already: When a downstream LSR detects a local link failure, for any protected LSPs routed over the failed link, Path and Resv state MUST NOT be cleared and PathTear and ResvErr messages MUST NOT be sent immediately. Further a downstream LSR SHOULD reset the refresh timers for these LSPs as if they had just been refreshed. This is to allow time for the PLR to begin refreshing state via the bypass tunnel. State MUST be removed if it has not been refreshed before the refresh timer expires. JP. >Comments?? > >-Sandeep > > >4.5.1. Path state > > Path state for every locally repaired LSPs is refreshed downstream by > the PLR. These Path messages use a new SENDER_TEMPLATE value (the > IPv4 tunnel sender address is set to a PLR address), and are sent > onto the bypass tunnel with changed PHOP, ERO and RRO. > > When a local link fails, there could be some protected LSPs using > this link. >>>>At this point, the LSR MUST NOT remove the state (Path > and Resv) and send PathTear and ResvErr messages that are > corresponding to these LSPs immediately. > > > > > >_________________________________________________________________ >Unlimited Internet access -- and 2 months free! Try MSN. >http://resourcecenter.msn.com/access/plans/2monthsfree.asp --=====================_827584834==_.ALT Content-Type: text/html; charset="us-ascii" Hi Sanddep,

At 23:44 30/10/2002 +0000, Sandeep B wrote:
As per my understanding for backup path to work with global label space is to keep all path states intact on a downstream node (MP) when an intermediate link fails (between PLR and MP)

With most of the implementations I see today all path states are removed
once a upstream link failure is detected on a router and PATHTEAR is
send downstream.

So my statement would be correct that "only way for backup facility to work is to replace all nodes in the network". With even one intermediate node behaving to not keep its PSB states on upstream node/link failure would bring down the Lsp and potentially creating a black-hole for a while (as PLR would think that backup facility is still in use even though MP has removed its path/resv state on getting a PATHTEAR from NHOP with respect to PLR)

This case is covered in the draft already:

When a downstream LSR detects a local link failure, for any protected
LSPs routed over the failed link, Path and Resv state MUST NOT be
cleared and PathTear and ResvErr messages MUST NOT be sent
immediately. Further a downstream LSR SHOULD reset the refresh
timers for these LSPs as if they had just been refreshed. This is to
allow time for the PLR to begin refreshing state via the bypass
tunnel. State MUST be removed if it has not been refreshed before
the refresh timer expires.

JP.

Comments??

-Sandeep


4.5.1. Path state

  Path state for every locally repaired LSPs is refreshed downstream by
  the PLR. These Path messages use a new SENDER_TEMPLATE value (the
  IPv4 tunnel sender address is set to a PLR address), and are sent
  onto the bypass tunnel with changed PHOP, ERO and RRO.

  When a local link fails, there could be some protected LSPs using
  this link.
At this point, the LSR MUST NOT remove the state (Path
  and Resv) and send PathTear and ResvErr messages that are
  corresponding to these LSPs immediately.





_________________________________________________________________
Unlimited Internet access -- and 2 months free!  Try MSN. http://resourcecenter.msn.com/access/plans/2monthsfree.asp
--=====================_827584834==_.ALT-- From owner-mpls@UU.NET Wed Oct 30 22:01:17 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23826 for ; Wed, 30 Oct 2002 22:01:16 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmwy28758 for ; Thu, 31 Oct 2002 03:03:37 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnmwy27547; Thu, 31 Oct 2002 03:03:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQnmwy15352 for mpls-outgoing; Thu, 31 Oct 2002 03:02:36 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnmwy13426 for ; Thu, 31 Oct 2002 03:02:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnmwy24716 for ; Thu, 31 Oct 2002 03:01:57 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmwy24563 for ; Thu, 31 Oct 2002 03:01:57 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f73.sea2.hotmail.com [207.68.165.73]) id QQnmwy24554 for ; Thu, 31 Oct 2002 03:01:57 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 30 Oct 2002 19:01:56 -0800 Received: from 63.104.212.252 by sea2fd.sea2.hotmail.msn.com with HTTP; Thu, 31 Oct 2002 03:01:56 GMT X-Originating-IP: [63.104.212.252] From: "Sandeep B" To: jvasseur@cisco.com Cc: mpls@UU.NET Subject: Re: question on backup facility Date: Thu, 31 Oct 2002 03:01:56 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 31 Oct 2002 03:01:56.0671 (UTC) FILETIME=[DF668CF0:01C28089] Sender: owner-mpls@UU.NET Precedence: bulk I understand that part. But what I'm saying is if there is a node between PLR and MP that does not supports backup facility and is just acting as a regular LSR. Topology is like - ingres --- PLR --- node 1---- MP --- egress LSP is setup from ingress to egress via PLR--node1---MP. a backup is setup from PLR to MP via some other available route. MP is a node with global label space - so there is no need for PLR to send PATH message down the backup tunnel and MP has no idea that the main lsp is being protected by some incoming backup LSP. now link between PLR and node1 fails which triggers a PATHTEAR from node1 (as node1 does not understands backup facility). This PATHTEAR would wipe out protected LSP from MP as well as egress. With this assumption I say that for backup facility to work in a network is to have all nodes that would not delete local state on detecting incoming link failure (unlike as in this previous case where "node1" triggered a PATHTEAR) -Sandeep >Hi Sanddep, > >At 23:44 30/10/2002 +0000, Sandeep B wrote: >>As per my understanding for backup path to work with global label space is >>to keep all path states intact on a downstream node (MP) when an >>intermediate link fails (between PLR and MP) >> >>With most of the implementations I see today all path states are removed >>once a upstream link failure is detected on a router and PATHTEAR is >>send downstream. >> >>So my statement would be correct that "only way for backup facility to >>work is to replace all nodes in the network". With even one intermediate >>node behaving to not keep its PSB states on upstream node/link failure >>would bring down the Lsp and potentially creating a black-hole for a while >>(as PLR would think that backup facility is still in use even though MP >>has removed its path/resv state on getting a PATHTEAR from NHOP with >>respect to PLR) > >This case is covered in the draft already: > >When a downstream LSR detects a local link failure, for any protected >LSPs routed over the failed link, Path and Resv state MUST NOT be >cleared and PathTear and ResvErr messages MUST NOT be sent >immediately. Further a downstream LSR SHOULD reset the refresh >timers for these LSPs as if they had just been refreshed. This is to >allow time for the PLR to begin refreshing state via the bypass >tunnel. State MUST be removed if it has not been refreshed before >the refresh timer expires. > >JP. > >>Comments?? >> >>-Sandeep >> >> >>4.5.1. Path state >> >> Path state for every locally repaired LSPs is refreshed downstream by >> the PLR. These Path messages use a new SENDER_TEMPLATE value (the >> IPv4 tunnel sender address is set to a PLR address), and are sent >> onto the bypass tunnel with changed PHOP, ERO and RRO. >> >> When a local link fails, there could be some protected LSPs using >> this link. >>>>>At this point, the LSR MUST NOT remove the state (Path >> and Resv) and send PathTear and ResvErr messages that are >> corresponding to these LSPs immediately. >> >> >> >> >> >>_________________________________________________________________ >>Unlimited Internet access -- and 2 months free! Try MSN. >>http://resourcecenter.msn.com/access/plans/2monthsfree.asp _________________________________________________________________ Surf the Web without missing calls! Get MSN Broadband. http://resourcecenter.msn.com/access/plans/freeactivation.asp From owner-mpls@UU.NET Thu Oct 31 09:39:28 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21513 for ; Thu, 31 Oct 2002 09:39:27 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmys20939 for ; Thu, 31 Oct 2002 14:41:49 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnmys20117; Thu, 31 Oct 2002 14:41:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQnmys14012 for mpls-outgoing; Thu, 31 Oct 2002 14:40:58 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnmys14005 for ; Thu, 31 Oct 2002 14:40:45 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnmys02173; Thu, 31 Oct 2002 14:40:02 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmys07173; Thu, 31 Oct 2002 14:40:02 GMT Received: from mlsrv1.avici.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host128.avici.com [208.246.215.128]) id QQnmys07146; Thu, 31 Oct 2002 14:40:01 GMT Received: from avici.com (swdev105.avici.com [10.2.21.105]) by mlsrv1.avici.com (8.11.0/8.11.0) with ESMTP id g9VEdcV28220; Thu, 31 Oct 2002 09:39:38 -0500 (EST) Message-Id: <200210311439.g9VEdcV28220@mlsrv1.avici.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Markus Jork To: Jean Philippe Vasseur cc: Amir Birjandi , mpls@UU.NET, najam.ahmad@wcom.com, juzer.kopti@wcom.com, plahiri@UU.NET, blaine.christian@wcom.com Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" In-reply-to: Your message of "Wed, 30 Oct 2002 21:06:34 -0400." <4.3.2.7.2.20021030210555.08c11ec0@paris.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 31 Oct 2002 09:39:37 -0500 Sender: owner-mpls@UU.NET Precedence: bulk Well, in theory this shouldn't cause any interop problems because no matter what approach it has chosen itself, an implementation has to be prepared to deal with a bandwidth decrease via a simple change in the tspec or via a reroute (new LSP-ID). In practice, it apparently has caused interop problems... I'm only familiar with three implementations, two of them use the reroute method and one just changes the tspec. Because reroute is the safer method that is guaranteed to work, I'm with JP here and would suggest that the LSP-ID should always be incremented for any bandwidth change (whether increase or decrease). Markus > Hi Amir, > > You're correct, there is an ambiguity in the RFCs that we need to address. > This can clearly cause some interoperability issues. The simplest and more > logical approach here is to proceed the same way whether the bandwidth is > being increased or decreased, just increment the LSP-ID. > > Any other vendor opinion ? > > Thanks. > > JP. > > At 14:25 30/10/2002 -0500, Amir Birjandi wrote: > > >Hi, > > > >There are straight guide lines for increasing TE-LSP bandwidth in rfc-3209, > >however there are ambiguities in rfc3209 and rfc2205 for decreasing the > >TE-LSP bandwidth. > > > >It seems vendors can follow the spc if they change the LSP-ID or not change > >the LSP-ID, after the LSP bandwidth has been decreased. > > > >This ambiguity may causes some intereoperabilty issues. > > > >Perhaps verdors or authors "3209 or 2205 "should address this issue so > >every one comply to the same standard. > > > >Thanks > > > >A. > > From owner-mpls@UU.NET Thu Oct 31 11:54:20 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00806 for ; Thu, 31 Oct 2002 11:54:19 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmzb07064 for ; Thu, 31 Oct 2002 16:56:38 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnmzb05971; Thu, 31 Oct 2002 16:56:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQnmzb28222 for mpls-outgoing; Thu, 31 Oct 2002 16:55:36 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnmzb28217 for ; Thu, 31 Oct 2002 16:55:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnmzb16521 for ; Thu, 31 Oct 2002 16:55:04 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmzb14914 for ; Thu, 31 Oct 2002 16:55:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnmzb14905 for ; Thu, 31 Oct 2002 16:55:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA10078 for ; Thu, 31 Oct 2002 11:55:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9VGt2300459 for mpls@uu.net; Thu, 31 Oct 2002 11:55:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnmzb28124 for ; Thu, 31 Oct 2002 16:54:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnmzb28265; Thu, 31 Oct 2002 16:53:05 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmzb13511; Thu, 31 Oct 2002 16:53:05 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnmzb13493; Thu, 31 Oct 2002 16:53:04 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA69530; Thu, 31 Oct 2002 11:52:06 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200210311652.LAA69530@workhorse.fictitious.org> To: Amir Birjandi cc: mpls@UU.NET, najam.ahmad@wcom.com, juzer.kopti@wcom.com, plahiri@UU.NET, blaine.christian@wcom.com Reply-To: curtis@fictitious.org Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" In-reply-to: Your message of "Wed, 30 Oct 2002 14:25:50 EST." <3.0.32.20021030142549.027cb8b0@pop.wcomnet.com> Date: Thu, 31 Oct 2002 11:52:06 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3.0.32.20021030142549.027cb8b0@pop.wcomnet.com>, Amir Birjandi writ es: > > Hi, > > There are straight guide lines for increasing TE-LSP bandwidth in rfc-3209, > however there are ambiguities in rfc3209 and rfc2205 for decreasing the > TE-LSP bandwidth. > > It seems vendors can follow the spc if they change the LSP-ID or not change > the LSP-ID, after the LSP bandwidth has been decreased. > > This ambiguity may causes some intereoperabilty issues. > > Perhaps verdors or authors "3209 or 2205 "should address this issue so > every one comply to the same standard. > > Thanks > > A. Amir, As Markus pointed out, this is yet another case where it is wise for the implementor to "be conservative in what you send and liberal in what you accept". This has always been good advice to an implementor. As an ingress anytime anything changes, priority, bandwidth, color restrictions (if signaled), request for FRR, do a make-before-break reroute. Don't try to send a modified PATH message. It is important that an implementation not just change the LSP-id but also keep the SESSION object unchanged so that make-before-break reservation sharing works (as specified in rfc3209, section 2.5). As a midpoint be prepared for anything to change in the PATH message. Be prepared for priority to change or bandwidth to change. Be prepared for color restrictions to change. Be prepared for FRR to be added, dropped, or modified. Also be prepared to "share" bandwidth among more than two LSPs and for the possibility for those LSPs to have different priorities (otherwise how do you make-before-break reroute on a change in priority). Be sure to "get it right" when making a change or combining shared bandwidths on the CAC decision and in the bandwidth accounting (the remaining reservable bandwidth amounts that get reflooded). There is existance proof that this can be accomplished, yielding interoperabilty with two major MPLS implementation that do this differently. Of course, you are not an implementor and find yourself with one router that has not been sufficiently conservation in what it sends and another which has not been sufficiently liberal in what it accepts. The remaining question is if a spec is changed should changing the tspec bandwidth in PATH messages for MPLS/TE be explicitly allowed or explicitly disallowed. Or both, require that it not be sent by the ingress and require that it be accepted by the midpoint so in the future we still cover older or slightly buggy implementations. I prefer make-before-break reroute and therefore favor explicitly disallowing the tspec change (but our implementation is OK either way). I think the change should go in a future iteration of rfc3209. Curtis From owner-mpls@UU.NET Thu Oct 31 13:59:41 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08262 for ; Thu, 31 Oct 2002 13:59:41 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmzk02058 for ; Thu, 31 Oct 2002 19:02:03 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnmzk00972; Thu, 31 Oct 2002 19:01:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQnmzk16952 for mpls-outgoing; Thu, 31 Oct 2002 19:01:21 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnmzk16695 for ; Thu, 31 Oct 2002 19:01:06 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnmzk06009; Thu, 31 Oct 2002 19:00:32 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmzk21265; Thu, 31 Oct 2002 19:00:32 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQnmzk21254; Thu, 31 Oct 2002 19:00:31 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT02BM>; Thu, 31 Oct 2002 14:00:31 -0500 Message-ID: <1117F7D44159934FB116E36F4ABF221B0267EC45@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'curtis@fictitious.org'" Cc: mpls@UU.NET, najam.ahmad@wcom.com, juzer.kopti@wcom.com, plahiri@UU.NET, blaine.christian@wcom.com, Amir Birjandi Subject: RE: Decreasing TE-LSP bandwidth, "interoperability issue" Date: Thu, 31 Oct 2002 14:00:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Curtis, I don't disagree with your points with one caveat: if a new specification requires implementations to support multiple approaches for interoperability with existing implementations, it will effectively encourage multiple approaches in all future implementations. I assume you would not argue that the specification should require implementations to discriminate between existing and new implementations by requiring newer implementations to support fewer options. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > Sent: Thursday, October 31, 2002 11:52 AM > To: Amir Birjandi > Cc: mpls@UU.NET; najam.ahmad@wcom.com; juzer.kopti@wcom.com; > plahiri@UU.NET; blaine.christian@wcom.com > Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" > > > In message <3.0.32.20021030142549.027cb8b0@pop.wcomnet.com>, Amir Birjandi > writ > es: > > > > Hi, > > > > There are straight guide lines for increasing TE-LSP bandwidth in rfc- > 3209, > > however there are ambiguities in rfc3209 and rfc2205 for decreasing the > > TE-LSP bandwidth. > > > > It seems vendors can follow the spc if they change the LSP-ID or not > change > > the LSP-ID, after the LSP bandwidth has been decreased. > > > > This ambiguity may causes some intereoperabilty issues. > > > > Perhaps verdors or authors "3209 or 2205 "should address this issue so > > every one comply to the same standard. > > > > Thanks > > > > A. > > > > Amir, > > As Markus pointed out, this is yet another case where it is wise for > the implementor to "be conservative in what you send and liberal in > what you accept". This has always been good advice to an implementor. > > As an ingress anytime anything changes, priority, bandwidth, color > restrictions (if signaled), request for FRR, do a make-before-break > reroute. Don't try to send a modified PATH message. It is important > that an implementation not just change the LSP-id but also keep the > SESSION object unchanged so that make-before-break reservation sharing > works (as specified in rfc3209, section 2.5). > > As a midpoint be prepared for anything to change in the PATH message. > Be prepared for priority to change or bandwidth to change. Be > prepared for color restrictions to change. Be prepared for FRR to be > added, dropped, or modified. Also be prepared to "share" bandwidth > among more than two LSPs and for the possibility for those LSPs to > have different priorities (otherwise how do you make-before-break > reroute on a change in priority). Be sure to "get it right" when > making a change or combining shared bandwidths on the CAC decision and > in the bandwidth accounting (the remaining reservable bandwidth > amounts that get reflooded). > > There is existance proof that this can be accomplished, yielding > interoperabilty with two major MPLS implementation that do this > differently. > > Of course, you are not an implementor and find yourself with one > router that has not been sufficiently conservation in what it sends > and another which has not been sufficiently liberal in what it > accepts. > > The remaining question is if a spec is changed should changing the > tspec bandwidth in PATH messages for MPLS/TE be explicitly allowed or > explicitly disallowed. Or both, require that it not be sent by the > ingress and require that it be accepted by the midpoint so in the > future we still cover older or slightly buggy implementations. > > I prefer make-before-break reroute and therefore favor explicitly > disallowing the tspec change (but our implementation is OK either way). > I think the change should go in a future iteration of rfc3209. > > Curtis From owner-mpls@UU.NET Thu Oct 31 14:32:17 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11100 for ; Thu, 31 Oct 2002 14:32:16 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmzm01801 for ; Thu, 31 Oct 2002 19:34:37 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnmzm00386; Thu, 31 Oct 2002 19:33:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQnmzm01389 for mpls-outgoing; Thu, 31 Oct 2002 19:33:40 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnmzm01384 for ; Thu, 31 Oct 2002 19:33:33 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnmzm27742 for ; Thu, 31 Oct 2002 19:32:04 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmzm28190 for ; Thu, 31 Oct 2002 19:32:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnmzm28165 for ; Thu, 31 Oct 2002 19:32:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA25118 for ; Thu, 31 Oct 2002 14:32:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9VJW2E09043 for mpls@uu.net; Thu, 31 Oct 2002 14:32:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnmzm01115 for ; Thu, 31 Oct 2002 19:30:45 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnmzl19707; Thu, 31 Oct 2002 19:28:52 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmzl24630; Thu, 31 Oct 2002 19:28:52 GMT Received: from fido.nc.rr.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rdu57-1-013.nc.rr.com [66.57.1.13]) id QQnmzl24625; Thu, 31 Oct 2002 19:28:52 GMT Received: from localhost (jboyle@localhost) by fido.nc.rr.com (8.11.2/8.11.2) with ESMTP id g9VJ1lk32035; Thu, 31 Oct 2002 14:01:47 -0500 X-Authentication-Warning: fido.nc.rr.com: jboyle owned process doing -bs Date: Thu, 31 Oct 2002 14:01:47 -0500 (EST) From: Jim Boyle X-X-Sender: To: Markus Jork cc: Jean Philippe Vasseur , Amir Birjandi , , , , , Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" In-Reply-To: <200210311439.g9VEdcV28220@mlsrv1.avici.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk This issue was also discussed back in May See: "RSVP-TE : bandwidth decrease" there I think David Pointed out that there are obviously good reasons to change the LSP ID for bandwidth increases and route changes for make-before-break (you might lose your reservation). When you decrease the bandwidth, I don't see how you are in danger of losing your reservation, perhaps that's why the RFC3209 has a section titled: "4.6.4. Reroute and Bandwidth Increase Procedure" but says nothing on bandwidth decrease procedure. I guess I would agree somewhat with what's already been said. You should be conservative in what you send (e.g. the spec doesn't say to change the LSP ID for decreases, some versions of conservative might differ) and liberal in what you process (e.g., don't expect LSP ID changes to trigger you to see if bandwidth might have changed, and for increases and changes in ERO don't expect the LSP ID to increment by one (though that's common, it's only specified that a new LSP ID is assigned)). If an implementations failed to update the tspec propogated when the tspec is decreased and the LSP ID is not changed, there are obvious situations where this could cause a problem. Curtis implied in his last paragraph that you needed to change LSP ID in order to have make-before-break on bandwidth decreases. However, if one only decreased the bandwidth, there is no worry about losing one's reservation so there is no time the LSP would be "broke" (e.g. packets continue to flow the whole time). The only thing adding a new path with a different LSP ID would do is add more path state for a period of time, and likely change the label associated with the session. So what's the consensus here? Be ready for BW decreases with and without LSP ID to changes? regards, Jim Boyle (disclaimer: day job = juniper) From owner-mpls@UU.NET Thu Oct 31 15:02:32 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12260 for ; Thu, 31 Oct 2002 15:02:32 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmzo21864 for ; Thu, 31 Oct 2002 20:04:52 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnmzo20289; Thu, 31 Oct 2002 20:04:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQnmzo18366 for mpls-outgoing; Thu, 31 Oct 2002 20:03:55 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnmzo18279 for ; Thu, 31 Oct 2002 20:03:53 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnmzo05277; Thu, 31 Oct 2002 20:03:24 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmzo11937; Thu, 31 Oct 2002 20:03:24 GMT Received: from prattle.redback.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: prattle.redback.com [155.53.12.9]) id QQnmzo11907; Thu, 31 Oct 2002 20:03:23 GMT Received: from malt.redback.com (malt.redback.com [155.53.12.41]) by prattle.redback.com (Postfix) with ESMTP id 15959151A9A; Thu, 31 Oct 2002 12:02:15 -0800 (PST) Received: (from rahul@localhost) by malt.redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) id LAA23032; Thu, 31 Oct 2002 11:50:38 -0800 (PST) Date: Thu, 31 Oct 2002 11:50:34 -0800 From: Rahul Aggarwal To: Jim Boyle Cc: Markus Jork , Jean Philippe Vasseur , Amir Birjandi , mpls@UU.NET, najam.ahmad@wcom.com, juzer.kopti@wcom.com, plahiri@UU.NET, blaine.christian@wcom.com Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" Message-ID: <20021031195034.GF22537@malt.redback.com> References: <200210311439.g9VEdcV28220@mlsrv1.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-mpls@UU.NET Precedence: bulk Hi Jim, A comment inline : On Thu, Oct 31, 2002 at 02:01:47PM -0500, Jim Boyle wrote: > > This issue was also discussed back in May > > See: "RSVP-TE : bandwidth decrease" > > there I think David Pointed out that there are obviously good reasons to > change the LSP ID for bandwidth increases and route changes for > make-before-break (you might lose your reservation). > > When you decrease the bandwidth, I don't see how you are in danger of > losing your reservation, perhaps that's why the RFC3209 has a section > titled: > > "4.6.4. Reroute and Bandwidth Increase Procedure" > > but says nothing on bandwidth decrease procedure. > > I guess I would agree somewhat with what's already been said. > > You should be conservative in what you send (e.g. the spec doesn't say to > change the LSP ID for decreases, some versions of conservative might > differ) and liberal in what you process (e.g., don't expect LSP ID changes > to trigger you to see if bandwidth might have changed, and for increases > and changes in ERO don't expect the LSP ID to increment by one (though > that's common, it's only specified that a new LSP ID is assigned)). If an > implementations failed to update the tspec propogated when the tspec is > decreased and the LSP ID is not changed, there are obvious situations > where this could cause a problem. > > Curtis implied in his last paragraph that you needed to change LSP ID in > order to have make-before-break on bandwidth decreases. However, if one > only decreased the bandwidth, there is no worry about losing one's > reservation so there is no time the LSP would be "broke" (e.g. packets > continue to flow the whole time). The only thing adding a new path with a > different LSP ID would do is add more path state for a period of time, and > likely change the label associated with the session. > > So what's the consensus here? > > Be ready for BW decreases with and without LSP ID to changes? IMHO that sounds like the best approach. In our implementation this is exactly how its handled. A tspec change is propagated when the tpsec is decreased irrespective of a change in the LSP ID. As you pointed out for a bandwidth decrease this has advantages as there no additional path state introduced. rahul > > regards, > > Jim Boyle > > (disclaimer: day job = juniper) > > > From owner-mpls@UU.NET Thu Oct 31 15:21:15 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12946 for ; Thu, 31 Oct 2002 15:21:15 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmzp03541 for ; Thu, 31 Oct 2002 20:23:37 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnmzp02297; Thu, 31 Oct 2002 20:23:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQnmzp22107 for mpls-outgoing; Thu, 31 Oct 2002 20:22:35 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnmzp22087 for ; Thu, 31 Oct 2002 20:22:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnmzp18999; Thu, 31 Oct 2002 20:21:51 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmzp24651; Thu, 31 Oct 2002 20:21:51 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQnmzp24642; Thu, 31 Oct 2002 20:21:51 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT02RC>; Thu, 31 Oct 2002 15:21:48 -0500 Message-ID: <1117F7D44159934FB116E36F4ABF221B0267EC46@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'Jim Boyle'" , Markus Jork Cc: Jean Philippe Vasseur , Amir Birjandi , mpls@UU.NET, najam.ahmad@wcom.com, juzer.kopti@wcom.com, plahiri@UU.NET, blaine.christian@wcom.com Subject: RE: Decreasing TE-LSP bandwidth, "interoperability issue" Date: Thu, 31 Oct 2002 15:21:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Jim, With respect to your comment on make before break (and not referencing any particular implementation), it can be the case that packets might be lost in reducing bandwidth associated with a queue in an implementation - if a new queue is not temporarily created. This could occur, for example, as a result relinquishing buffer resources previously allocated to a "deeper" queue now being associated with "shallower" queuing resources. I have not seen such an implementation recently, but it is distinctly possible that some implementations do not handle reduction of queuing resources for an existing queue gracefully. Such an implementation would not necessarily be "broken", if it were not designed with the intention of supporting resource reduction for an active queue. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 > -----Original Message----- > From: Jim Boyle [mailto:jboyle@pdnets.com] > Sent: Thursday, October 31, 2002 2:02 PM > To: Markus Jork > Cc: Jean Philippe Vasseur; Amir Birjandi; mpls@UU.NET; > najam.ahmad@wcom.com; juzer.kopti@wcom.com; plahiri@UU.NET; > blaine.christian@wcom.com > Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" > > > This issue was also discussed back in May > > See: "RSVP-TE : bandwidth decrease" > > there I think David Pointed out that there are obviously good reasons to > change the LSP ID for bandwidth increases and route changes for > make-before-break (you might lose your reservation). > > When you decrease the bandwidth, I don't see how you are in danger of > losing your reservation, perhaps that's why the RFC3209 has a section > titled: > > "4.6.4. Reroute and Bandwidth Increase Procedure" > > but says nothing on bandwidth decrease procedure. > > I guess I would agree somewhat with what's already been said. > > You should be conservative in what you send (e.g. the spec doesn't say to > change the LSP ID for decreases, some versions of conservative might > differ) and liberal in what you process (e.g., don't expect LSP ID changes > to trigger you to see if bandwidth might have changed, and for increases > and changes in ERO don't expect the LSP ID to increment by one (though > that's common, it's only specified that a new LSP ID is assigned)). If an > implementations failed to update the tspec propogated when the tspec is > decreased and the LSP ID is not changed, there are obvious situations > where this could cause a problem. > > Curtis implied in his last paragraph that you needed to change LSP ID in > order to have make-before-break on bandwidth decreases. However, if one > only decreased the bandwidth, there is no worry about losing one's > reservation so there is no time the LSP would be "broke" (e.g. packets > continue to flow the whole time). The only thing adding a new path with a > different LSP ID would do is add more path state for a period of time, and > likely change the label associated with the session. > > So what's the consensus here? > > Be ready for BW decreases with and without LSP ID to changes? > > regards, > > Jim Boyle > > (disclaimer: day job = juniper) > From owner-mpls@UU.NET Thu Oct 31 16:12:18 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15219 for ; Thu, 31 Oct 2002 16:12:17 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmzs27346 for ; Thu, 31 Oct 2002 21:14:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnmzs25672; Thu, 31 Oct 2002 21:13:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQnmzs12911 for mpls-outgoing; Thu, 31 Oct 2002 21:13:13 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnmzs12839 for ; Thu, 31 Oct 2002 21:13:04 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnmzs25720 for ; Thu, 31 Oct 2002 21:13:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmzs13858 for ; Thu, 31 Oct 2002 21:13:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnmzs13852 for ; Thu, 31 Oct 2002 21:13:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA04331 for ; Thu, 31 Oct 2002 16:13:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9VLD2M15696 for mpls@uu.net; Thu, 31 Oct 2002 16:13:02 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnmzs12164 for ; Thu, 31 Oct 2002 21:10:36 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnmzs25941 for ; Thu, 31 Oct 2002 21:08:20 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmzs10056 for ; Thu, 31 Oct 2002 21:08:19 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnmzs10049 for ; Thu, 31 Oct 2002 21:08:19 GMT Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA03920; Thu, 31 Oct 2002 16:08:19 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id QAA07578; Thu, 31 Oct 2002 16:08:18 -0500 (EST) Message-Id: <200210312108.QAA07578@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: "Gray, Eric" cc: mpls@UU.NET Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" In-reply-to: Your message of "Thu, 31 Oct 2002 14:00:30 EST." <1117F7D44159934FB116E36F4ABF221B0267EC45@celox-ma1-ems1.celoxnetworks.com> Date: Thu, 31 Oct 2002 16:08:18 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > I don't disagree with your points with one caveat: > if a new specification requires implementations to support > multiple approaches for interoperability with existing > implementations, it will effectively encourage multiple > approaches in all future implementations. I assume you > would not argue that the specification should require > implementations to discriminate between existing and new > implementations by requiring newer implementations to > support fewer options. As far as I know, all implementations deal with changing the LSP-ID at the midpoint. At the head-end all change the LSP-ID on increase. Some change the LSP-ID on decrease and some (one?) don't. If that one did then we'd all be in sync. ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu Oct 31 17:13:41 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17705 for ; Thu, 31 Oct 2002 17:13:40 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmzx24407 for ; Thu, 31 Oct 2002 22:16:00 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnmzx22955; Thu, 31 Oct 2002 22:15:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQnmzw04744 for mpls-outgoing; Thu, 31 Oct 2002 22:14:54 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnmzw04736 for ; Thu, 31 Oct 2002 22:14:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnmzw23609 for ; Thu, 31 Oct 2002 22:13:24 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmzw26867 for ; Thu, 31 Oct 2002 22:13:24 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnmzw26855 for ; Thu, 31 Oct 2002 22:13:24 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA09493 for ; Thu, 31 Oct 2002 17:13:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9VMD2420021 for mpls@uu.net; Thu, 31 Oct 2002 17:13:02 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnmzw04656 for ; Thu, 31 Oct 2002 22:11:59 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnmzw18344 for ; Thu, 31 Oct 2002 22:11:47 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmzw17935 for ; Thu, 31 Oct 2002 22:11:47 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnmzw17915 for ; Thu, 31 Oct 2002 22:11:46 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id RAA70583; Thu, 31 Oct 2002 17:09:24 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200210312209.RAA70583@workhorse.fictitious.org> To: George Swallow cc: "Gray, Eric" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" In-reply-to: Your message of "Thu, 31 Oct 2002 16:08:18 EST." <200210312108.QAA07578@bifocal.cisco.com> Date: Thu, 31 Oct 2002 17:09:24 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <200210312108.QAA07578@bifocal.cisco.com>, George Swallow writes: > > I don't disagree with your points with one caveat: > > if a new specification requires implementations to support > > multiple approaches for interoperability with existing > > implementations, it will effectively encourage multiple > > approaches in all future implementations. I assume you > > would not argue that the specification should require > > implementations to discriminate between existing and new > > implementations by requiring newer implementations to > > support fewer options. > > As far as I know, all implementations deal with changing the LSP-ID at > the midpoint. At the head-end all change the LSP-ID on increase. > Some change the LSP-ID on decrease and some (one?) don't. If that one > did then we'd all be in sync. > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 497-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 George, If all of the implementations handled a decrease in bandwidth without changing the LSP-ID we wouldn't be having this discussion. Otherwise we have no interoperability problems. We simply have some doing make-before-break reroute on bandwidth decrease, which works and has to be done for bandwidth increase, and some just sending a new PATH message with a changed tspec. If so, we can just drop the discussion. Using the make-before-break reroute will always work so we intend to continue to use it. I thought we were doing that since we had seen interoperability problems doing otherwise but I don't know how long ago that was. Just out of curriousity, do you also plan to change to numerically higher holding priority (same or lower bandwidth) via change to the PATH message, since CAC could not reject that either? We do make-before-break reroute as an ingress on that too but we rerun admission at midpoint and allow any acceptable change. Curtis From owner-mpls@UU.NET Thu Oct 31 18:30:51 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20161 for ; Thu, 31 Oct 2002 18:30:50 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnac10267 for ; Thu, 31 Oct 2002 23:33:08 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnac08002; Thu, 31 Oct 2002 23:31:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnac27741 for mpls-outgoing; Thu, 31 Oct 2002 23:31:35 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnnac27736 for ; Thu, 31 Oct 2002 23:31:27 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnnac24434 for ; Thu, 31 Oct 2002 23:31:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnac19404 for ; Thu, 31 Oct 2002 23:31:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnac19398 for ; Thu, 31 Oct 2002 23:31:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA14763 for ; Thu, 31 Oct 2002 18:31:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9VNV2I24898 for mpls@uu.net; Thu, 31 Oct 2002 18:31:02 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnmzt13991 for ; Thu, 31 Oct 2002 21:21:17 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnmzt19767; Thu, 31 Oct 2002 21:20:40 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnmzt20903; Thu, 31 Oct 2002 21:20:40 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnmzt20858; Thu, 31 Oct 2002 21:20:36 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id QAA70278; Thu, 31 Oct 2002 16:19:10 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200210312119.QAA70278@workhorse.fictitious.org> To: "Gray, Eric" cc: "'curtis@fictitious.org'" , mpls@UU.NET, najam.ahmad@wcom.com, juzer.kopti@wcom.com, plahiri@UU.NET, blaine.christian@wcom.com, Amir Birjandi Reply-To: curtis@fictitious.org Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" In-reply-to: Your message of "Thu, 31 Oct 2002 14:00:30 EST." <1117F7D44159934FB116E36F4ABF221B0267EC45@celox-ma1-ems1.celoxnetworks.com> Date: Thu, 31 Oct 2002 16:19:09 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <1117F7D44159934FB116E36F4ABF221B0267EC45@celox-ma1-ems1.celoxnetwor ks.com>, "Gray, Eric" writes: > Curtis, > > I don't disagree with your points with one caveat: > if a new specification requires implementations to support > multiple approaches for interoperability with existing > implementations, it will effectively encourage multiple > approaches in all future implementations. I assume you > would not argue that the specification should require > implementations to discriminate between existing and new > implementations by requiring newer implementations to > support fewer options. > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 Eric, In the ABSENSE of guidance from the spec, all possibilities have to be covered. What I suggested was the we add guidance. > > I prefer make-before-break reroute and therefore favor explicitly > > disallowing the tspec change (but our implementation is OK either way). > > I think the change should go in a future iteration of rfc3209. The guideance we add is: 1. Do a make-before-break rather than change tspec. Put this requirement (recommendation?) in rfc3209. 2. If you want to play it safe regarding older or buggy implementations anticipate arbitrary change to the PATH. In any case do something reasonable, like don't crash. So exactly what do you disagree with? Or was it unclear what I was suggesting since I started by explaining the current situation? Curtis btw- You'll still need to handle priorities and bandwidth being different among LSP that are part of the same Tunnel (sharing). That is just a fact of life unless you think that it is just fine to drop the old LSP and start a new one (without make-before-break) if you change priorities using the CLI. > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > > Sent: Thursday, October 31, 2002 11:52 AM > > To: Amir Birjandi > > Cc: mpls@UU.NET; najam.ahmad@wcom.com; juzer.kopti@wcom.com; > > plahiri@UU.NET; blaine.christian@wcom.com > > Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" > > > > > > In message <3.0.32.20021030142549.027cb8b0@pop.wcomnet.com>, Amir Birjandi > > writ > > es: > > > > > > Hi, > > > > > > There are straight guide lines for increasing TE-LSP bandwidth in rfc- > > 3209, > > > however there are ambiguities in rfc3209 and rfc2205 for decreasing the > > > TE-LSP bandwidth. > > > > > > It seems vendors can follow the spc if they change the LSP-ID or not > > change > > > the LSP-ID, after the LSP bandwidth has been decreased. > > > > > > This ambiguity may causes some intereoperabilty issues. > > > > > > Perhaps verdors or authors "3209 or 2205 "should address this issue so > > > every one comply to the same standard. > > > > > > Thanks > > > > > > A. > > > > > > > > Amir, > > > > As Markus pointed out, this is yet another case where it is wise for > > the implementor to "be conservative in what you send and liberal in > > what you accept". This has always been good advice to an implementor. > > > > As an ingress anytime anything changes, priority, bandwidth, color > > restrictions (if signaled), request for FRR, do a make-before-break > > reroute. Don't try to send a modified PATH message. It is important > > that an implementation not just change the LSP-id but also keep the > > SESSION object unchanged so that make-before-break reservation sharing > > works (as specified in rfc3209, section 2.5). > > > > As a midpoint be prepared for anything to change in the PATH message. > > Be prepared for priority to change or bandwidth to change. Be > > prepared for color restrictions to change. Be prepared for FRR to be > > added, dropped, or modified. Also be prepared to "share" bandwidth > > among more than two LSPs and for the possibility for those LSPs to > > have different priorities (otherwise how do you make-before-break > > reroute on a change in priority). Be sure to "get it right" when > > making a change or combining shared bandwidths on the CAC decision and > > in the bandwidth accounting (the remaining reservable bandwidth > > amounts that get reflooded). > > > > There is existance proof that this can be accomplished, yielding > > interoperabilty with two major MPLS implementation that do this > > differently. > > > > Of course, you are not an implementor and find yourself with one > > router that has not been sufficiently conservation in what it sends > > and another which has not been sufficiently liberal in what it > > accepts. > > > > The remaining question is if a spec is changed should changing the > > tspec bandwidth in PATH messages for MPLS/TE be explicitly allowed or > > explicitly disallowed. Or both, require that it not be sent by the > > ingress and require that it be accepted by the midpoint so in the > > future we still cover older or slightly buggy implementations. > > > > I prefer make-before-break reroute and therefore favor explicitly > > disallowing the tspec change (but our implementation is OK either way). > > I think the change should go in a future iteration of rfc3209. > > > > Curtis > From owner-mpls@UU.NET Thu Oct 31 18:39:53 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20310 for ; Thu, 31 Oct 2002 18:39:53 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnac27804 for ; Thu, 31 Oct 2002 23:42:08 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnac25989; Thu, 31 Oct 2002 23:41:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnac28281 for mpls-outgoing; Thu, 31 Oct 2002 23:40:35 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnnac28276 for ; Thu, 31 Oct 2002 23:40:21 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnnac02826 for ; Thu, 31 Oct 2002 23:40:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnac25097 for ; Thu, 31 Oct 2002 23:40:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnac25051 for ; Thu, 31 Oct 2002 23:40:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA15201 for ; Thu, 31 Oct 2002 18:40:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g9VNe2E26359 for mpls@uu.net; Thu, 31 Oct 2002 18:40:02 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnnac28231 for ; Thu, 31 Oct 2002 23:39:01 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnnac23296; Thu, 31 Oct 2002 23:38:38 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnac24130; Thu, 31 Oct 2002 23:38:38 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: europe.cisco.com [144.254.52.73]) id QQnnac24123; Thu, 31 Oct 2002 23:38:37 GMT Received: from JVASSEUR-W2K.cisco.com (rtp-vpn1-719.cisco.com [10.82.226.207]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id AAA01855; Fri, 1 Nov 2002 00:38:20 +0100 (MET) Message-Id: <4.3.2.7.2.20021031183709.073be970@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 31 Oct 2002 18:38:19 -0500 To: curtis@fictitious.org From: Jean Philippe Vasseur Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" Cc: "Gray, Eric" , "'curtis@fictitious.org'" , mpls@UU.NET, najam.ahmad@wcom.com, juzer.kopti@wcom.com, plahiri@UU.NET, blaine.christian@wcom.com, Amir Birjandi In-Reply-To: <200210312119.QAA70278@workhorse.fictitious.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi Curtis, At 16:19 31/10/2002 -0500, Curtis Villamizar wrote: >In message ><1117F7D44159934FB116E36F4ABF221B0267EC45@celox-ma1-ems1.celoxnetwor >ks.com>, "Gray, Eric" writes: > > Curtis, > > > > I don't disagree with your points with one caveat: > > if a new specification requires implementations to support > > multiple approaches for interoperability with existing > > implementations, it will effectively encourage multiple > > approaches in all future implementations. I assume you > > would not argue that the specification should require > > implementations to discriminate between existing and new > > implementations by requiring newer implementations to > > support fewer options. > > > > Eric W. Gray > > Systems Architect > > Celox Networks, Inc. > > egray@celoxnetworks.com > > 508 305 7214 > > >Eric, > >In the ABSENSE of guidance from the spec, all possibilities have to be >covered. > >What I suggested was the we add guidance. > > > > I prefer make-before-break reroute and therefore favor explicitly > > > disallowing the tspec change (but our implementation is OK either way). > > > I think the change should go in a future iteration of rfc3209. > >The guideance we add is: > > 1. Do a make-before-break rather than change tspec. Put this > requirement (recommendation?) in rfc3209. > > 2. If you want to play it safe regarding older or buggy > implementations anticipate arbitrary change to the PATH. In any > case do something reasonable, like don't crash. I fully support your position here. JP. >So exactly what do you disagree with? Or was it unclear what I was >suggesting since I started by explaining the current situation? > >Curtis > >btw- You'll still need to handle priorities and bandwidth being >different among LSP that are part of the same Tunnel (sharing). That >is just a fact of life unless you think that it is just fine to drop >the old LSP and start a new one (without make-before-break) if you >change priorities using the CLI. > > > > > -----Original Message----- > > > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > > > Sent: Thursday, October 31, 2002 11:52 AM > > > To: Amir Birjandi > > > Cc: mpls@UU.NET; najam.ahmad@wcom.com; juzer.kopti@wcom.com; > > > plahiri@UU.NET; blaine.christian@wcom.com > > > Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" > > > > > > > > > In message <3.0.32.20021030142549.027cb8b0@pop.wcomnet.com>, Amir > Birjandi > > > writ > > > es: > > > > > > > > Hi, > > > > > > > > There are straight guide lines for increasing TE-LSP bandwidth in rfc- > > > 3209, > > > > however there are ambiguities in rfc3209 and rfc2205 for decreasing the > > > > TE-LSP bandwidth. > > > > > > > > It seems vendors can follow the spc if they change the LSP-ID or not > > > change > > > > the LSP-ID, after the LSP bandwidth has been decreased. > > > > > > > > This ambiguity may causes some intereoperabilty issues. > > > > > > > > Perhaps verdors or authors "3209 or 2205 "should address this issue so > > > > every one comply to the same standard. > > > > > > > > Thanks > > > > > > > > A. > > > > > > > > > > > > Amir, > > > > > > As Markus pointed out, this is yet another case where it is wise for > > > the implementor to "be conservative in what you send and liberal in > > > what you accept". This has always been good advice to an implementor. > > > > > > As an ingress anytime anything changes, priority, bandwidth, color > > > restrictions (if signaled), request for FRR, do a make-before-break > > > reroute. Don't try to send a modified PATH message. It is important > > > that an implementation not just change the LSP-id but also keep the > > > SESSION object unchanged so that make-before-break reservation sharing > > > works (as specified in rfc3209, section 2.5). > > > > > > As a midpoint be prepared for anything to change in the PATH message. > > > Be prepared for priority to change or bandwidth to change. Be > > > prepared for color restrictions to change. Be prepared for FRR to be > > > added, dropped, or modified. Also be prepared to "share" bandwidth > > > among more than two LSPs and for the possibility for those LSPs to > > > have different priorities (otherwise how do you make-before-break > > > reroute on a change in priority). Be sure to "get it right" when > > > making a change or combining shared bandwidths on the CAC decision and > > > in the bandwidth accounting (the remaining reservable bandwidth > > > amounts that get reflooded). > > > > > > There is existance proof that this can be accomplished, yielding > > > interoperabilty with two major MPLS implementation that do this > > > differently. > > > > > > Of course, you are not an implementor and find yourself with one > > > router that has not been sufficiently conservation in what it sends > > > and another which has not been sufficiently liberal in what it > > > accepts. > > > > > > The remaining question is if a spec is changed should changing the > > > tspec bandwidth in PATH messages for MPLS/TE be explicitly allowed or > > > explicitly disallowed. Or both, require that it not be sent by the > > > ingress and require that it be accepted by the midpoint so in the > > > future we still cover older or slightly buggy implementations. > > > > > > I prefer make-before-break reroute and therefore favor explicitly > > > disallowing the tspec change (but our implementation is OK either way). > > > I think the change should go in a future iteration of rfc3209. > > > > > > Curtis > > From owner-mpls@UU.NET Thu Oct 31 18:51:05 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20675 for ; Thu, 31 Oct 2002 18:51:05 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnad02016 for ; Thu, 31 Oct 2002 23:53:25 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnad00596; Thu, 31 Oct 2002 23:52:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnad29537 for mpls-outgoing; Thu, 31 Oct 2002 23:52:17 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnnad29524 for ; Thu, 31 Oct 2002 23:52:13 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnnad25128; Thu, 31 Oct 2002 23:50:41 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnad28313; Thu, 31 Oct 2002 23:50:40 GMT Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQnnad28305; Thu, 31 Oct 2002 23:50:40 GMT Received: from juniper.net (lookout.juniper.net [172.17.20.54]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9VNoJm99032; Thu, 31 Oct 2002 15:50:19 -0800 (PST) (envelope-from dhg@juniper.net) Message-Id: <200210312350.g9VNoJm99032@merlot.juniper.net> To: Jim Boyle From: Markus Jork To: Jean Philippe Vasseur Cc: Amir Birjandi , mpls@UU.NET, najam.ahmad@wcom.com, juzer.kopti@wcom.com, plahiri@UU.NET, blaine.christian@wcom.com cc: kireeti@juniper.net, yakov@juniper.net Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) In-reply-to: Your message of Thu, 31 Oct 2002 13:07:41 -0500. Date: Thu, 31 Oct 2002 15:50:19 -0800 Sender: owner-mpls@UU.NET Precedence: bulk > > Well, in theory this shouldn't cause any interop problems because > no matter what approach it has chosen itself, an implementation has to > be prepared to deal with a bandwidth decrease via a simple change in An implementation has to be prepared to deal with changes in ERO, RRO, Label Object, Label Request Object, SessionAttribute without requiring a new LSP-ID. In fact, an implementation should be prepared that most RSVP objects may change on-the-fly, and react accordingly. None of this is specified in rfc2205 and rfc3209, and most implementations do a good job on it today. Why is bandwidth decrease so uniquely different? > the tspec or via a reroute (new LSP-ID). In practice, it apparently > has caused interop problems... > > I'm only familiar with three implementations, two of them use the > reroute method and one just changes the tspec. Because reroute > is the safer method that is guaranteed to work, I'm with JP here There are deployed implementations on live networks today, it is way beyond the stage of being 'safer'. It is perhaps more appropriate to ask what is the technical reason that a new ID is required to get bandwidth decrease? Der-Hwa > and would suggest that the LSP-ID should always be incremented > for any bandwidth change (whether increase or decrease). > > Markus > > > > Hi Amir, > > > > You're correct, there is an ambiguity in the RFCs that we need to address. > > This can clearly cause some interoperability issues. The simplest and more > > logical approach here is to proceed the same way whether the bandwidth is > > being increased or decreased, just increment the LSP-ID. > > > > Any other vendor opinion ? > > > > Thanks. > > > > JP. > > > > At 14:25 30/10/2002 -0500, Amir Birjandi wrote: > > > > >Hi, > > > > > >There are straight guide lines for increasing TE-LSP bandwidth in rfc-3209 , > > >however there are ambiguities in rfc3209 and rfc2205 for decreasing the > > >TE-LSP bandwidth. > > > > > >It seems vendors can follow the spc if they change the LSP-ID or not chang e > > >the LSP-ID, after the LSP bandwidth has been decreased. > > > > > >This ambiguity may causes some intereoperabilty issues. > > > > > >Perhaps verdors or authors "3209 or 2205 "should address this issue so > > >every one comply to the same standard. > > > > > >Thanks > > > > > >A. > > > > > > From owner-mpls@UU.NET Thu Oct 31 19:59:51 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22223 for ; Thu, 31 Oct 2002 19:59:50 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnai28623 for ; Fri, 1 Nov 2002 01:02:10 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnai27222; Fri, 1 Nov 2002 01:01:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnai26227 for mpls-outgoing; Fri, 1 Nov 2002 01:01:00 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnnai26164 for ; Fri, 1 Nov 2002 01:00:53 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnnai29088 for ; Fri, 1 Nov 2002 01:00:08 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnai26694 for ; Fri, 1 Nov 2002 01:00:08 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnai26672 for ; Fri, 1 Nov 2002 01:00:07 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA19575 for ; Thu, 31 Oct 2002 20:00:07 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA1105n01585 for mpls@uu.net; Thu, 31 Oct 2002 20:00:05 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnnah21527 for ; Fri, 1 Nov 2002 00:58:59 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnnah14285; Fri, 1 Nov 2002 00:58:51 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnah25053; Fri, 1 Nov 2002 00:58:50 GMT Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQnnah25049; Fri, 1 Nov 2002 00:58:50 GMT Received: from juniper.net (lookout.juniper.net [172.17.20.54]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gA10wQm04088; Thu, 31 Oct 2002 16:58:26 -0800 (PST) (envelope-from dhg@juniper.net) Message-Id: <200211010058.gA10wQm04088@merlot.juniper.net> To: Markus Jork cc: Jim Boyle , Jean Philippe Vasseur , Amir Birjandi , mpls@UU.NET, najam.ahmad@wcom.com, juzer.kopti@wcom.com, plahiri@UU.NET, blaine.christian@wcom.com, kireeti@juniper.net, yakov@juniper.net Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) In-reply-to: Your message of Thu, 31 Oct 2002 15:50:19 -0800. Date: Thu, 31 Oct 2002 16:58:25 -0800 From: Der-Hwa Gan Sender: owner-mpls@UU.NET Precedence: bulk Here is a resend. I screwed the From address in the last mail. Der-Hwa ------- Forwarded Message > > Well, in theory this shouldn't cause any interop problems because > no matter what approach it has chosen itself, an implementation has to > be prepared to deal with a bandwidth decrease via a simple change in An implementation has to be prepared to deal with changes in ERO, RRO, Label Object, Label Request Object, SessionAttribute without requiring a new LSP-ID. In fact, an implementation should be prepared that most RSVP objects may change on-the-fly, and react accordingly. None of this is specified in rfc2205 and rfc3209, and most implementations do a good job on it today. Why is bandwidth decrease so uniquely different? > the tspec or via a reroute (new LSP-ID). In practice, it apparently > has caused interop problems... > > I'm only familiar with three implementations, two of them use the > reroute method and one just changes the tspec. Because reroute > is the safer method that is guaranteed to work, I'm with JP here There are deployed implementations on live networks today, it is way beyond the stage of being 'safer'. It is perhaps more appropriate to ask what is the technical reason that a new ID is required to get bandwidth decrease? Der-Hwa > and would suggest that the LSP-ID should always be incremented > for any bandwidth change (whether increase or decrease). > > Markus > > > > Hi Amir, > > > > You're correct, there is an ambiguity in the RFCs that we need to address