From owner-mpls@UU.NET Mon Dec 2 02:36:14 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 CAA06394 for ; Mon, 2 Dec 2002 02:36:14 -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 QQnrlu04805 for ; Mon, 2 Dec 2002 07:39: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 QQnrlu26230; Mon, 2 Dec 2002 07:34:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrlu27808 for mpls-outgoing; Mon, 2 Dec 2002 07:34:30 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 QQnrlu27803 for ; Mon, 2 Dec 2002 07:34:28 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 QQnrlu05525 for ; Mon, 2 Dec 2002 07:34: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 QQnrlu18380 for ; Mon, 2 Dec 2002 07:34:20 GMT Received: from wiprom2mx2.wipro.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx2.wipro.com [203.197.164.42]) id QQnrlu18346 for ; Mon, 2 Dec 2002 07:34:18 GMT Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx2.wipro.com (8.11.3/8.11.3) with SMTP id gB27YDb05718 for ; Mon, 2 Dec 2002 13:04:16 +0530 (IST) Received: from chn-gdy-msg.wipro.com ([10.146.50.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 2 Dec 2002 13:04:08 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Extending VLAN's over public network..(Ethernet Over MPLS) content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 2 Dec 2002 13:04:07 +0530 Message-ID: Thread-Topic: Extending VLAN's over public network..(Ethernet Over MPLS) Thread-Index: AcKV+3mmka08JYd3SKO6PqaDstXFWgD10Nhg From: "Madhan Kumar" To: X-OriginalArrivalTime: 02 Dec 2002 07:34:08.0868 (UTC) FILETIME=[335E0A40:01C299D5] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA06394 Hello Everybody, I need some clarifications on extending VLAN's over public network. Initially VLAN concept is introduced only for privately administered domains as per 802.1Q (Packet never pass through public domain). My question is, Is it possible to extend VLAN over public domain ? Martini's draft on "Ethernet Over MPLS" talks about tranmitting Ethernet packet over MPLS. Is this the idea behind extending VLAN's across public domain ? If so, how a VLAN identifier (VLAN Id or tag) can be mapped to an LSP at the provider edge. Are they configured manually or, are there any standards/protocol for this. Thanks in advance for your replies. Regards, Madhan From owner-mpls@UU.NET Mon Dec 2 03:03: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 DAA06924 for ; Mon, 2 Dec 2002 03:03:31 -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 QQnrlw20181 for ; Mon, 2 Dec 2002 08:06: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 QQnrlw14927; Mon, 2 Dec 2002 08:03:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrlw16814 for mpls-outgoing; Mon, 2 Dec 2002 08:03:24 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 QQnrlw16710 for ; Mon, 2 Dec 2002 08:03: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 QQnrlw08440 for ; Mon, 2 Dec 2002 08:03: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 QQnrlw14453 for ; Mon, 2 Dec 2002 08:03:16 GMT Received: from fsnt.future.futsoft.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQnrlw14375 for ; Mon, 2 Dec 2002 08:03:14 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Mon, 02 Dec 2002 13:36:32 +0530 Received: from srikn (srikn.future.futsoft.com [10.20.6.48]) by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id gB280a9n018969; Mon, 2 Dec 2002 13:30:37 +0530 Reply-To: From: "Srikn" To: "'Madhan Kumar'" , Subject: RE: Extending VLAN's over public network..(Ethernet Over MPLS) Date: Mon, 2 Dec 2002 13:27:21 +0530 Message-Id: <000001c299d8$71e342a0$3006140a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Madhan, Refer to draft-ietf-pwe3-enet-mib and other related drafts in pwe3 working group for further details. Regards, Srikanth. -----Original Message----- From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of Madhan Kumar Sent: Monday, 2 December 2002 1:04 PM To: mpls@uu.net Subject: Extending VLAN's over public network..(Ethernet Over MPLS) Hello Everybody, I need some clarifications on extending VLAN's over public network. Initially VLAN concept is introduced only for privately administered domains as per 802.1Q (Packet never pass through public domain). My question is, Is it possible to extend VLAN over public domain ? Martini's draft on "Ethernet Over MPLS" talks about tranmitting Ethernet packet over MPLS. Is this the idea behind extending VLAN's across public domain ? If so, how a VLAN identifier (VLAN Id or tag) can be mapped to an LSP at the provider edge. Are they configured manually or, are there any standards/protocol for this. Thanks in advance for your replies. Regards, Madhan *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-mpls@UU.NET Mon Dec 2 07:59:26 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 HAA12479 for ; Mon, 2 Dec 2002 07:59:26 -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 QQnrmq01759 for ; Mon, 2 Dec 2002 13:02:13 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 QQnrmp21963; Mon, 2 Dec 2002 12:58:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrmp23711 for mpls-outgoing; Mon, 2 Dec 2002 12:57: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 QQnrmp23706 for ; Mon, 2 Dec 2002 12:57:47 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 QQnrmp05693 for ; Mon, 2 Dec 2002 12:57:07 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 QQnrmp28250 for ; Mon, 2 Dec 2002 12:57:07 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 QQnrmp28243 for ; Mon, 2 Dec 2002 12:57: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 HAA06427 for ; Mon, 2 Dec 2002 07:57:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB2Cv6U01565 for mpls@uu.net; Mon, 2 Dec 2002 07:57:06 -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 QQnrmp23663 for ; Mon, 2 Dec 2002 12:56:28 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 QQnrmp02678 for ; Mon, 2 Dec 2002 12:55: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 QQnrmp27587 for ; Mon, 2 Dec 2002 12:55:50 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 QQnrmp27582 for ; Mon, 2 Dec 2002 12:55:49 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12094; Mon, 2 Dec 2002 07:53:00 -0500 (EST) Message-Id: <200212021253.HAA12094@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-10.txt Date: Mon, 02 Dec 2002 07:53:00 -0500 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-10.txt Pages : 8 Date : 2002-11-27 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-10.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-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-crldp-unnum-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-27105932.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-crldp-unnum-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-crldp-unnum-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-27105932.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Dec 2 09:03: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 JAA15288 for ; Mon, 2 Dec 2002 09:03:38 -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 QQnrmu11502 for ; Mon, 2 Dec 2002 14:06: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 QQnrmu09042; Mon, 2 Dec 2002 14:05:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrmu04259 for mpls-outgoing; Mon, 2 Dec 2002 14:04: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 QQnrmu04228 for ; Mon, 2 Dec 2002 14:04:27 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 QQnrmu12153 for ; Mon, 2 Dec 2002 14:03: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 QQnrmu27610 for ; Mon, 2 Dec 2002 14:03:17 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 QQnrmu27590 for ; Mon, 2 Dec 2002 14:03:17 GMT Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2656.59) id ; Mon, 2 Dec 2002 14:03:02 -0000 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F80109CAED@baker.datcon.co.uk> From: Edward Harrison To: Cisco - Thomas Nadeau Cc: "'jcucchiara@crescentnetworks.com'" , Parama - Cheenu Srinivasan , "'arun@force10networks.com'" , "'hans@ipunplugged.com'" , mpls@UU.NET Subject: RE: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt Date: Mon, 2 Dec 2002 14:01:37 -0000 Deferred-Delivery: Mon, 2 Dec 2002 14:02:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Tom, I notice that the latest MPLS TE and TC MIBs still have resource affinities specified as "Exclude-all" rather than "Exclude-any". Is this another oversight, or did the authors decide that "Exclude-all" was preferred? One other minor thing I've noticed: - The mplsTunnelOwner field is now read-only. However, the comment talks about not being able to modify the object if mplsTunnelRowStatus is active. Surely one can't modify the object at all if it is read-only? [Also, the example in section 9 includes mplsTunnelOwner - I guess this should not be present (and in any case, the given value is no longer correct given the latest definition of the MplsOwner TC)]. Regards, Ed -----Original Message----- From: Cisco - Thomas Nadeau Sent: 15 October 2002 15:22 To: Edward Harrison Cc: 'jcucchiara@crescentnetworks.com'; Parama - Cheenu Srinivasan; 'arun@force10networks.com'; 'hans@ipunplugged.com'; mpls@UU.NET Subject: RE: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt >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 Mon Dec 2 09:30: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 JAA16461 for ; Mon, 2 Dec 2002 09:30:05 -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 QQnrmw12873 for ; Mon, 2 Dec 2002 14:32: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 QQnrmw10325; Mon, 2 Dec 2002 14:31:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrmw07770 for mpls-outgoing; Mon, 2 Dec 2002 14:31: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 QQnrmw07761 for ; Mon, 2 Dec 2002 14:31:11 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 QQnrmw04815 for ; Mon, 2 Dec 2002 14:30: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 QQnrmw26353 for ; Mon, 2 Dec 2002 14:30:52 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 QQnrmw26336 for ; Mon, 2 Dec 2002 14:30:51 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 JAA10917 for ; Mon, 2 Dec 2002 09:30:51 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB2EUpu07515 for mpls@uu.net; Mon, 2 Dec 2002 09:30:51 -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 QQnqtu00802 for ; Wed, 27 Nov 2002 10:30:49 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 QQnqtu25641 for ; Wed, 27 Nov 2002 10:30:36 GMT From: Roberto.Guglielmi@alcatel.it 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 QQnqtu05052 for ; Wed, 27 Nov 2002 10:30:36 GMT Received: from tlvsdy.vim.tlt.alcatel.it by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [194.243.74.244]) id QQnqtu05011 for ; Wed, 27 Nov 2002 10:30:34 GMT Received: from itmail02.prod.alcatel.it (localhost [127.0.0.1]) by tlvsdy.vim.tlt.alcatel.it (8.12.5/8.12.5) with ESMTP id gARAWrof015744 for ; Wed, 27 Nov 2002 11:32:53 +0100 (MET) Received: from alcatel.it ([151.98.36.75]) by itmail02.prod.alcatel.it (Lotus Domino Release 5.0.8) with ESMTP id 2002112711323133:1502 ; Wed, 27 Nov 2002 11:32:31 +0100 Message-ID: <3DE49D3E.8060106@alcatel.it> Date: Wed, 27 Nov 2002 11:23:58 +0100 User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: mpls@UU.NET Subject: Issue relating to mplsTunnelXCPointer X-MIMETrack: Itemize by SMTP Server on ITMAIL02/IT/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/27/2002 11:32:31, Serialize by Router on ITMAIL02/IT/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/27/2002 11:32:36, Serialize complete at 11/27/2002 11:32:36 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tom, tracking the archives I found some emails where you specified that each tunnel instance, in the TE tunnel table, has one LSP per instance and that it *may* be convenient to associate a "group" of LSPs in the LSR MIB together using this primary XCindex, but that is not mandatory. This is not necessarily mandatory, since you can have distinct XCindexes for each underlying LSP as well. In my opinion, even if you associate a "group" of LSPs together using the XCindex, the mplsTunnelXCPointer can only point to one of the XC entries because it's a RowPointer. Am I correct? How can you associate multiple LPSs to one TE tunnel instance? Thanks in advance, Roberto From owner-mpls@UU.NET Mon Dec 2 09:30:59 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 JAA16521 for ; Mon, 2 Dec 2002 09:30:59 -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 QQnrmw00774 for ; Mon, 2 Dec 2002 14:33:44 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 QQnrmw28356; Mon, 2 Dec 2002 14:32:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrmw07791 for mpls-outgoing; Mon, 2 Dec 2002 14:31:54 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 QQnrmw07779 for ; Mon, 2 Dec 2002 14:31:46 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 QQnrmw06364 for ; Mon, 2 Dec 2002 14:31:27 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 QQnrmw26922 for ; Mon, 2 Dec 2002 14:31:27 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 QQnrmw26908 for ; Mon, 2 Dec 2002 14:31:26 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 JAA10957 for ; Mon, 2 Dec 2002 09:31:26 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB2EVQv07563 for mpls@uu.net; Mon, 2 Dec 2002 09:31:26 -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 QQnrcu02414 for ; Fri, 29 Nov 2002 21:01: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 QQnrcu24598 for ; Fri, 29 Nov 2002 21:00:46 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 QQnrcu16922 for ; Fri, 29 Nov 2002 21:00:46 GMT Received: from web20510.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web20510.mail.yahoo.com [216.136.226.145]) id QQnrcu16912 for ; Fri, 29 Nov 2002 21:00:45 GMT Message-ID: <20021129210045.83656.qmail@web20510.mail.yahoo.com> Received: from [128.107.253.37] by web20510.mail.yahoo.com via HTTP; Fri, 29 Nov 2002 13:00:45 PST Date: Fri, 29 Nov 2002 13:00:45 -0800 (PST) From: "Gopal@Yahoo" Subject: Re: [MPLS-OPS]: Regarding LDP scalability To: Intae Jung , mpls-ops@mplsrc.com, mpls@UU.NET In-Reply-To: <002b01c297b9$4b54fc80$e675d3d3@lge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk you may consider: 1. Summerize the networks into IGP on the edge routers. Or, 2. Run Mpls TE Tunnels across the edge routers and have the edge rtrs learn these lot-of-routes thru TE tunnel(auto-route announce). 3.Ibgp---you already said this;-) Rgds, Gopal --- Intae Jung wrote: > Hello, > I'd like to ask a couple of questions regarding a > scalability of LDP, > especially when it is deployed in an ATM-LSR, > adopting Downstream on > Demand distribution with conservative label > retension and ordered control, > where labels (VPI/VCI) are a relatively scarce > resource that must be conserved > in ATM switch. The VPI/VCI is a particularly > valuable and limited resource that > should be saved when an ATM LSR is not able to > support VC-merging capability. > Unfortunately the system I'm managing has no > VC-merging capability. > As defined in the standard, LDP attempts to setup or > release a hop-by-hop LSP > whenever a new route is added or deleted in an ATM > LER through routing protocols, > mainly IGP such as OSPF, ISIS or RIP. > Let me assume a sample ATM-MPLS network as follows. > > Network1 - R1 <-> LER1 <-> LSR1 <-> LSR2 <-> LER2 > <-> R2 - Network2 > > <---IP Network---><------------MPLS > Network---------><---IP Network---> > > R1, R2: Router operating IGP (OSPF or RIP) > LER1, LER2: Edge ATM LSR operating LDP and IGP (iBGP > if needed) > LSR1, LSR2: ATM LSR operating LDP and IGP (OSPF or > IS-IS) > > OSPF or RIP is used in the IP Network and OSPF or > IS-IS is deployed > in the MPLS Network. An i-BGP session could be setup > between LER1 and LER2 > if needed, but not necessarily since LER1 and LER2 > are not supposed to provide > BGP/MPLS functionality, in other words, they don't > work as a PE(Provider Edge) router. > LER1, LER2, LSR1 and LSR2 support only LDP as an > MPLS signaling protocol. > > The problem is that the number of LSP's from LER1 to > LER2 increases > as the number of networks increases in the Network2, > meaning that the number of > routing entries in LER1 increases accordingly, > wherease the number of LSPs supported > by LER1 is a lot smaller than the number of its > route entries. > Eventually, as the number of LSPs setup exceeds the > maximum number of LSP's, > we'll not be able to setup an LSP any more even > though new routes are added. > As I mentioned above, LSR1 and LSR2 don't support > VC-merging capability, > thus the scalability becomes quite servere. > Therefore w're trying to figure out how to support a > lot of routing entries using > a limited number of LSP's. We are trying to come up > with a mechanism that setups > just one LSP between LER1 and LER2, which could be > shared between all best-effort > traffic between Network1 and Networks2. > > The problem we faced is how to setup only 1 LSPs > between LERs automatically, > and then how to map a lot of route entries to the > shared LSP. > Although two LER's are shown in the example, the > number of LSP's between LER's > can be quite large as the number of LER's increases. > We're considering to setup a full-mesh iBGP sessions > between all LER's, and > to use BGP next hop gateway in order to get an > FEC-to-NHFLE mapping. > In other words, routes from Network2 will be > redistributed to LER1 via iBGP session > between LER1 and LER2, and then LER1 will setup just > one LSP for the BGP next hop > address and map all routes from Network1 to the LSP. > However it enforces us to setup iBGP sessions > between all of LER's even though > we don't need them unless we deploy MPLS. We're also > wondering whether > we'll be able to solve the problem using any IGP > capability, like tag field of AS-external > LSA in OSPF. > > Please enlighten us on this issue. > Any experience or idea will be greatly appreciated. > Thanks in advance. > > Regards, > > Jung. __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From owner-mpls@UU.NET Mon Dec 2 09:33: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 JAA16659 for ; Mon, 2 Dec 2002 09:33:04 -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 QQnrmw12488 for ; Mon, 2 Dec 2002 14:35: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 QQnrmw08997; Mon, 2 Dec 2002 14:33:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrmw07837 for mpls-outgoing; Mon, 2 Dec 2002 14:32: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 QQnrmw07805 for ; Mon, 2 Dec 2002 14:32: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 QQnrmw11204 for ; Mon, 2 Dec 2002 14:30:34 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 QQnrmw26046 for ; Mon, 2 Dec 2002 14:30:34 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 QQnrmw26019 for ; Mon, 2 Dec 2002 14:30:33 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 JAA10876 for ; Mon, 2 Dec 2002 09:30:33 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB2EUXG07505 for mpls@uu.net; Mon, 2 Dec 2002 09:30:33 -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 QQnqtl14649 for ; Wed, 27 Nov 2002 08:26:22 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 QQnqtl11861 for ; Wed, 27 Nov 2002 08:26:06 GMT From: Roberto.Guglielmi@alcatel.it 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 QQnqtl23293 for ; Wed, 27 Nov 2002 08:26:05 GMT Received: from tlvsdy.vim.tlt.alcatel.it by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [194.243.74.244]) id QQnqtl23258 for ; Wed, 27 Nov 2002 08:26:04 GMT Received: from itmail02.prod.alcatel.it (localhost [127.0.0.1]) by tlvsdy.vim.tlt.alcatel.it (8.12.5/8.12.5) with ESMTP id gAR8Rmof007105; Wed, 27 Nov 2002 09:27:48 +0100 (MET) Received: from alcatel.it ([151.98.36.75]) by itmail02.prod.alcatel.it (Lotus Domino Release 5.0.8) with ESMTP id 2002112709272943:634 ; Wed, 27 Nov 2002 09:27:29 +0100 Message-ID: <3DE47FEF.3050608@alcatel.it> Date: Wed, 27 Nov 2002 09:18:55 +0100 User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijayanand C - CTD, Chennai." , "Zhu, Rupert" , Yuan Gu CC: mpls@UU.NET Subject: Re: TE MIB - LSR MIB integration References: <55E277B99171E041ABF5F4B1C6DDCA06D65D71@haritha.hclt.com> X-MIMETrack: Itemize by SMTP Server on ITMAIL02/IT/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/27/2002 09:27:29, Serialize by Router on ITMAIL02/IT/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/27/2002 09:27:32, Serialize complete at 11/27/2002 09:27:32 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yuan,Rupert and Vijayanand thanks for your replies. Please see my comments inline. - Roberto Vijayanand C - CTD, Chennai. wrote: >In this scenario there is only one TE tunnel , ie the outer tunnel across R1 >to R3. Three vanilla LSPs use it to tunnel flows across R1 to R3. ( hope I >understood the problem right). > You understood right. > >Hence , it would be appropriate to have 3 XC entries( pointed from their >respective FTN entries) corresponding to each vanilla LSP with the tunnel >label in their label stacks. > So, the tunnel label in the mplsOutSegmentTable and the bottom label in the mplsLabelStackTable? > >Also, I think there should be only one tunnel entry corresponding to the TE >tunnel. > Which table points to this tunnel entry? Where does this tunnel entry point to? > >Thanks and Regards >Vijay > >"Where protocols are a passion, MPLS is a religion " > >-----Original Message----- >From: Zhu, Rupert [mailto:rupert.zhu@santera.com] >Sent: Wednesday, November 27, 2002 6:01 AM >To: Yuan Gu; Roberto.Guglielmi@alcatel.it; mpls@UU.NET >Subject: RE: TE MIB - LSR MIB integration > > >Roberto, Yuan: > >Interesting scenario. I agree on Yuan's approach, if you >insist on mapping the 3 LSPs into one TE tunnel. >However, why should we choose to map the 3 LSPs to >the same tunnel? > The incoming flows are Ethernet TLS flow traversing an intervening MPLS network. The typical scenario is to assign each of the flows entering and leaving the MPLS network from the same end points, with a VC label (following Martini's draft) and encapsulate all the obtained LSPs into one TE tunnel, in order to offer the different clients the same service. > >The application described is to have 3 flows carried in 3 LSPs, >respectively. Since there is no logical relationships between >the 3 LSPs, (e.g., load sharing, backup, etc.), it seems more >appropriate to model them as 3 independent entities. > >Alternative Solution #1: Map to 3 LSPs directly. > > -- Populate 3 entries in mplsFTNTable (in MPLS-FTN-MIB). > Have each mplsFTNActionType=redirectLSP. > Have each mplsFTNActionPointer pointing to one > of the 3 mplsXCEntry. > The classification is achieved using the pwe MIBs. The VC label is kept in the MPLS world, not in the pwe world. > >Alternative Solution #2: Map to 3 tunnels (instead of one). > > -- Populate 3 entries in mplsFTNTable (in MPLS-FTN-MIB). > -- Populate 3 entries in mplsTunnelTable, each representing > a distinct (logical) tunnel. (That is, they have different > values in mplsTunnelIndex.) > -- Have each mplsFTNActionType=redirectTunnel. > Have each mplsFTNActionPointer pointing to one of > the 3 mplsTunnelEntry. > >In other words, if there is no relationship between the 3 LSPs, >then they do not belong to the same TE tunnel. > >My two cents. > >-- Rupert > > > > >>-----Original Message----- >>From: Yuan Gu [mailto:yuangu@ipinfusion.com] >>Sent: Monday, November 25, 2002 2:12 PM >>To: Roberto.Guglielmi@alcatel.it; mpls@UU.NET >>Subject: RE: TE MIB - LSR MIB integration >> >> >>Hello, Roberto: >> >> >> >>>-----Original Message----- >>>From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of >>>Roberto.Guglielmi@alcatel.it >>>Sent: Monday, November 25, 2002 3:19 AM >>>To: mpls@UU.NET >>>Subject: TE MIB - LSR MIB integration >>> >>> >>>Hello everybody, >>>I have a doubt about interactions between LSR MIB and TE >>> >>> >>MIB for what >> >> >>>concerning LSPs nested in TE tunnels. >>>Consider the following scenario: >>> >>>R1 -------- R2 -------- R3 >>> >>>and suppose, for example, I have three incoming flows. I >>> >>> >>want to insert >> >> >>>each flow in one LSP and tunnel the three LSPs in one TE tunnel. >>>My questions are: >>> >>>1) How are the three LSPs mapped on the same TE tunnel? >>> >>> >>There will be 3 entries in mplsTunnelTable. Each entry has different >>mplsTuunnelInstance. >> >>The mplsTunnelInstance "Uniquely identifies an instance of a >>tunnel. It is >>useful to identify multiple instances of tunnels for the >>purposes of backup >>and parallel tunnels." >>You may want to put your LSPID into this field. >> >> >> >>>2) Is there only one entry in the mplsTunnelTable pointing >>> >>> >>to one entry >> >> >>>in the mplsXCTable? >>> >>> >>There will be 3 corresponding entries in mplsXCTable. Each entry has >>different mplsXCLspId (RSVP-TE or CR-LDP). >> >> >> I understand your point of view. In my opinion, the 3 entries in mplsXCTable should have the tunnel label in the mplsOutSegmentTable and the bottom label in the mplsLabelStackTable. Do you agree? If not, where the 2 labels are indicated for each flow? >> >> >> > > > From owner-mpls@UU.NET Mon Dec 2 09:40: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 JAA16976 for ; Mon, 2 Dec 2002 09:40: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 QQnrmw24938 for ; Mon, 2 Dec 2002 14:42: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 QQnrmw15304; Mon, 2 Dec 2002 14:37:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrmw07845 for mpls-outgoing; Mon, 2 Dec 2002 14:32:19 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 QQnrmw07806 for ; Mon, 2 Dec 2002 14:32: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 QQnrmw11546 for ; Mon, 2 Dec 2002 14:30: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 QQnrmw26158 for ; Mon, 2 Dec 2002 14:30:41 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 QQnrmw26151 for ; Mon, 2 Dec 2002 14:30:41 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 JAA10894 for ; Mon, 2 Dec 2002 09:30:40 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB2EUeu07509 for mpls@uu.net; Mon, 2 Dec 2002 09:30:40 -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 QQnqtt00049 for ; Wed, 27 Nov 2002 10:20:52 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 QQnqtt28960 for ; Wed, 27 Nov 2002 10:20:40 GMT From: Roberto.Guglielmi@alcatel.it 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 QQnqtt25531 for ; Wed, 27 Nov 2002 10:20:39 GMT Received: from tlvsca.vim.tlt.alcatel.it by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [194.243.74.245]) id QQnqtt25514 for ; Wed, 27 Nov 2002 10:20:38 GMT Received: from itmail02.prod.alcatel.it (localhost [127.0.0.1]) by tlvsca.vim.tlt.alcatel.it (8.12.5/8.12.5) with ESMTP id gARAK0rt000058; Wed, 27 Nov 2002 11:20:00 +0100 (MET) Received: from alcatel.it ([151.98.36.75]) by itmail02.prod.alcatel.it (Lotus Domino Release 5.0.8) with ESMTP id 2002112711221134:1404 ; Wed, 27 Nov 2002 11:22:11 +0100 Message-ID: <3DE49AD2.6090806@alcatel.it> Date: Wed, 27 Nov 2002 11:13:38 +0100 User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijayanand C - CTD, Chennai." CC: mpls@UU.NET Subject: Re: TE MIB - LSR MIB integration References: <55E277B99171E041ABF5F4B1C6DDCA06D6605C@haritha.hclt.com> X-MIMETrack: Itemize by SMTP Server on ITMAIL02/IT/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/27/2002 11:22:11, Serialize by Router on ITMAIL02/IT/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/27/2002 11:22:13, Serialize complete at 11/27/2002 11:22:13 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Vijayanand, please let me know if i understood what you just said. 1) There are 4 XC entries: - 1 XC entry associated to the TE tunnel entry with only the tunnel label in the Out Segment - 3 XC entries each one associated to one flow and each one with the tunnel label in the Out Segment and the bottom label in the Stack Table. Is this correct? 2) In this case, how is it possible to get to one of the 3 XC entries containing the stack of labels, passing by the TE tunnel table, since the TE tunnel entry points to the XC entry with only the tunnel label? In other words, I don't understand how multiple LSPs can use the TE tunnel entry! - Roberto Vijayanand C - CTD, Chennai. wrote: >The label stack and top label arrangements are as usual , as you said. > >Reg. the TE tunnel entry - I would imagine its going to have an associated >XC entry ,which has associated outsegment, FTN etc. and would be able to >carry traffic directly( not just as a tunnel for other LSPs). >Multiple LSPs may be using this TE tunnel entry, since they would be holding >the TE tunnel label as their top label in their outsegments. > >Thanks and Regards >Vijay > >"Where protocols are a passion, MPLS is a religion " > >-----Original Message----- >From: Roberto.Guglielmi@alcatel.it [mailto:Roberto.Guglielmi@alcatel.it] >Sent: Wednesday, November 27, 2002 1:49 PM >To: Vijayanand C - CTD, Chennai.; Zhu, Rupert; Yuan Gu >Cc: mpls@UU.NET >Subject: Re: TE MIB - LSR MIB integration > > >Yuan,Rupert and Vijayanand thanks for your replies. >Please see my comments inline. > > - Roberto > > > >Vijayanand C - CTD, Chennai. wrote: > > > >>In this scenario there is only one TE tunnel , ie the outer tunnel across >> >> >R1 > > >>to R3. Three vanilla LSPs use it to tunnel flows across R1 to R3. ( hope I >>understood the problem right). >> >> >> >You understood right. > > > >>Hence , it would be appropriate to have 3 XC entries( pointed from their >>respective FTN entries) corresponding to each vanilla LSP with the tunnel >>label in their label stacks. >> >> >> >So, the tunnel label in the mplsOutSegmentTable and the bottom label in the >mplsLabelStackTable? > > > >>Also, I think there should be only one tunnel entry corresponding to the TE >>tunnel. >> >> >> >Which table points to this tunnel entry? Where does this tunnel entry >point to? > > > >>Thanks and Regards >>Vijay >> >>"Where protocols are a passion, MPLS is a religion " >> >>-----Original Message----- >>From: Zhu, Rupert [mailto:rupert.zhu@santera.com] >>Sent: Wednesday, November 27, 2002 6:01 AM >>To: Yuan Gu; Roberto.Guglielmi@alcatel.it; mpls@UU.NET >>Subject: RE: TE MIB - LSR MIB integration >> >> >>Roberto, Yuan: >> >>Interesting scenario. I agree on Yuan's approach, if you >>insist on mapping the 3 LSPs into one TE tunnel. >>However, why should we choose to map the 3 LSPs to >>the same tunnel? >> >> >> >The incoming flows are Ethernet TLS flow traversing an intervening MPLS >network. The typical scenario is to assign each of the flows entering >and leaving the MPLS network from the same end points, with a VC label >(following Martini's draft) and encapsulate all the obtained LSPs into >one TE tunnel, in order to offer the different clients the same service. > > > >>The application described is to have 3 flows carried in 3 LSPs, >>respectively. Since there is no logical relationships between >>the 3 LSPs, (e.g., load sharing, backup, etc.), it seems more >>appropriate to model them as 3 independent entities. >> >>Alternative Solution #1: Map to 3 LSPs directly. >> >> -- Populate 3 entries in mplsFTNTable (in MPLS-FTN-MIB). >> Have each mplsFTNActionType=redirectLSP. >> Have each mplsFTNActionPointer pointing to one >> of the 3 mplsXCEntry. >> >> >> >The classification is achieved using the pwe MIBs. The VC label is kept >in the MPLS world, not in the pwe world. > > > >>Alternative Solution #2: Map to 3 tunnels (instead of one). >> >> -- Populate 3 entries in mplsFTNTable (in MPLS-FTN-MIB). >> -- Populate 3 entries in mplsTunnelTable, each representing >> a distinct (logical) tunnel. (That is, they have different >> values in mplsTunnelIndex.) >> -- Have each mplsFTNActionType=redirectTunnel. >> Have each mplsFTNActionPointer pointing to one of >> the 3 mplsTunnelEntry. >> >>In other words, if there is no relationship between the 3 LSPs, >>then they do not belong to the same TE tunnel. >> >>My two cents. >> >>-- Rupert >> >> >> >> >> >> >>>-----Original Message----- >>>From: Yuan Gu [mailto:yuangu@ipinfusion.com] >>>Sent: Monday, November 25, 2002 2:12 PM >>>To: Roberto.Guglielmi@alcatel.it; mpls@UU.NET >>>Subject: RE: TE MIB - LSR MIB integration >>> >>> >>>Hello, Roberto: >>> >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of >>>>Roberto.Guglielmi@alcatel.it >>>>Sent: Monday, November 25, 2002 3:19 AM >>>>To: mpls@UU.NET >>>>Subject: TE MIB - LSR MIB integration >>>> >>>> >>>>Hello everybody, >>>>I have a doubt about interactions between LSR MIB and TE >>>> >>>> >>>> >>>> >>>MIB for what >>> >>> >>> >>> >>>>concerning LSPs nested in TE tunnels. >>>>Consider the following scenario: >>>> >>>>R1 -------- R2 -------- R3 >>>> >>>>and suppose, for example, I have three incoming flows. I >>>> >>>> >>>> >>>> >>>want to insert >>> >>> >>> >>> >>>>each flow in one LSP and tunnel the three LSPs in one TE tunnel. >>>>My questions are: >>>> >>>>1) How are the three LSPs mapped on the same TE tunnel? >>>> >>>> >>>> >>>> >>>There will be 3 entries in mplsTunnelTable. Each entry has different >>>mplsTuunnelInstance. >>> >>>The mplsTunnelInstance "Uniquely identifies an instance of a >>>tunnel. It is >>>useful to identify multiple instances of tunnels for the >>>purposes of backup >>>and parallel tunnels." >>>You may want to put your LSPID into this field. >>> >>> >>> >>> >>> >>>>2) Is there only one entry in the mplsTunnelTable pointing >>>> >>>> >>>> >>>> >>>to one entry >>> >>> >>> >>> >>>>in the mplsXCTable? >>>> >>>> >>>> >>>> >>>There will be 3 corresponding entries in mplsXCTable. Each entry has >>>different mplsXCLspId (RSVP-TE or CR-LDP). >>> >>> >>> >>> >>> >I understand your point of view. >In my opinion, the 3 entries in mplsXCTable should have the tunnel label in >the mplsOutSegmentTable and the bottom label in the mplsLabelStackTable. Do >you agree? If not, where the 2 labels are indicated for each flow? > > > > >>> >>> >>> >>> >> >> >> >> > > > > From owner-mpls@UU.NET Mon Dec 2 09:41:09 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 JAA17004 for ; Mon, 2 Dec 2002 09:41:09 -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 QQnrmw19913 for ; Mon, 2 Dec 2002 14:43: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 QQnrmw15923; Mon, 2 Dec 2002 14:41:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrmw07930 for mpls-outgoing; Mon, 2 Dec 2002 14:33:40 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 QQnrmw07865 for ; Mon, 2 Dec 2002 14:32:41 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 QQnrmw13149 for ; Mon, 2 Dec 2002 14:31: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 QQnrmw26723 for ; Mon, 2 Dec 2002 14:31:14 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 QQnrmw26712 for ; Mon, 2 Dec 2002 14:31:14 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 JAA10944 for ; Mon, 2 Dec 2002 09:31:14 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB2EVEp07559 for mpls@uu.net; Mon, 2 Dec 2002 09:31:14 -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 QQnqxd21804 for ; Thu, 28 Nov 2002 08:17: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 QQnqxd12541 for ; Thu, 28 Nov 2002 08:16:44 GMT From: Roberto.Guglielmi@alcatel.it 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 QQnqxd09914 for ; Thu, 28 Nov 2002 08:16:44 GMT Received: from tlvsdy.vim.tlt.alcatel.it by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [194.243.74.244]) id QQnqxd09908 for ; Thu, 28 Nov 2002 08:16:42 GMT Received: from itmail02.prod.alcatel.it (localhost [127.0.0.1]) by tlvsdy.vim.tlt.alcatel.it (8.12.5/8.12.5) with ESMTP id gAS8IPof011262; Thu, 28 Nov 2002 09:18:25 +0100 (MET) Received: from alcatel.it ([151.98.36.75]) by itmail02.prod.alcatel.it (Lotus Domino Release 5.0.8) with ESMTP id 2002112809180872:757 ; Thu, 28 Nov 2002 09:18:08 +0100 Message-ID: <3DE5CF3A.1050208@alcatel.it> Date: Thu, 28 Nov 2002 09:09:30 +0100 User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijayanand C - CTD, Chennai." Cc: rupert.zhu@santera.com, mpls@UU.NET Subject: Re: TE MIB - LSR MIB integration References: <55E277B99171E041ABF5F4B1C6DDCA06D66146@haritha.hclt.com> X-MIMETrack: Itemize by SMTP Server on ITMAIL02/IT/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/28/2002 09:18:08, Serialize by Router on ITMAIL02/IT/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/28/2002 09:18:10, Serialize complete at 11/28/2002 09:18:10 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Vijay, I have a doubt. If the TE tunnel is internally used by the LSP, how is it possible to use all the parameters configured in the TE MIB for the TE tunnel, given the fact the the classification process would point directly to the XC entry? You can only apply traffic parameters retrieved from the LSR MIB. - Roberto Vijayanand C - CTD, Chennai. wrote: >Yes, thats because its' the vanilla LSP which is the 'hit' in the >classification, and the TE tunnel is internally used by it. > >Its my pleasure to help. > >Thanks and Regards >Vijay > >"Where protocols are a passion, MPLS is a religion " > >-----Original Message----- >From: Roberto.Guglielmi@alcatel.it [mailto:Roberto.Guglielmi@alcatel.it] >Sent: Wednesday, November 27, 2002 4:14 PM >To: Vijayanand C - CTD, Chennai. >Subject: Re: TE MIB - LSR MIB integration > > >Hence, the FTNActionPointer would point directly to the XC entry and not >to the TE tunnel entry, is it right? This was the point getting me confused. >I really appreciate your help. > - Roberto > > >Vijayanand C - CTD, Chennai. wrote: > > > >>Yes, this is what I meant. >> >>But I dont understand what you are trying to get at. >> >>At the ingress the FTN map entries for the vanilla LSPs will clasify the >>packet and use the labels pointed to by the XC which will contain the TE >>tunnel label on top. This top label will be associated with the subsequent >>traffic shaping activities. >> >> >>Thanks and Regards >>Vijay >> >>"Where protocols are a passion, MPLS is a religion " >> >>-----Original Message----- >>From: Roberto.Guglielmi@alcatel.it [mailto:Roberto.Guglielmi@alcatel.it] >>Sent: Wednesday, November 27, 2002 3:44 PM >>To: Vijayanand C - CTD, Chennai. >>Cc: mpls@UU.NET >>Subject: Re: TE MIB - LSR MIB integration >> >> >>Vijayanand, >>please let me know if i understood what you just said. >> >>1) There are 4 XC entries: >> - 1 XC entry associated to the TE tunnel entry with only the >>tunnel label in the Out Segment >> - 3 XC entries each one associated to one flow and each one with >>the tunnel label in the Out Segment and the bottom label in the Stack >> >> >Table. > > >>Is this correct? >> >>2) In this case, how is it possible to get to one of the 3 XC entries >>containing the stack of labels, passing by the TE tunnel table, since >>the TE tunnel entry points to the XC entry with only the tunnel label? >>In other words, I don't understand how multiple LSPs can use the TE >>tunnel entry! >> >> - Roberto >> >> >>Vijayanand C - CTD, Chennai. wrote: >> >> >> >> >> >>>The label stack and top label arrangements are as usual , as you said. >>> >>>Reg. the TE tunnel entry - I would imagine its going to have an associated >>>XC entry ,which has associated outsegment, FTN etc. and would be able to >>>carry traffic directly( not just as a tunnel for other LSPs). >>>Multiple LSPs may be using this TE tunnel entry, since they would be >>> >>> >>> >>> >>holding >> >> >> >> >>>the TE tunnel label as their top label in their outsegments. >>> >>>Thanks and Regards >>>Vijay >>> >>>"Where protocols are a passion, MPLS is a religion " >>> >>>-----Original Message----- >>>From: Roberto.Guglielmi@alcatel.it [mailto:Roberto.Guglielmi@alcatel.it] >>>Sent: Wednesday, November 27, 2002 1:49 PM >>>To: Vijayanand C - CTD, Chennai.; Zhu, Rupert; Yuan Gu >>>Cc: mpls@UU.NET >>>Subject: Re: TE MIB - LSR MIB integration >>> >>> >>>Yuan,Rupert and Vijayanand thanks for your replies. >>>Please see my comments inline. >>> >>> - Roberto >>> >>> >>> >>>Vijayanand C - CTD, Chennai. wrote: >>> >>> >>> >>> >>> >>> >>> >>>>In this scenario there is only one TE tunnel , ie the outer tunnel across >>>> >>>> >>>> >>>> >>>> >>>> >>>R1 >>> >>> >>> >>> >>> >>> >>>>to R3. Three vanilla LSPs use it to tunnel flows across R1 to R3. ( hope >>>> >>>> >I > > >>>>understood the problem right). >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>You understood right. >>> >>> >>> >>> >>> >>> >>> >>>>Hence , it would be appropriate to have 3 XC entries( pointed from their >>>>respective FTN entries) corresponding to each vanilla LSP with the tunnel >>>>label in their label stacks. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>So, the tunnel label in the mplsOutSegmentTable and the bottom label in >>> >>> >the > > >>>mplsLabelStackTable? >>> >>> >>> >>> >>> >>> >>> >>>>Also, I think there should be only one tunnel entry corresponding to the >>>> >>>> >>>> >>>> >>TE >> >> >> >> >>>>tunnel. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>Which table points to this tunnel entry? Where does this tunnel entry >>>point to? >>> >>> >>> >>> >>> >>> >>> >>>>Thanks and Regards >>>>Vijay >>>> >>>>"Where protocols are a passion, MPLS is a religion " >>>> >>>>-----Original Message----- >>>>From: Zhu, Rupert [mailto:rupert.zhu@santera.com] >>>>Sent: Wednesday, November 27, 2002 6:01 AM >>>>To: Yuan Gu; Roberto.Guglielmi@alcatel.it; mpls@UU.NET >>>>Subject: RE: TE MIB - LSR MIB integration >>>> >>>> >>>>Roberto, Yuan: >>>> >>>>Interesting scenario. I agree on Yuan's approach, if you >>>>insist on mapping the 3 LSPs into one TE tunnel. >>>>However, why should we choose to map the 3 LSPs to >>>>the same tunnel? >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>The incoming flows are Ethernet TLS flow traversing an intervening MPLS >>>network. The typical scenario is to assign each of the flows entering >>>and leaving the MPLS network from the same end points, with a VC label >>>(following Martini's draft) and encapsulate all the obtained LSPs into >>>one TE tunnel, in order to offer the different clients the same service. >>> >>> >>> >>> >>> >>> >>> >>>>The application described is to have 3 flows carried in 3 LSPs, >>>>respectively. Since there is no logical relationships between >>>>the 3 LSPs, (e.g., load sharing, backup, etc.), it seems more >>>>appropriate to model them as 3 independent entities. >>>> >>>>Alternative Solution #1: Map to 3 LSPs directly. >>>> >>>> -- Populate 3 entries in mplsFTNTable (in MPLS-FTN-MIB). >>>> Have each mplsFTNActionType=redirectLSP. >>>> Have each mplsFTNActionPointer pointing to one >>>> of the 3 mplsXCEntry. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>The classification is achieved using the pwe MIBs. The VC label is kept >>>in the MPLS world, not in the pwe world. >>> >>> >>> >>> >>> >>> >>> >>>>Alternative Solution #2: Map to 3 tunnels (instead of one). >>>> >>>> -- Populate 3 entries in mplsFTNTable (in MPLS-FTN-MIB). >>>> -- Populate 3 entries in mplsTunnelTable, each representing >>>> a distinct (logical) tunnel. (That is, they have different >>>> values in mplsTunnelIndex.) >>>> -- Have each mplsFTNActionType=redirectTunnel. >>>> Have each mplsFTNActionPointer pointing to one of >>>> the 3 mplsTunnelEntry. >>>> >>>>In other words, if there is no relationship between the 3 LSPs, >>>>then they do not belong to the same TE tunnel. >>>> >>>>My two cents. >>>> >>>>-- Rupert >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Yuan Gu [mailto:yuangu@ipinfusion.com] >>>>>Sent: Monday, November 25, 2002 2:12 PM >>>>>To: Roberto.Guglielmi@alcatel.it; mpls@UU.NET >>>>>Subject: RE: TE MIB - LSR MIB integration >>>>> >>>>> >>>>>Hello, Roberto: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of >>>>>>Roberto.Guglielmi@alcatel.it >>>>>>Sent: Monday, November 25, 2002 3:19 AM >>>>>>To: mpls@UU.NET >>>>>>Subject: TE MIB - LSR MIB integration >>>>>> >>>>>> >>>>>>Hello everybody, >>>>>>I have a doubt about interactions between LSR MIB and TE >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>MIB for what >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>concerning LSPs nested in TE tunnels. >>>>>>Consider the following scenario: >>>>>> >>>>>>R1 -------- R2 -------- R3 >>>>>> >>>>>>and suppose, for example, I have three incoming flows. I >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>want to insert >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>each flow in one LSP and tunnel the three LSPs in one TE tunnel. >>>>>>My questions are: >>>>>> >>>>>>1) How are the three LSPs mapped on the same TE tunnel? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>There will be 3 entries in mplsTunnelTable. Each entry has different >>>>>mplsTuunnelInstance. >>>>> >>>>>The mplsTunnelInstance "Uniquely identifies an instance of a >>>>>tunnel. It is >>>>>useful to identify multiple instances of tunnels for the >>>>>purposes of backup >>>>>and parallel tunnels." >>>>>You may want to put your LSPID into this field. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>2) Is there only one entry in the mplsTunnelTable pointing >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>to one entry >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>in the mplsXCTable? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>There will be 3 corresponding entries in mplsXCTable. Each entry has >>>>>different mplsXCLspId (RSVP-TE or CR-LDP). >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>I understand your point of view. >>>In my opinion, the 3 entries in mplsXCTable should have the tunnel label >>> >>> >in > > >>>the mplsOutSegmentTable and the bottom label in the mplsLabelStackTable. >>> >>> >Do > > >>>you agree? If not, where the 2 labels are indicated for each flow? >>> >>> >>> >>> >>> >>> >>> >>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> >> > > > > From owner-mpls@UU.NET Mon Dec 2 10:01:56 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 KAA18006 for ; Mon, 2 Dec 2002 10:01:56 -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 QQnrmy26539 for ; Mon, 2 Dec 2002 15:04: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 QQnrmy23089; Mon, 2 Dec 2002 15:03:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrmy19317 for mpls-outgoing; Mon, 2 Dec 2002 15:03: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 QQnrmy19142 for ; Mon, 2 Dec 2002 15:03:04 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 QQnrmy15435 for ; Mon, 2 Dec 2002 15:01: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 QQnrmy14270 for ; Mon, 2 Dec 2002 15:01:07 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 QQnrmy14248 for ; Mon, 2 Dec 2002 15:01: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 KAA13163 for ; Mon, 2 Dec 2002 10:01:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB2F16o20588 for mpls@uu.net; Mon, 2 Dec 2002 10:01:06 -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 QQnrmx11080 for ; Mon, 2 Dec 2002 14:53:47 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 QQnrmx11423 for ; Mon, 2 Dec 2002 14:53: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 QQnrmx07701 for ; Mon, 2 Dec 2002 14:53:03 GMT Received: from rooster.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hen.cisco.com [64.102.19.198]) id QQnrmx07691 for ; Mon, 2 Dec 2002 14:53:03 GMT Received: from CPIGNATA-W2K.cisco.com (dhcp-64-102-52-173.cisco.com [64.102.52.173]) by rooster.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id gB2Eqs010131; Mon, 2 Dec 2002 09:52:54 -0500 (EST) Message-Id: <4.3.2.7.2.20021202094231.01ada038@rooster> X-Sender: cpignata@rooster X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 02 Dec 2002 09:51:50 -0500 To: "Intae Jung" , , From: "Carlos M. Pignataro" Subject: Re: Regarding LDP scalability In-Reply-To: <002b01c297b9$4b54fc80$e675d3d3@lge.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_2980645==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_2980645==_.ALT Content-Type: text/plain; charset="us-ascii" Intae, At 12:09 AM 11/30/2002 +0900, Intae Jung wrote: >Hello, >I'd like to ask a couple of questions regarding a scalability of LDP, >especially when it is deployed in an ATM-LSR, adopting Downstream on >Demand distribution with conservative label retension and ordered control, >where labels (VPI/VCI) are a relatively scarce resource that must be conserved >in ATM switch. The VPI/VCI is a particularly valuable and limited resource that >should be saved when an ATM LSR is not able to support VC-merging capability. >Unfortunately the system I'm managing has no VC-merging capability. >As defined in the standard, LDP attempts to setup or release a hop-by-hop LSP >whenever a new route is added or deleted in an ATM LER through routing protocols, >mainly IGP such as OSPF, ISIS or RIP. >Let me assume a sample ATM-MPLS network as follows. > >Network1 - R1 <-> LER1 <-> LSR1 <-> LSR2 <-> LER2 <-> R2 - Network2 > ><---IP Network---><------------MPLS Network---------><---IP Network---> > >R1, R2: Router operating IGP (OSPF or RIP) >LER1, LER2: Edge ATM LSR operating LDP and IGP (iBGP if needed) >LSR1, LSR2: ATM LSR operating LDP and IGP (OSPF or IS-IS) > >OSPF or RIP is used in the IP Network and OSPF or IS-IS is deployed >in the MPLS Network. An i-BGP session could be setup between LER1 and LER2 >if needed, but not necessarily since LER1 and LER2 are not supposed to provide >BGP/MPLS functionality, in other words, they don't work as a PE(Provider Edge) router. >LER1, LER2, LSR1 and LSR2 support only LDP as an MPLS signaling protocol. > >The problem is that the number of LSP's from LER1 to LER2 increases >as the number of networks increases in the Network2, meaning that the number of >routing entries in LER1 increases accordingly, wherease the number of LSPs supported >by LER1 is a lot smaller than the number of its route entries. >Eventually, as the number of LSPs setup exceeds the maximum number of LSP's, >we'll not be able to setup an LSP any more even though new routes are added. >As I mentioned above, LSR1 and LSR2 don't support VC-merging capability, >thus the scalability becomes quite servere. >Therefore w're trying to figure out how to support a lot of routing entries using >a limited number of LSP's. We are trying to come up with a mechanism that setups >just one LSP between LER1 and LER2, which could be shared between all best-effort >traffic between Network1 and Networks2. Some options to reduce the # of LSPs would be: 1. Run MPLS TE Tunnels between the edge routers and have the edge routers learn these routes through the Tunnel (but you mention only LDP distributing labels). 2. Summarize the networks on the edge routers (using your IGP). 3. As you mention, use iBGP. Some implementations also improve scalability by allowing an edge router, by configuration, to selects FECs for which to request a label (using DoD), as well as disabling ATM LSRs from requesting labels. Thanks, Carlos. >The problem we faced is how to setup only 1 LSPs between LERs automatically, >and then how to map a lot of route entries to the shared LSP. >Although two LER's are shown in the example, the number of LSP's between LER's >can be quite large as the number of LER's increases. >We're considering to setup a full-mesh iBGP sessions between all LER's, and >to use BGP next hop gateway in order to get an FEC-to-NHFLE mapping. >In other words, routes from Network2 will be redistributed to LER1 via iBGP session >between LER1 and LER2, and then LER1 will setup just one LSP for the BGP next hop >address and map all routes from Network1 to the LSP. >However it enforces us to setup iBGP sessions between all of LER's even though >we don't need them unless we deploy MPLS. We're also wondering whether >we'll be able to solve the problem using any IGP capability, like tag field of AS-external >LSA in OSPF. > >Please enlighten us on this issue. >Any experience or idea will be greatly appreciated. >Thanks in advance. > >Regards, > >Jung. ================================================================= | Carlos Pignataro - CCIE 4619 cisco Systems, Inc. | Escalation RTP | cpignata@cisco.com || || | +1 919 392 7428 - office .||. .||. | +1 919 345 3028 - mobile .||||. .||||. | +1 919 392 6470 - fax .:||||||||:.:||||||||:. | 7025 Kit Creek Road, PO Box 14987 Are you Ready ? | Research Triangle Park, NC 27709 ================================================================= --=====================_2980645==_.ALT Content-Type: text/html; charset="us-ascii" Intae,


At 12:09 AM 11/30/2002 +0900, Intae Jung wrote:
Hello,
I'd like to ask a couple of questions regarding a scalability of LDP,
especially when it is deployed in an ATM-LSR, adopting Downstream on
Demand distribution with conservative label retension and ordered control,
where labels (VPI/VCI) are a relatively scarce resource that must be conserved
in ATM switch. The VPI/VCI is a particularly valuable and limited resource that
should be saved when an ATM LSR is not able to support VC-merging capability.
Unfortunately the system I'm managing has no VC-merging capability.
As defined in the standard, LDP attempts to setup or release a hop-by-hop LSP
whenever a new route is added or deleted in an ATM LER through routing protocols,
mainly IGP such as OSPF, ISIS or RIP.
Let me assume a sample ATM-MPLS network as follows.

Network1 - R1 <-> LER1 <-> LSR1 <-> LSR2 <-> LER2 <-> R2 - Network2

<---IP Network---><------------MPLS Network---------><---IP Network--->

R1, R2: Router operating IGP (OSPF or RIP)
LER1, LER2: Edge ATM LSR operating LDP and IGP (iBGP if needed)
LSR1, LSR2: ATM LSR operating LDP and IGP (OSPF or IS-IS)

OSPF or RIP is used in the IP Network and OSPF or IS-IS is deployed
in the MPLS Network. An i-BGP session could be setup between LER1 and LER2
if needed, but not necessarily since LER1 and LER2 are not supposed to provide
BGP/MPLS functionality, in other words, they don't work as a PE(Provider Edge) router.
LER1, LER2, LSR1 and LSR2 support only LDP as an MPLS signaling protocol.

The problem is that the number of LSP's from LER1 to LER2 increases
as the number of networks increases in the Network2, meaning that the number of
routing entries in LER1 increases accordingly, wherease the number of LSPs supported
by LER1 is a lot smaller than the number of its route entries.
Eventually, as the number of LSPs setup exceeds the maximum number of LSP's,
we'll not be able to setup an LSP any more even though new routes are added.
As I mentioned above, LSR1 and LSR2 don't support VC-merging capability,
thus the scalability becomes quite servere.
Therefore w're trying to figure out how to support a lot of routing entries using
a limited number of LSP's. We are trying to come up with a mechanism that setups
just one LSP between LER1 and LER2, which could be shared between all best-effort
traffic between Network1 and Networks2.

Some options to reduce the # of LSPs would be:
1. Run MPLS TE Tunnels between the edge routers and have the edge routers learn these routes through the Tunnel (but you mention only LDP distributing labels).
2. Summarize the networks on the edge routers (using your IGP).
3. As you mention, use iBGP.

Some implementations also improve scalability by allowing an edge router, by configuration, to selects FECs for which to request a label (using DoD), as well as disabling ATM LSRs from requesting labels.

Thanks,

Carlos.

The problem we faced is how to setup only 1 LSPs between LERs automatically,
and then how to map a lot of route entries to the shared LSP.
Although two LER's are shown in the example, the number of LSP's between LER's
can be quite large as the number of LER's increases.
We're considering to setup a full-mesh iBGP sessions between all LER's, and
to use BGP next hop gateway in order to get an FEC-to-NHFLE mapping.
In other words, routes from Network2 will be redistributed to LER1 via iBGP session
between LER1 and LER2, and then LER1 will setup just one LSP for the BGP next hop
address and map all routes from Network1 to the LSP.
However it enforces us to setup iBGP sessions between all of LER's even though
we don't need them unless we deploy MPLS. We're also wondering whether
we'll be able to solve the problem using any IGP capability, like tag field of AS-external
LSA in OSPF.

Please enlighten us on this issue.
Any experience or idea will be greatly appreciated.
Thanks in advance.

Regards,

Jung.

=================================================================
                            |  Carlos Pignataro - CCIE 4619
     cisco Systems, Inc.    |  Escalation RTP
                            |  cpignata@cisco.com
       ||         ||        |  +1 919 392 7428 - office
      .||.       .||.       |  +1 919 345 3028 - mobile
     .||||.     .||||.      |  +1 919 392 6470 - fax
  .:||||||||:.:||||||||:.   |  7025 Kit Creek Road, PO Box 14987
      Are you Ready ?       |  Research Triangle Park, NC 27709
================================================================= --=====================_2980645==_.ALT-- From owner-mpls@UU.NET Mon Dec 2 10:22: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 KAA18980 for ; Mon, 2 Dec 2002 10:22:36 -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 QQnrmz24803 for ; Mon, 2 Dec 2002 15:25: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 QQnrmz22004; Mon, 2 Dec 2002 15:24:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrmz02755 for mpls-outgoing; Mon, 2 Dec 2002 15:24:05 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 QQnrmz02749 for ; Mon, 2 Dec 2002 15:23:56 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 QQnrmz08928 for ; Mon, 2 Dec 2002 15:22: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 QQnrmz11406 for ; Mon, 2 Dec 2002 15:22:07 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 QQnrmz11384 for ; Mon, 2 Dec 2002 15:22: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 KAA14715 for ; Mon, 2 Dec 2002 10:22:07 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB2FM7E23415 for mpls@uu.net; Mon, 2 Dec 2002 10:22:07 -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 QQnrmz02658 for ; Mon, 2 Dec 2002 15:21:24 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 QQnrmz14269 for ; Mon, 2 Dec 2002 15:20:25 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 QQnrmz06109 for ; Mon, 2 Dec 2002 15:20:24 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 QQnrmz06098 for ; Mon, 2 Dec 2002 15:20:24 GMT Received: (qmail 25573 invoked by uid 104); 2 Dec 2002 15:20:23 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4235. . Clean. Processed in 0.646354 secs); 02 Dec 2002 15:20:23 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 2 Dec 2002 15:20:22 -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 gB2FKHQ05767; Mon, 2 Dec 2002 07:20:17 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Mon, 2 Dec 2002 07:20:16 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B19@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Carlos M. Pignataro'" , Intae Jung , mpls-ops@mplsrc.com, mpls@UU.NET Subject: RE: Regarding LDP scalability Date: Mon, 2 Dec 2002 07:20:12 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29A16.4EC58240" 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_01C29A16.4EC58240 Content-Type: text/plain Carlos, 1. Run MPLS TE Tunnels between the edge routers and have the edge routers learn these routes through the Tunnel (but you mention only LDP distributing labels). Why do we need to run TE. Can't you establish full mesh LSPs between edge routers, by running LDP DoD, only for edge router addresses. Then all prefixes could be advertised also inside these LSPs and be used by ingress LERs. Yours, -Shahram -----Original Message----- From: Carlos M. Pignataro [mailto:cpignata@cisco.com] Sent: Monday, December 02, 2002 9:52 AM To: Intae Jung; mpls-ops@mplsrc.com; mpls@UU.NET Subject: Re: Regarding LDP scalability Intae, At 12:09 AM 11/30/2002 +0900, Intae Jung wrote: Hello, I'd like to ask a couple of questions regarding a scalability of LDP, especially when it is deployed in an ATM-LSR, adopting Downstream on Demand distribution with conservative label retension and ordered control, where labels (VPI/VCI) are a relatively scarce resource that must be conserved in ATM switch. The VPI/VCI is a particularly valuable and limited resource that should be saved when an ATM LSR is not able to support VC-merging capability. Unfortunately the system I'm managing has no VC-merging capability. As defined in the standard, LDP attempts to setup or release a hop-by-hop LSP whenever a new route is added or deleted in an ATM LER through routing protocols, mainly IGP such as OSPF, ISIS or RIP. Let me assume a sample ATM-MPLS network as follows. Network1 - R1 <-> LER1 <-> LSR1 <-> LSR2 <-> LER2 <-> R2 - Network2 <---IP Network---><------------MPLS Network---------><---IP Network---> R1, R2: Router operating IGP (OSPF or RIP) LER1, LER2: Edge ATM LSR operating LDP and IGP (iBGP if needed) LSR1, LSR2: ATM LSR operating LDP and IGP (OSPF or IS-IS) OSPF or RIP is used in the IP Network and OSPF or IS-IS is deployed in the MPLS Network. An i-BGP session could be setup between LER1 and LER2 if needed, but not necessarily since LER1 and LER2 are not supposed to provide BGP/MPLS functionality, in other words, they don't work as a PE(Provider Edge) router. LER1, LER2, LSR1 and LSR2 support only LDP as an MPLS signaling protocol. The problem is that the number of LSP's from LER1 to LER2 increases as the number of networks increases in the Network2, meaning that the number of routing entries in LER1 increases accordingly, wherease the number of LSPs supported by LER1 is a lot smaller than the number of its route entries. Eventually, as the number of LSPs setup exceeds the maximum number of LSP's, we'll not be able to setup an LSP any more even though new routes are added. As I mentioned above, LSR1 and LSR2 don't support VC-merging capability, thus the scalability becomes quite servere. Therefore w're trying to figure out how to support a lot of routing entries using a limited number of LSP's. We are trying to come up with a mechanism that setups just one LSP between LER1 and LER2, which could be shared between all best-effort traffic between Network1 and Networks2. Some options to reduce the # of LSPs would be: 1. Run MPLS TE Tunnels between the edge routers and have the edge routers learn these routes through the Tunnel (but you mention only LDP distributing labels). 2. Summarize the networks on the edge routers (using your IGP). 3. As you mention, use iBGP. Some implementations also improve scalability by allowing an edge router, by configuration, to selects FECs for which to request a label (using DoD), as well as disabling ATM LSRs from requesting labels. Thanks, Carlos. The problem we faced is how to setup only 1 LSPs between LERs automatically, and then how to map a lot of route entries to the shared LSP. Although two LER's are shown in the example, the number of LSP's between LER's can be quite large as the number of LER's increases. We're considering to setup a full-mesh iBGP sessions between all LER's, and to use BGP next hop gateway in order to get an FEC-to-NHFLE mapping. In other words, routes from Network2 will be redistributed to LER1 via iBGP session between LER1 and LER2, and then LER1 will setup just one LSP for the BGP next hop address and map all routes from Network1 to the LSP. However it enforces us to setup iBGP sessions between all of LER's even though we don't need them unless we deploy MPLS. We're also wondering whether we'll be able to solve the problem using any IGP capability, like tag field of AS-external LSA in OSPF. Please enlighten us on this issue. Any experience or idea will be greatly appreciated. Thanks in advance. Regards, Jung. ================================================================= | Carlos Pignataro - CCIE 4619 cisco Systems, Inc. | Escalation RTP | cpignata@cisco.com || || | +1 919 392 7428 - office .||. .||. | +1 919 345 3028 - mobile .||||. .||||. | +1 919 392 6470 - fax .:||||||||:.:||||||||:. | 7025 Kit Creek Road, PO Box 14987 Are you Ready ? | Research Triangle Park, NC 27709 ================================================================= ------_=_NextPart_001_01C29A16.4EC58240 Content-Type: text/html
Carlos,
 
1. Run MPLS TE Tunnels between the edge routers and have the edge routers learn these routes through the Tunnel (but you mention only LDP distributing labels).
 
Why do we need to run TE. Can't you establish full mesh LSPs between edge routers, by running LDP DoD, only for edge router addresses. Then all prefixes could be advertised also inside these LSPs and
be used by ingress LERs.
 
Yours,
-Shahram 
-----Original Message-----
From: Carlos M. Pignataro [mailto:cpignata@cisco.com]
Sent: Monday, December 02, 2002 9:52 AM
To: Intae Jung; mpls-ops@mplsrc.com; mpls@UU.NET
Subject: Re: Regarding LDP scalability

Intae,


At 12:09 AM 11/30/2002 +0900, Intae Jung wrote:
Hello,
I'd like to ask a couple of questions regarding a scalability of LDP,
especially when it is deployed in an ATM-LSR, adopting Downstream on
Demand distribution with conservative label retension and ordered control,
where labels (VPI/VCI) are a relatively scarce resource that must be conserved
in ATM switch. The VPI/VCI is a particularly valuable and limited resource that
should be saved when an ATM LSR is not able to support VC-merging capability.
Unfortunately the system I'm managing has no VC-merging capability.
As defined in the standard, LDP attempts to setup or release a hop-by-hop LSP
whenever a new route is added or deleted in an ATM LER through routing protocols,
mainly IGP such as OSPF, ISIS or RIP.
Let me assume a sample ATM-MPLS network as follows.

Network1 - R1 <-> LER1 <-> LSR1 <-> LSR2 <-> LER2 <-> R2 - Network2

<---IP Network---><------------MPLS Network---------><---IP Network--->

R1, R2: Router operating IGP (OSPF or RIP)
LER1, LER2: Edge ATM LSR operating LDP and IGP (iBGP if needed)
LSR1, LSR2: ATM LSR operating LDP and IGP (OSPF or IS-IS)

OSPF or RIP is used in the IP Network and OSPF or IS-IS is deployed
in the MPLS Network. An i-BGP session could be setup between LER1 and LER2
if needed, but not necessarily since LER1 and LER2 are not supposed to provide
BGP/MPLS functionality, in other words, they don't work as a PE(Provider Edge) router.
LER1, LER2, LSR1 and LSR2 support only LDP as an MPLS signaling protocol.

The problem is that the number of LSP's from LER1 to LER2 increases
as the number of networks increases in the Network2, meaning that the number of
routing entries in LER1 increases accordingly, wherease the number of LSPs supported
by LER1 is a lot smaller than the number of its route entries.
Eventually, as the number of LSPs setup exceeds the maximum number of LSP's,
we'll not be able to setup an LSP any more even though new routes are added.
As I mentioned above, LSR1 and LSR2 don't support VC-merging capability,
thus the scalability becomes quite servere.
Therefore w're trying to figure out how to support a lot of routing entries using
a limited number of LSP's. We are trying to come up with a mechanism that setups
just one LSP between LER1 and LER2, which could be shared between all best-effort
traffic between Network1 and Networks2.

Some options to reduce the # of LSPs would be:
1. Run MPLS TE Tunnels between the edge routers and have the edge routers learn these routes through the Tunnel (but you mention only LDP distributing labels).
2. Summarize the networks on the edge routers (using your IGP).
3. As you mention, use iBGP.

Some implementations also improve scalability by allowing an edge router, by configuration, to selects FECs for which to request a label (using DoD), as well as disabling ATM LSRs from requesting labels.

Thanks,

Carlos.

The problem we faced is how to setup only 1 LSPs between LERs automatically,
and then how to map a lot of route entries to the shared LSP.
Although two LER's are shown in the example, the number of LSP's between LER's
can be quite large as the number of LER's increases.
We're considering to setup a full-mesh iBGP sessions between all LER's, and
to use BGP next hop gateway in order to get an FEC-to-NHFLE mapping.
In other words, routes from Network2 will be redistributed to LER1 via iBGP session
between LER1 and LER2, and then LER1 will setup just one LSP for the BGP next hop
address and map all routes from Network1 to the LSP.
However it enforces us to setup iBGP sessions between all of LER's even though
we don't need them unless we deploy MPLS. We're also wondering whether
we'll be able to solve the problem using any IGP capability, like tag field of AS-external
LSA in OSPF.

Please enlighten us on this issue.
Any experience or idea will be greatly appreciated.
Thanks in advance.

Regards,

Jung.

=================================================================
                            |  Carlos Pignataro - CCIE 4619
     cisco Systems, Inc.    |  Escalation RTP
                            |  cpignata@cisco.com
       ||         ||        |  +1 919 392 7428 - office
      .||.       .||.       |  +1 919 345 3028 - mobile
     .||||.     .||||.      |  +1 919 392 6470 - fax
  .:||||||||:.:||||||||:.   |  7025 Kit Creek Road, PO Box 14987
      Are you Ready ?       |  Research Triangle Park, NC 27709
=================================================================
------_=_NextPart_001_01C29A16.4EC58240-- From owner-mpls@UU.NET Mon Dec 2 10:45:08 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 KAA20541 for ; Mon, 2 Dec 2002 10:45:08 -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 QQnrnb05389 for ; Mon, 2 Dec 2002 15:47: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 QQnrnb02376; Mon, 2 Dec 2002 15:46:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrnb04767 for mpls-outgoing; Mon, 2 Dec 2002 15:45:40 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 QQnrnb04762 for ; Mon, 2 Dec 2002 15:45: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 QQnrnb13084 for ; Mon, 2 Dec 2002 15:45: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 QQnrnb17649 for ; Mon, 2 Dec 2002 15:45:18 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 QQnrnb17633 for ; Mon, 2 Dec 2002 15:45: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 KAA16494 for ; Mon, 2 Dec 2002 10:45:17 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB2FjHD27800 for mpls@uu.net; Mon, 2 Dec 2002 10:45:17 -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 QQnrna04381 for ; Mon, 2 Dec 2002 15:43:33 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 QQnrna24861 for ; Mon, 2 Dec 2002 15:43:06 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 QQnrna05072 for ; Mon, 2 Dec 2002 15:43:05 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 QQnrna05064 for ; Mon, 2 Dec 2002 15:43:05 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 gB2FhCZg017943; Mon, 2 Dec 2002 10:43:12 -0500 (EST) Received: from tnadeau-w2k.cisco.com (che-vpn-cluster-2-48.cisco.com [10.86.242.48]) by bucket.cisco.com (Mirapoint) with ESMTP id ACE87359; Mon, 2 Dec 2002 10:42:44 -0500 (EST) Message-Id: <5.2.0.9.2.20021202104001.035346c8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 02 Dec 2002 10:42:37 -0500 To: Edward Harrison From: "Thomas D. Nadeau" Subject: RE: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt Cc: , Parama - Cheenu Srinivasan , "'arun@force10networks.com'" , "'hans@ipunplugged.com'" , mpls@UU.NET In-Reply-To: <53F74F5A7B94D511841C00B0D0AB16F80109CAED@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 >I notice that the latest MPLS TE and TC MIBs still have resource affinities >specified as "Exclude-all" rather than "Exclude-any". Is this another >oversight, or did the authors decide that "Exclude-all" was preferred? Oversight. I think that you were supposed to remind us about this during the last round of edits. *) >One other minor thing I've noticed: > >- The mplsTunnelOwner field is now read-only. However, the comment talks >about not being able to modify the object if mplsTunnelRowStatus is active. >Surely one can't modify the object at all if it is read-only? This was discussed during the meeting, and as I recall the conclusion was that the object's access was okay as it as it is given that the text has to state that the agent MUST set the value to the correct value. Why would you want to change this after the object/row is created? >[Also, the >example in section 9 includes mplsTunnelOwner - I guess this should not be >present (and in any case, the given value is no longer correct given the >latest definition of the MplsOwner TC)]. Okay. --Tom >Regards, > >Ed > >-----Original Message----- >From: Cisco - Thomas Nadeau >Sent: 15 October 2002 15:22 >To: Edward Harrison >Cc: 'jcucchiara@crescentnetworks.com'; Parama - Cheenu Srinivasan; >'arun@force10networks.com'; 'hans@ipunplugged.com'; mpls@UU.NET >Subject: RE: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt > > > > >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 Mon Dec 2 10:55: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 KAA21262 for ; Mon, 2 Dec 2002 10:55:52 -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 QQnrnb01938 for ; Mon, 2 Dec 2002 15:57: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 QQnrnb27695; Mon, 2 Dec 2002 15:55:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrnb05764 for mpls-outgoing; Mon, 2 Dec 2002 15:55:30 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 QQnrnb05759 for ; Mon, 2 Dec 2002 15:55:28 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 QQnrnb00826 for ; Mon, 2 Dec 2002 15:54: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 QQnrnb26739 for ; Mon, 2 Dec 2002 15:54:39 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 QQnrnb26732 for ; Mon, 2 Dec 2002 15:54: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 KAA17249 for ; Mon, 2 Dec 2002 10:54:38 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB2FscR00184 for mpls@uu.net; Mon, 2 Dec 2002 10:54:38 -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 QQnrnb05607 for ; Mon, 2 Dec 2002 15:52: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 QQnrnb29785 for ; Mon, 2 Dec 2002 15:51:51 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 QQnrnb12648 for ; Mon, 2 Dec 2002 15:51:50 GMT Received: from rooster.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hen.cisco.com [64.102.19.198]) id QQnrnb12555 for ; Mon, 2 Dec 2002 15:51:47 GMT Received: from CPIGNATA-W2K.cisco.com (dhcp-64-102-52-173.cisco.com [64.102.52.173]) by rooster.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id gB2FpX020605; Mon, 2 Dec 2002 10:51:33 -0500 (EST) Message-Id: <4.3.2.7.2.20021202102529.01ade040@rooster> X-Sender: cpignata@rooster X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 02 Dec 2002 10:51:32 -0500 To: Shahram Davari , Intae Jung , mpls-ops@mplsrc.com, mpls@UU.NET From: "Carlos M. Pignataro" Subject: RE: Regarding LDP scalability In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03B19@nt-exch-yow.pmc-sie rra.bc.ca> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_6499656==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_6499656==_.ALT Content-Type: text/plain; charset="us-ascii" Shahram, At 07:20 AM 12/2/2002 -0800, Shahram Davari wrote: >Carlos, > >1. Run MPLS TE Tunnels between the edge routers and have the edge routers learn these routes through the Tunnel (but you mention only LDP distributing labels). > >Why do we need to run TE. Can't you establish full mesh LSPs between edge routers, by running LDP DoD, only for edge router addresses. Normally, in a non-vc-merge environment, an LER will request labels (LDP DoD) for all entries in its routing table. Even if the next hop is the same, different LSPs will be signalled. That's why option 2 summarize the IGP. >Then all prefixes could be advertised also inside these LSPs and >be used by ingress LERs. How would we do that. An LDP signaled LSP is for a particular FEC. (FEC-Label mapping). New prefix -> new LSP. Check RCF 3031 section 5.1.1.4. PulledConditional and RFC 3035 section 8.1. Edge LSR Behavior. If LDP signals LSPs for only the edge router addresses, all other prefixes will not use that LSP. Regards, Carlos. > >Yours, >-Shahram >>-----Original Message----- >>From: Carlos M. Pignataro [mailto:cpignata@cisco.com] >>Sent: Monday, December 02, 2002 9:52 AM >>To: Intae Jung; mpls-ops@mplsrc.com; mpls@UU.NET >>Subject: Re: Regarding LDP scalability >> >>Intae, >> >> >>At 12:09 AM 11/30/2002 +0900, Intae Jung wrote: >>>Hello, >>>I'd like to ask a couple of questions regarding a scalability of LDP, >>>especially when it is deployed in an ATM-LSR, adopting Downstream on >>>Demand distribution with conservative label retension and ordered control, >>>where labels (VPI/VCI) are a relatively scarce resource that must be conserved >>>in ATM switch. The VPI/VCI is a particularly valuable and limited resource that >>>should be saved when an ATM LSR is not able to support VC-merging capability. >>>Unfortunately the system I'm managing has no VC-merging capability. >>>As defined in the standard, LDP attempts to setup or release a hop-by-hop LSP >>>whenever a new route is added or deleted in an ATM LER through routing protocols, >>>mainly IGP such as OSPF, ISIS or RIP. >>>Let me assume a sample ATM-MPLS network as follows. >>> >>>Network1 - R1 <-> LER1 <-> LSR1 <-> LSR2 <-> LER2 <-> R2 - Network2 >>> >>><---IP Network---><------------MPLS Network---------><---IP Network---> >>> >>>R1, R2: Router operating IGP (OSPF or RIP) >>>LER1, LER2: Edge ATM LSR operating LDP and IGP (iBGP if needed) >>>LSR1, LSR2: ATM LSR operating LDP and IGP (OSPF or IS-IS) >>> >>>OSPF or RIP is used in the IP Network and OSPF or IS-IS is deployed >>>in the MPLS Network. An i-BGP session could be setup between LER1 and LER2 >>>if needed, but not necessarily since LER1 and LER2 are not supposed to provide >>>BGP/MPLS functionality, in other words, they don't work as a PE(Provider Edge) router. >>>LER1, LER2, LSR1 and LSR2 support only LDP as an MPLS signaling protocol. >>> >>>The problem is that the number of LSP's from LER1 to LER2 increases >>>as the number of networks increases in the Network2, meaning that the number of >>>routing entries in LER1 increases accordingly, wherease the number of LSPs supported >>>by LER1 is a lot smaller than the number of its route entries. >>>Eventually, as the number of LSPs setup exceeds the maximum number of LSP's, >>>we'll not be able to setup an LSP any more even though new routes are added. >>>As I mentioned above, LSR1 and LSR2 don't support VC-merging capability, >>>thus the scalability becomes quite servere. >>>Therefore w're trying to figure out how to support a lot of routing entries using >>>a limited number of LSP's. We are trying to come up with a mechanism that setups >>>just one LSP between LER1 and LER2, which could be shared between all best-effort >>>traffic between Network1 and Networks2. >> >>Some options to reduce the # of LSPs would be: >>1. Run MPLS TE Tunnels between the edge routers and have the edge routers learn these routes through the Tunnel (but you mention only LDP distributing labels). >>2. Summarize the networks on the edge routers (using your IGP). >>3. As you mention, use iBGP. >> >>Some implementations also improve scalability by allowing an edge router, by configuration, to selects FECs for which to request a label (using DoD), as well as disabling ATM LSRs from requesting labels. >> >>Thanks, >> >>Carlos. >> >>>The problem we faced is how to setup only 1 LSPs between LERs automatically, >>>and then how to map a lot of route entries to the shared LSP. >>>Although two LER's are shown in the example, the number of LSP's between LER's >>>can be quite large as the number of LER's increases. >>>We're considering to setup a full-mesh iBGP sessions between all LER's, and >>>to use BGP next hop gateway in order to get an FEC-to-NHFLE mapping. >>>In other words, routes from Network2 will be redistributed to LER1 via iBGP session >>>between LER1 and LER2, and then LER1 will setup just one LSP for the BGP next hop >>>address and map all routes from Network1 to the LSP. >>>However it enforces us to setup iBGP sessions between all of LER's even though >>>we don't need them unless we deploy MPLS. We're also wondering whether >>>we'll be able to solve the problem using any IGP capability, like tag field of AS-external >>>LSA in OSPF. >>> >>>Please enlighten us on this issue. >>>Any experience or idea will be greatly appreciated. >>>Thanks in advance. >>> >>>Regards, >>> >>>Jung. >> >>================================================================= >> | Carlos Pignataro - CCIE 4619 >> cisco Systems, Inc. | Escalation RTP >> | cpignata@cisco.com >> || || | +1 919 392 7428 - office >> .||. .||. | +1 919 345 3028 - mobile >> .||||. .||||. | +1 919 392 6470 - fax >> .:||||||||:.:||||||||:. | 7025 Kit Creek Road, PO Box 14987 >> Are you Ready ? | Research Triangle Park, NC 27709 >>================================================================= ================================================================= | Carlos Pignataro - CCIE 4619 cisco Systems, Inc. | Escalation RTP | cpignata@cisco.com || || | +1 919 392 7428 - office .||. .||. | +1 919 345 3028 - mobile .||||. .||||. | +1 919 392 6470 - fax .:||||||||:.:||||||||:. | 7025 Kit Creek Road, PO Box 14987 Are you Ready ? | Research Triangle Park, NC 27709 ================================================================= --=====================_6499656==_.ALT Content-Type: text/html; charset="us-ascii" Shahram,

At 07:20 AM 12/2/2002 -0800, Shahram Davari wrote:
Carlos,
 
1. Run MPLS TE Tunnels between the edge routers and have the edge routers learn these routes through the Tunnel (but you mention only LDP distributing labels).
 
Why do we need to run TE. Can't you establish full mesh LSPs between edge routers, by running LDP DoD, only for edge router addresses.

Normally, in a non-vc-merge environment, an LER will request labels (LDP DoD) for all entries in its routing table. Even if the next hop is the same, different LSPs will be signalled. That's why option 2 summarize the IGP.

Then all prefixes could be advertised also inside these LSPs and
be used by ingress LERs.

How would we do that. An LDP signaled LSP is for a particular FEC. (FEC-Label mapping). New prefix -> new LSP. Check RCF 3031 section 5.1.1.4. PulledConditional and RFC 3035 section 8.1. Edge LSR Behavior.
If LDP signals LSPs for only the edge router addresses, all other prefixes will not use that LSP.

Regards,

Carlos.

 
Yours,
-Shahram
-----Original Message-----
From: Carlos M. Pignataro [mailto:cpignata@cisco.com]
Sent: Monday, December 02, 2002 9:52 AM
To: Intae Jung; mpls-ops@mplsrc.com; mpls@UU.NET
Subject: Re: Regarding LDP scalability

Intae,


At 12:09 AM 11/30/2002 +0900, Intae Jung wrote:
Hello,
I'd like to ask a couple of questions regarding a scalability of LDP,
especially when it is deployed in an ATM-LSR, adopting Downstream on
Demand distribution with conservative label retension and ordered control,
where labels (VPI/VCI) are a relatively scarce resource that must be conserved
in ATM switch. The VPI/VCI is a particularly valuable and limited resource that
should be saved when an ATM LSR is not able to support VC-merging capability.
Unfortunately the system I'm managing has no VC-merging capability.
As defined in the standard, LDP attempts to setup or release a hop-by-hop LSP
whenever a new route is added or deleted in an ATM LER through routing protocols,
mainly IGP such as OSPF, ISIS or RIP.
Let me assume a sample ATM-MPLS network as follows.

Network1 - R1 <-> LER1 <-> LSR1 <-> LSR2 <-> LER2 <-> R2 - Network2

<---IP Network---><------------MPLS Network---------><---IP Network--->

R1, R2: Router operating IGP (OSPF or RIP)
LER1, LER2: Edge ATM LSR operating LDP and IGP (iBGP if needed)
LSR1, LSR2: ATM LSR operating LDP and IGP (OSPF or IS-IS)

OSPF or RIP is used in the IP Network and OSPF or IS-IS is deployed
in the MPLS Network. An i-BGP session could be setup between LER1 and LER2
if needed, but not necessarily since LER1 and LER2 are not supposed to provide
BGP/MPLS functionality, in other words, they don't work as a PE(Provider Edge) router.
LER1, LER2, LSR1 and LSR2 support only LDP as an MPLS signaling protocol.

The problem is that the number of LSP's from LER1 to LER2 increases
as the number of networks increases in the Network2, meaning that the number of
routing entries in LER1 increases accordingly, wherease the number of LSPs supported
by LER1 is a lot smaller than the number of its route entries.
Eventually, as the number of LSPs setup exceeds the maximum number of LSP's,
we'll not be able to setup an LSP any more even though new routes are added.
As I mentioned above, LSR1 and LSR2 don't support VC-merging capability,
thus the scalability becomes quite servere.
Therefore w're trying to figure out how to support a lot of routing entries using
a limited number of LSP's. We are trying to come up with a mechanism that setups
just one LSP between LER1 and LER2, which could be shared between all best-effort
traffic between Network1 and Networks2.

Some options to reduce the # of LSPs would be:
1. Run MPLS TE Tunnels between the edge routers and have the edge routers learn these routes through the Tunnel (but you mention only LDP distributing labels).
2. Summarize the networks on the edge routers (using your IGP).
3. As you mention, use iBGP.

Some implementations also improve scalability by allowing an edge router, by configuration, to selects FECs for which to request a label (using DoD), as well as disabling ATM LSRs from requesting labels.

Thanks,

Carlos.

The problem we faced is how to setup only 1 LSPs between LERs automatically,
and then how to map a lot of route entries to the shared LSP.
Although two LER's are shown in the example, the number of LSP's between LER's
can be quite large as the number of LER's increases.
We're considering to setup a full-mesh iBGP sessions between all LER's, and
to use BGP next hop gateway in order to get an FEC-to-NHFLE mapping.
In other words, routes from Network2 will be redistributed to LER1 via iBGP session
between LER1 and LER2, and then LER1 will setup just one LSP for the BGP next hop
address and map all routes from Network1 to the LSP.
However it enforces us to setup iBGP sessions between all of LER's even though
we don't need them unless we deploy MPLS. We're also wondering whether
we'll be able to solve the problem using any IGP capability, like tag field of AS-external
LSA in OSPF.

Please enlighten us on this issue.
Any experience or idea will be greatly appreciated.
Thanks in advance.

Regards,

Jung.

=================================================================
                            |  Carlos Pignataro - CCIE 4619
     cisco Systems, Inc.    |  Escalation RTP
                            |  cpignata@cisco.com
       ||         ||        |  +1 919 392 7428 - office
      .||.       .||.       |  +1 919 345 3028 - mobile
     .||||.     .||||.      |  +1 919 392 6470 - fax
  .:||||||||:.:||||||||:.   |  7025 Kit Creek Road, PO Box 14987
      Are you Ready ?       |  Research Triangle Park, NC 27709
=================================================================

=================================================================
                            |  Carlos Pignataro - CCIE 4619
     cisco Systems, Inc.    |  Escalation RTP
                            |  cpignata@cisco.com
       ||         ||        |  +1 919 392 7428 - office
      .||.       .||.       |  +1 919 345 3028 - mobile
     .||||.     .||||.      |  +1 919 392 6470 - fax
  .:||||||||:.:||||||||:.   |  7025 Kit Creek Road, PO Box 14987
      Are you Ready ?       |  Research Triangle Park, NC 27709
================================================================= --=====================_6499656==_.ALT-- From owner-mpls@UU.NET Mon Dec 2 11:38:00 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 LAA24801 for ; Mon, 2 Dec 2002 11:38:00 -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 QQnrne15019 for ; Mon, 2 Dec 2002 16:40: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 QQnrne12085; Mon, 2 Dec 2002 16:39:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrne27793 for mpls-outgoing; Mon, 2 Dec 2002 16:38: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 QQnrne27780 for ; Mon, 2 Dec 2002 16:38:37 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 QQnrne12780 for ; Mon, 2 Dec 2002 16:38:07 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 QQnrne11343 for ; Mon, 2 Dec 2002 16:38: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 QQnrne11332 for ; Mon, 2 Dec 2002 16:38:06 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 LAA21087 for ; Mon, 2 Dec 2002 11:38:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB2Gc6K04061 for mpls@uu.net; Mon, 2 Dec 2002 11:38:06 -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 QQnrne27744 for ; Mon, 2 Dec 2002 16:37:25 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 QQnrne19909 for ; Mon, 2 Dec 2002 16:35: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 QQnrne07428 for ; Mon, 2 Dec 2002 16:35:39 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 QQnrne07423 for ; Mon, 2 Dec 2002 16:35:38 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 gB2Ga3n6027310; Mon, 2 Dec 2002 11:36:03 -0500 (EST) Received: from tnadeau-w2k.cisco.com (che-vpn-cluster-2-48.cisco.com [10.86.242.48]) by bucket.cisco.com (Mirapoint) with ESMTP id ACE88646; Mon, 2 Dec 2002 11:35:35 -0500 (EST) Message-Id: <5.2.0.9.2.20021202113343.0362e930@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 02 Dec 2002 11:35:32 -0500 To: "Adrian Farrel" From: "Thomas D. Nadeau" Subject: Re: review of mpls-mgmt-overview revision 02 Cc: "Wijnen, Bert \(Bert\)" , "Mpls \(E-mail\)" In-Reply-To: <000d01c2981e$a4855ec0$ef13588a@movaz.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 10:14 PM 11/29/2002 -0500, Adrian Farrel wrote: >Bert, >Thanks. All nits are most welcome. I, for one, welcome your efforts to get >RFCs >in clear and correct English. > >A couple of follow-up questions/comments in the snipped text below... > >Cheers, >Adrian >----- Original Message ----- >From: "Wijnen, Bert (Bert)" > > > > A lot of it is indeed nits/spelling/grammar > > stuff... do I have to repat that for all docs, or can I assume > > that the authors/editors will seriously check those things > > themselves? > >Hmmm. I know what you SHOULD be able to asume... > > > - I see you use mib module names with an underscore, for example > > MPLS-LDP_MIB, but the real module name is MPLS-LDP-MIB > > Better get that in sync. True for most mib module names I believe > >Ah! I made this global change after I thought I heard Tom suggest that you >said >that the use of underscore was a requirement. At least one of us is out of >synch >here - I will change back to hyphen. Shouldn't it be written as MPLS-LDP MIB when referring to the actual MIB and not the SMI MODULE-NAME macro? > > - Make descriptors consistent. Like > > - mplsLdpEntityFrameRelayXxxxx > > - mplsLdpEntityConfFrXxxx > > so either make all freme-relay stuff xxxFrameRelayYyy or xxxFrYyy > > but do not mix all that. I also wonder why in some case > > Fr comes before the Xxxx and in other cases after it. > > - mplsLdpEntityFrameRelayXxxxx > > - mplsLdpEntityConfFrXxxx > > why not mplsLdpEntityFrameRelayConfXxxx > > Are mplsTunnelResourceTable and mplsTunnelCRDLPResTable both "resource" > > tables? If so, then why not use "Resource" in both cases, or just "Res" > > in both cases? Consistency please!!!!! > > So Tunnel Computed Hop Table is: mplsTunnelCHopTable > > and Tunnel Actual Hop Table is: mplsTunnelARHopTable > > is the R for Route? If so then add Route in there > >Agreed. This draft, however, can only report what is in the MIB modules >themselves. > >Tom and Joan - relying on you to pick up these things and then I'll change the >overview to match. > > > Question: Is there also a mplsTunnelRSVPResTable? If yes, then I am > > missing it here, if no, then why is that not needed? > >Good question. >No there is no RSVP resource table. CR-LDP resource specification is a >superset >of RSVP resource specification. >I will add a note explaining. > > > - sect 7.2 > > ".. mplsTunnelMaxHops defines the size of route that may be configured > > on the LSR." > > I have difficulty understanding what that means. > > What is the "size of route"? > >Syntax is "size of route that", but I agree that this could be clearer. > > > - Your references to PWE3 and PPVPN WG docs are listed as normative. > > I doubt that they really are. In any event, if they are normative, > > then they will have to be ready for RFC at the same time that this > > doc goes to RFC. > >You're right. Old reference from when we thought we were going to include them >in detail. > > > - Your split of references for the SNMP boilerplate text is not > > correct. The correct split is: >[SNIP] > > - We're working on the new MIB boilerplate. Much shorter. Not 100% stable > > yet. If you prefer to use it (I assume the new boiler plate will be > > stable by the time you go to RFC-Editor queue), then I can send you what > > the curretn text looks like. > >I will wait as late as I can and then include the most up-to-date version. >But... >Do you consider that the boilerplate is appropriate for inclusion in this >overview or should I aim to hack it down? Actually, if the new material is >shorter, perhaps it will be fine. I think that we had agreed during the meeting that we would not wait for the updated boiler plate giving the timing issues. --Tom From owner-mpls@UU.NET Mon Dec 2 12:00: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 MAA26000 for ; Mon, 2 Dec 2002 12:00:17 -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 QQnrng08637 for ; Mon, 2 Dec 2002 17:02:56 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 QQnrng06799; Mon, 2 Dec 2002 17:02:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrng06032 for mpls-outgoing; Mon, 2 Dec 2002 17:01:44 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 QQnrng05974 for ; Mon, 2 Dec 2002 17:01:40 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 QQnrng15306 for ; Mon, 2 Dec 2002 17:01:33 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 QQnrng06194 for ; Mon, 2 Dec 2002 17:01:33 GMT Received: from ariadne.dt.fee.unicamp.br by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ariadne.dt.fee.unicamp.br [143.106.12.20]) id QQnrng06179 for ; Mon, 2 Dec 2002 17:01:32 GMT Received: from calipso.dt.fee.unicamp.br (calipso.dt.fee.unicamp.br [143.106.12.37]) by ariadne.dt.fee.unicamp.br (8.9.3/8.9.3) with ESMTP id OAA14906; Mon, 2 Dec 2002 14:48:26 -0200 (EDT) Date: Mon, 2 Dec 2002 15:00:34 -0200 (EDT) From: Marcos Antonio De Almeida Cora To: mpls@UU.NET, mpls-ops@mplsrc.com, ccamp@ops.ietf.org Subject: Upstream Labels in GMPLS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8BIT Hi, I have some doubts on Upstream Labels in GMPLS. First, GMPLS supports both "unidirectional LSPs" and "bidirectional LSPs" ??? I would like to know if when a initiator node send a request message (Path/RSVP or Label Request/CR-LDP) with a Upstream Label, and this label is not suitable for use at the next LSR, it must reject the request message and send a "Error message" to the initiator node. In this case, the Error message may include an acceptable Label Set to tell the Upstream LSR wich labels would have been succeful. But if Upstream LSR decide to fail the LSP set up, my doubt is: The unidirectional LSP will set up and just the bidirectional LSP not is set up ?? or both uniderectional and bidirectional will fail, and LSR initiator will try again ?? Thanks, Marcos _________________________________________________________________ Marcos Antônio de Almeida Corá School of Electrical and Computer Engineering Departament of Telematics State University of Campinas/Brazil - UNICAMP Phone: +55 (19) 3788.3711 - Branch: 73723 Home Page: www.dt.fee.unicamp.br/~cora _________________________________________________________________ From owner-mpls@UU.NET Mon Dec 2 12:05:02 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 MAA26191 for ; Mon, 2 Dec 2002 12:05:02 -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 QQnrng25520 for ; Mon, 2 Dec 2002 17:07: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 QQnrng22894; Mon, 2 Dec 2002 17:06:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrng18239 for mpls-outgoing; Mon, 2 Dec 2002 17:06: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 QQnrng18164 for ; Mon, 2 Dec 2002 17:06:03 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 QQnrng18937 for ; Mon, 2 Dec 2002 17:05: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 QQnrng11485 for ; Mon, 2 Dec 2002 17:05:21 GMT Received: from atlntex01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: exchange.movaz.com [65.205.166.141]) id QQnrng11475 for ; Mon, 2 Dec 2002 17:05:20 GMT Received: from BLIULAPTOP ([172.16.24.104]) by atlntex01.movaz.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 2 Dec 2002 12:05:20 -0500 Message-ID: <008c01c29a24$fedece30$681810ac@movaz.com> From: "Adrian Farrel" To: "Thomas D. Nadeau" , "Wijnen, Bert \(Bert\)" Cc: "Mpls \(E-mail\)" References: <5.2.0.9.2.20021202113343.0362e930@bucket.cisco.com> Subject: Re: review of mpls-mgmt-overview revision 02 Date: Mon, 2 Dec 2002 12:05:20 -0500 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: 02 Dec 2002 17:05:20.0341 (UTC) FILETIME=[FEC1D050:01C29A24] Sender: owner-mpls@UU.NET Precedence: bulk Aaagh! Let's try to get this straight. There is only one MIB. There is a series of MIB documents, such as MPLS-TE MIB. Each MIB document describes one or more MIB modules, such as MPLS-TE-MIB. Is that agreed? Adrian (Sorry if I am stating the obvious, but I'd rather only make the change once!) > > > - I see you use mib module names with an underscore, for example > > > MPLS-LDP_MIB, but the real module name is MPLS-LDP-MIB > > > Better get that in sync. True for most mib module names I believe > > > >Ah! I made this global change after I thought I heard Tom suggest that you > >said > >that the use of underscore was a requirement. At least one of us is out of > >synch > >here - I will change back to hyphen. > > Shouldn't it be written as MPLS-LDP MIB when referring to the actual > MIB and not the SMI MODULE-NAME macro? > From owner-mpls@UU.NET Mon Dec 2 13:09: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 NAA00026 for ; Mon, 2 Dec 2002 13:09: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 QQnrnk21838 for ; Mon, 2 Dec 2002 18:12: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 QQnrnk19603; Mon, 2 Dec 2002 18:11:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrnk12276 for mpls-outgoing; Mon, 2 Dec 2002 18:10: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 QQnrnk12226 for ; Mon, 2 Dec 2002 18:10:42 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 QQnrnk29788 for ; Mon, 2 Dec 2002 18:10:39 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 QQnrnk19041 for ; Mon, 2 Dec 2002 18:10:38 GMT Received: from hoemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQnrnk19032 for ; Mon, 2 Dec 2002 18:10:38 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 gB2IAaW01468 for ; Mon, 2 Dec 2002 13:10:37 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Dec 2002 19:10:33 +0100 Message-ID: From: "Wijnen, Bert (Bert)" To: Adrian Farrel , "Thomas D. Nadeau" , "Wijnen, Bert (Bert)" Cc: "Mpls (E-mail)" Subject: RE: review of mpls-mgmt-overview revision 02 Date: Mon, 2 Dec 2002 19:10:33 +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 > Aaagh! > > Let's try to get this straight. > > There is only one MIB. > There is a series of MIB documents, such as MPLS-TE MIB. Add "document" at the end > Each MIB document describes one or more MIB modules, such as > MPLS-TE-MIB. > > Is that agreed? > Yep. See also below > Adrian > (Sorry if I am stating the obvious, but I'd rather only make > the change once!) > > > > > - I see you use mib module names with an underscore, for example > > > > MPLS-LDP_MIB, but the real module name is MPLS-LDP-MIB > > > > Better get that in sync. True for most mib module names I believe > > > > > >Ah! I made this global change after I thought I heard Tom suggest that you > > >said > > >that the use of underscore was a requirement. At least one of us is out of > > >synch here - I will change back to hyphen. > > > > Shouldn't it be written as MPLS-LDP MIB when referring to the actual > > MIB and not the SMI MODULE-NAME macro? > > That would be fine with me too. But the underscore seemed to show the MIB module name (incorrectly). Bert From owner-mpls@UU.NET Mon Dec 2 13:10: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 NAA00114 for ; Mon, 2 Dec 2002 13:10: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 QQnrnk24752 for ; Mon, 2 Dec 2002 18:13:29 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 QQnrnk20110; Mon, 2 Dec 2002 18:11:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrnk12423 for mpls-outgoing; Mon, 2 Dec 2002 18:10:54 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 QQnrnk12227 for ; Mon, 2 Dec 2002 18:10:42 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 QQnrnk29688 for ; Mon, 2 Dec 2002 18:10: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 QQnrnk18996 for ; Mon, 2 Dec 2002 18:10:37 GMT Received: from hoemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQnrnk18982 for ; Mon, 2 Dec 2002 18:10:36 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 gB2IAYW01446 for ; Mon, 2 Dec 2002 13:10:35 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Dec 2002 19:10:33 +0100 Message-ID: From: "Wijnen, Bert (Bert)" To: "Thomas D. Nadeau" , Adrian Farrel Cc: "Wijnen, Bert (Bert)" , "Mpls (E-mail)" Subject: RE: review of mpls-mgmt-overview revision 02 Date: Mon, 2 Dec 2002 19:10:33 +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 > > > - Your split of references for the SNMP boilerplate text is not > > > correct. The correct split is: > >[SNIP] > > > - We're working on the new MIB boilerplate. Much shorter. > > > Not 100% stable yet. If you prefer to use it (I assume the > > > new boiler plate will be stable by the time you go to > > > RFC-Editor queue), then I can send you what > > > the current text looks like. > > > >I will wait as late as I can and then include the most up-to-date version. > >But... Do you consider that the boilerplate is appropriate for > >inclusion in this overview or should I aim to hack it down? Actually, > >if the new material is shorter, perhaps it will be fine. > > I think that we had agreed during the meeting that we would not > wait for the updated boiler plate giving the timing issues. > As I said, it is up to you. We may end up having to do the boilerplate change in 48-hour author-call I expect/hope to have a stable new boiler plate in a week (or two) and if you can still include it, I think it would be good. Again, up to you Bert > --Tom From owner-mpls@UU.NET Mon Dec 2 13:25:36 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 NAA00961 for ; Mon, 2 Dec 2002 13:25:36 -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 QQnrnl03050 for ; Mon, 2 Dec 2002 18:27: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 QQnrnl29228; Mon, 2 Dec 2002 18:25:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrnl13952 for mpls-outgoing; Mon, 2 Dec 2002 18:25: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 QQnrnl13947 for ; Mon, 2 Dec 2002 18:25: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 QQnrnl05279 for ; Mon, 2 Dec 2002 18: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 QQnrnl27850 for ; Mon, 2 Dec 2002 18:24:06 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 QQnrnl27841 for ; Mon, 2 Dec 2002 18:24:06 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 NAA29461 for ; Mon, 2 Dec 2002 13:24:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB2IO6N13502 for mpls@uu.net; Mon, 2 Dec 2002 13:24:06 -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 QQnrnl13901 for ; Mon, 2 Dec 2002 18:23: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 QQnrnl28015 for ; Mon, 2 Dec 2002 18:21:39 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 QQnrnl07892 for ; Mon, 2 Dec 2002 18:21:39 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 QQnrnl07872 for ; Mon, 2 Dec 2002 18:21:39 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 gB2IM3xX010527; Mon, 2 Dec 2002 13:22:04 -0500 (EST) Received: from tnadeau-w2k.cisco.com (che-vpn-cluster-2-48.cisco.com [10.86.242.48]) by bucket.cisco.com (Mirapoint) with ESMTP id ACE90845; Mon, 2 Dec 2002 13:21:35 -0500 (EST) Message-Id: <5.2.0.9.2.20021202132052.036b5a90@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 02 Dec 2002 13:21:32 -0500 To: "Adrian Farrel" From: "Thomas D. Nadeau" Subject: Re: review of mpls-mgmt-overview revision 02 Cc: "Wijnen, Bert \(Bert\)" , "Mpls \(E-mail\)" In-Reply-To: <008c01c29a24$fedece30$681810ac@movaz.com> References: <5.2.0.9.2.20021202113343.0362e930@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 12:05 PM 12/2/2002 -0500, Adrian Farrel wrote: >Aaagh! > >Let's try to get this straight. > >There is only one MIB. >There is a series of MIB documents, such as MPLS-TE MIB. >Each MIB document describes one or more MIB modules, such as MPLS-TE-MIB. > >Is that agreed? That jives with my understanding. --Tom >Adrian >(Sorry if I am stating the obvious, but I'd rather only make the change once!) > > > > > - I see you use mib module names with an underscore, for example > > > > MPLS-LDP_MIB, but the real module name is MPLS-LDP-MIB > > > > Better get that in sync. True for most mib module names I believe > > > > > >Ah! I made this global change after I thought I heard Tom suggest that you > > >said > > >that the use of underscore was a requirement. At least one of us is out of > > >synch > > >here - I will change back to hyphen. > > > > Shouldn't it be written as MPLS-LDP MIB when referring to the > actual > > MIB and not the SMI MODULE-NAME macro? > > From owner-mpls@UU.NET Mon Dec 2 14:08:49 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 OAA04345 for ; Mon, 2 Dec 2002 14:08:49 -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 QQnrno25764 for ; Mon, 2 Dec 2002 19:11: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 QQnrno23054; Mon, 2 Dec 2002 19:10:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrno05661 for mpls-outgoing; Mon, 2 Dec 2002 19:09: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 QQnrno05626 for ; Mon, 2 Dec 2002 19:09:39 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 QQnrno09486 for ; Mon, 2 Dec 2002 19:09:06 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 QQnrno14346 for ; Mon, 2 Dec 2002 19:09:06 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 QQnrno14336 for ; Mon, 2 Dec 2002 19:09: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 OAA03762 for ; Mon, 2 Dec 2002 14:09:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB2J95817834 for mpls@uu.net; Mon, 2 Dec 2002 14:09:05 -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 QQnrno05454 for ; Mon, 2 Dec 2002 19:08:14 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 QQnrno12391 for ; Mon, 2 Dec 2002 19:08: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 QQnrno16477 for ; Mon, 2 Dec 2002 19:08:05 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 QQnrno16472 for ; Mon, 2 Dec 2002 19:08:04 GMT Received: (qmail 29888 invoked by uid 104); 2 Dec 2002 19:08:03 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4235. . Clean. Processed in 0.940395 secs); 02 Dec 2002 19:08:03 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 2 Dec 2002 19:08:02 -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 gB2J7vQ23962; Mon, 2 Dec 2002 11:07:57 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Mon, 2 Dec 2002 11:07:56 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B1D@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Carlos M. Pignataro'" , Intae Jung , mpls-ops@mplsrc.com, mpls@UU.NET Subject: RE: Regarding LDP scalability Date: Mon, 2 Dec 2002 11:07:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29A36.1CCD4000" 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_01C29A36.1CCD4000 Content-Type: text/plain Here is how you do it: Network1 - R1 <-> LER1 <-> LSR1 <-> LSR2 <-> LER2 <-> R2 - Network2 <---IP Network---><------------MPLS Network---------><---IP Network---> LER1 runs DoD LDP and requests a label for Prefix=LER2 address (LSP12) LER2 does the same and requests a label for Prefix=LER1 address (LSP21) LSP12 could be viewed as a single link connecting LER1 and LER2, and therefore could be advertised (as FA) in IGP. Same thing for LSP21. Let's say Prefix X is in Network2. LER2 advertises X to all its neigbors including LSR2 and LER1 (which looks like a neighbor, due to LSP21). When LER1 is computing the SPF, the shortest path to Network2 is obviously LER2 via LSP12. -Shahram -----Original Message----- From: Carlos M. Pignataro [mailto:cpignata@cisco.com] Sent: Monday, December 02, 2002 10:52 AM To: Shahram Davari; Intae Jung; mpls-ops@mplsrc.com; mpls@UU.NET Subject: RE: Regarding LDP scalability Shahram, At 07:20 AM 12/2/2002 -0800, Shahram Davari wrote: Carlos, 1. Run MPLS TE Tunnels between the edge routers and have the edge routers learn these routes through the Tunnel (but you mention only LDP distributing labels). Why do we need to run TE. Can't you establish full mesh LSPs between edge routers, by running LDP DoD, only for edge router addresses. Normally, in a non-vc-merge environment, an LER will request labels (LDP DoD) for all entries in its routing table. Even if the next hop is the same, different LSPs will be signalled. That's why option 2 summarize the IGP. Then all prefixes could be advertised also inside these LSPs and be used by ingress LERs. How would we do that. An LDP signaled LSP is for a particular FEC. (FEC-Label mapping). New prefix -> new LSP. Check RCF 3031 section 5.1.1.4. PulledConditional and RFC 3035 section 8.1. Edge LSR Behavior. If LDP signals LSPs for only the edge router addresses, all other prefixes will not use that LSP. Regards, Carlos. Yours, -Shahram -----Original Message----- From: Carlos M. Pignataro [ mailto:cpignata@cisco.com ] Sent: Monday, December 02, 2002 9:52 AM To: Intae Jung; mpls-ops@mplsrc.com; mpls@UU.NET Subject: Re: Regarding LDP scalability Intae, At 12:09 AM 11/30/2002 +0900, Intae Jung wrote: Hello, I'd like to ask a couple of questions regarding a scalability of LDP, especially when it is deployed in an ATM-LSR, adopting Downstream on Demand distribution with conservative label retension and ordered control, where labels (VPI/VCI) are a relatively scarce resource that must be conserved in ATM switch. The VPI/VCI is a particularly valuable and limited resource that should be saved when an ATM LSR is not able to support VC-merging capability. Unfortunately the system I'm managing has no VC-merging capability. As defined in the standard, LDP attempts to setup or release a hop-by-hop LSP whenever a new route is added or deleted in an ATM LER through routing protocols, mainly IGP such as OSPF, ISIS or RIP. Let me assume a sample ATM-MPLS network as follows. Network1 - R1 <-> LER1 <-> LSR1 <-> LSR2 <-> LER2 <-> R2 - Network2 <---IP Network---><------------MPLS Network---------><---IP Network---> R1, R2: Router operating IGP (OSPF or RIP) LER1, LER2: Edge ATM LSR operating LDP and IGP (iBGP if needed) LSR1, LSR2: ATM LSR operating LDP and IGP (OSPF or IS-IS) OSPF or RIP is used in the IP Network and OSPF or IS-IS is deployed in the MPLS Network. An i-BGP session could be setup between LER1 and LER2 if needed, but not necessarily since LER1 and LER2 are not supposed to provide BGP/MPLS functionality, in other words, they don't work as a PE(Provider Edge) router. LER1, LER2, LSR1 and LSR2 support only LDP as an MPLS signaling protocol. The problem is that the number of LSP's from LER1 to LER2 increases as the number of networks increases in the Network2, meaning that the number of routing entries in LER1 increases accordingly, wherease the number of LSPs supported by LER1 is a lot smaller than the number of its route entries. Eventually, as the number of LSPs setup exceeds the maximum number of LSP's, we'll not be able to setup an LSP any more even though new routes are added. As I mentioned above, LSR1 and LSR2 don't support VC-merging capability, thus the scalability becomes quite servere. Therefore w're trying to figure out how to support a lot of routing entries using a limited number of LSP's. We are trying to come up with a mechanism that setups just one LSP between LER1 and LER2, which could be shared between all best-effort traffic between Network1 and Networks2. Some options to reduce the # of LSPs would be: 1. Run MPLS TE Tunnels between the edge routers and have the edge routers learn these routes through the Tunnel (but you mention only LDP distributing labels). 2. Summarize the networks on the edge routers (using your IGP). 3. As you mention, use iBGP. Some implementations also improve scalability by allowing an edge router, by configuration, to selects FECs for which to request a label (using DoD), as well as disabling ATM LSRs from requesting labels. Thanks, Carlos. The problem we faced is how to setup only 1 LSPs between LERs automatically, and then how to map a lot of route entries to the shared LSP. Although two LER's are shown in the example, the number of LSP's between LER's can be quite large as the number of LER's increases. We're considering to setup a full-mesh iBGP sessions between all LER's, and to use BGP next hop gateway in order to get an FEC-to-NHFLE mapping. In other words, routes from Network2 will be redistributed to LER1 via iBGP session between LER1 and LER2, and then LER1 will setup just one LSP for the BGP next hop address and map all routes from Network1 to the LSP. However it enforces us to setup iBGP sessions between all of LER's even though we don't need them unless we deploy MPLS. We're also wondering whether we'll be able to solve the problem using any IGP capability, like tag field of AS-external LSA in OSPF. Please enlighten us on this issue. Any experience or idea will be greatly appreciated. Thanks in advance. Regards, Jung. ================================================================= | Carlos Pignataro - CCIE 4619 cisco Systems, Inc. | Escalation RTP | cpignata@cisco.com || || | +1 919 392 7428 - office .||. .||. | +1 919 345 3028 - mobile .||||. .||||. | +1 919 392 6470 - fax .:||||||||:.:||||||||:. | 7025 Kit Creek Road, PO Box 14987 Are you Ready ? | Research Triangle Park, NC 27709 ================================================================= ================================================================= | Carlos Pignataro - CCIE 4619 cisco Systems, Inc. | Escalation RTP | cpignata@cisco.com || || | +1 919 392 7428 - office .||. .||. | +1 919 345 3028 - mobile .||||. .||||. | +1 919 392 6470 - fax .:||||||||:.:||||||||:. | 7025 Kit Creek Road, PO Box 14987 Are you Ready ? | Research Triangle Park, NC 27709 ================================================================= ------_=_NextPart_001_01C29A36.1CCD4000 Content-Type: text/html
Here is how you do it:
 
Network1 - R1 <-> LER1 <-> LSR1 <-> LSR2 <-> LER2 <-> R2 - Network2

<---IP Network---><------------MPLS Network---------><---IP Network--->
 
LER1 runs DoD LDP and requests a label for Prefix=LER2 address (LSP12)
LER2 does the same and requests a label for Prefix=LER1 address (LSP21)
LSP12 could be viewed as a single link connecting LER1 and LER2,
and therefore could be advertised (as FA) in IGP. Same thing for LSP21.
Let's say Prefix X is in Network2. LER2 advertises X to all its neigbors
including LSR2 and LER1 (which looks like a neighbor, due to LSP21).
When LER1 is computing the SPF, the shortest path to Network2 is obviously
LER2 via LSP12.
 
-Shahram
-----Original Message-----
From: Carlos M. Pignataro [mailto:cpignata@cisco.com]
Sent: Monday, December 02, 2002 10:52 AM
To: Shahram Davari; Intae Jung; mpls-ops@mplsrc.com; mpls@UU.NET
Subject: RE: Regarding LDP scalability

Shahram,

At 07:20 AM 12/2/2002 -0800, Shahram Davari wrote:
Carlos,
 
1. Run MPLS TE Tunnels between the edge routers and have the edge routers learn these routes through the Tunnel (but you mention only LDP distributing labels).
 
Why do we need to run TE. Can't you establish full mesh LSPs between edge routers, by running LDP DoD, only for edge router addresses.

Normally, in a non-vc-merge environment, an LER will request labels (LDP DoD) for all entries in its routing table. Even if the next hop is the same, different LSPs will be signalled. That's why option 2 summarize the IGP.

Then all prefixes could be advertised also inside these LSPs and
be used by ingress LERs.

How would we do that. An LDP signaled LSP is for a particular FEC. (FEC-Label mapping). New prefix -> new LSP. Check RCF 3031 section 5.1.1.4. PulledConditional and RFC 3035 section 8.1. Edge LSR Behavior.
If LDP signals LSPs for only the edge router addresses, all other prefixes will not use that LSP.

Regards,

Carlos.


Yours,
-Shahram
-----Original Message-----
From: Carlos M. Pignataro [mailto:cpignata@cisco.com]
Sent: Monday, December 02, 2002 9:52 AM
To: Intae Jung; mpls-ops@mplsrc.com; mpls@UU.NET
Subject: Re: Regarding LDP scalability

Intae,


At 12:09 AM 11/30/2002 +0900, Intae Jung wrote:
Hello,
I'd like to ask a couple of questions regarding a scalability of LDP,
especially when it is deployed in an ATM-LSR, adopting Downstream on
Demand distribution with conservative label retension and ordered control,
where labels (VPI/VCI) are a relatively scarce resource that must be conserved
in ATM switch. The VPI/VCI is a particularly valuable and limited resource that
should be saved when an ATM LSR is not able to support VC-merging capability.
Unfortunately the system I'm managing has no VC-merging capability.
As defined in the standard, LDP attempts to setup or release a hop-by-hop LSP
whenever a new route is added or deleted in an ATM LER through routing protocols,
mainly IGP such as OSPF, ISIS or RIP.
Let me assume a sample ATM-MPLS network as follows.

Network1 - R1 <-> LER1 <-> LSR1 <-> LSR2 <-> LER2 <-> R2 - Network2

<---IP Network---><------------MPLS Network---------><---IP Network--->

R1, R2: Router operating IGP (OSPF or RIP)
LER1, LER2: Edge ATM LSR operating LDP and IGP (iBGP if needed)
LSR1, LSR2: ATM LSR operating LDP and IGP (OSPF or IS-IS)

OSPF or RIP is used in the IP Network and OSPF or IS-IS is deployed
in the MPLS Network. An i-BGP session could be setup between LER1 and LER2
if needed, but not necessarily since LER1 and LER2 are not supposed to provide
BGP/MPLS functionality, in other words, they don't work as a PE(Provider Edge) router.
LER1, LER2, LSR1 and LSR2 support only LDP as an MPLS signaling protocol.

The problem is that the number of LSP's from LER1 to LER2 increases
as the number of networks increases in the Network2, meaning that the number of
routing entries in LER1 increases accordingly, wherease the number of LSPs supported
by LER1 is a lot smaller than the number of its route entries.
Eventually, as the number of LSPs setup exceeds the maximum number of LSP's,
we'll not be able to setup an LSP any more even though new routes are added.
As I mentioned above, LSR1 and LSR2 don't support VC-merging capability,
thus the scalability becomes quite servere.
Therefore w're trying to figure out how to support a lot of routing entries using
a limited number of LSP's. We are trying to come up with a mechanism that setups
just one LSP between LER1 and LER2, which could be shared between all best-effort
traffic between Network1 and Networks2.

Some options to reduce the # of LSPs would be:
1. Run MPLS TE Tunnels between the edge routers and have the edge routers learn these routes through the Tunnel (but you mention only LDP distributing labels).
2. Summarize the networks on the edge routers (using your IGP).
3. As you mention, use iBGP.

Some implementations also improve scalability by allowing an edge router, by configuration, to selects FECs for which to request a label (using DoD), as well as disabling ATM LSRs from requesting labels.

Thanks,

Carlos.

The problem we faced is how to setup only 1 LSPs between LERs automatically,
and then how to map a lot of route entries to the shared LSP.
Although two LER's are shown in the example, the number of LSP's between LER's
can be quite large as the number of LER's increases.
We're considering to setup a full-mesh iBGP sessions between all LER's, and
to use BGP next hop gateway in order to get an FEC-to-NHFLE mapping.
In other words, routes from Network2 will be redistributed to LER1 via iBGP session
between LER1 and LER2, and then LER1 will setup just one LSP for the BGP next hop
address and map all routes from Network1 to the LSP.
However it enforces us to setup iBGP sessions between all of LER's even though
we don't need them unless we deploy MPLS. We're also wondering whether
we'll be able to solve the problem using any IGP capability, like tag field of AS-external
LSA in OSPF.

Please enlighten us on this issue.
Any experience or idea will be greatly appreciated.
Thanks in advance.

Regards,

Jung.

=================================================================
                            |  Carlos Pignataro - CCIE 4619
     cisco Systems, Inc.    |  Escalation RTP
                            |  cpignata@cisco.com
       ||         ||        |  +1 919 392 7428 - office
      .||.       .||.       |  +1 919 345 3028 - mobile
     .||||.     .||||.      |  +1 919 392 6470 - fax
  .:||||||||:.:||||||||:.   |  7025 Kit Creek Road, PO Box 14987
      Are you Ready ?       |  Research Triangle Park, NC 27709
=================================================================

=================================================================
                            |  Carlos Pignataro - CCIE 4619
     cisco Systems, Inc.    |  Escalation RTP
                            |  cpignata@cisco.com
       ||         ||        |  +1 919 392 7428 - office
      .||.       .||.       |  +1 919 345 3028 - mobile
     .||||.     .||||.      |  +1 919 392 6470 - fax
  .:||||||||:.:||||||||:.   |  7025 Kit Creek Road, PO Box 14987
      Are you Ready ?       |  Research Triangle Park, NC 27709
=================================================================
------_=_NextPart_001_01C29A36.1CCD4000-- From owner-mpls@UU.NET Mon Dec 2 14:30: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 OAA05593 for ; Mon, 2 Dec 2002 14:30:29 -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 QQnrnq17728 for ; Mon, 2 Dec 2002 19:33: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 QQnrnq15278; Mon, 2 Dec 2002 19:31:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrnq08644 for mpls-outgoing; Mon, 2 Dec 2002 19:31:15 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 QQnrnq08516 for ; Mon, 2 Dec 2002 19:31: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 QQnrnq00144 for ; Mon, 2 Dec 2002 19:30: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 QQnrnq14344 for ; Mon, 2 Dec 2002 19:30:48 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 QQnrnq14332 for ; Mon, 2 Dec 2002 19:30:48 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 OAA05748 for ; Mon, 2 Dec 2002 14:30:47 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB2JUl222950 for mpls@uu.net; Mon, 2 Dec 2002 14:30:47 -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 QQnrnp08303 for ; Mon, 2 Dec 2002 19:28: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 QQnrnp25592 for ; Mon, 2 Dec 2002 19:27: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 QQnrnp00735 for ; Mon, 2 Dec 2002 19:27:11 GMT Received: from rediffmail.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: webmail34.rediffmail.com [203.199.83.247] (may be forged)) id QQnrnp00712 for ; Mon, 2 Dec 2002 19:27:10 GMT Received: (qmail 16517 invoked by uid 510); 2 Dec 2002 19:25:45 -0000 Date: 2 Dec 2002 19:25:45 -0000 Message-ID: <20021202192545.16516.qmail@mailweb34.rediffmail.com> Received: from unknown (203.200.20.226) by rediffmail.com via HTTP; 02 dec 2002 19:25:45 -0000 MIME-Version: 1.0 From: "venkat d" Reply-To: "venkat d" To: "Marcos Antonio De Almeida Cora" Cc: mpls@UU.NET, mpls-ops@mplsrc.com, ccamp@ops.ietf.org Subject: Re: Upstream Labels in GMPLS Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA05593 Hai, When a bi-directional request is sent for path establishment,any kind of failure irrespective of any error occurring for path towards downstream or path towards upstream will result in failure of the request as a whole. So no path is established in either and the intiator has to try again with new set. Thanks Venkat On Mon, 02 Dec 2002 Marcos Antonio De Almeida Cora wrote : >[ post by non-subscriber. with the massive amount of spam, it is easy to miss > and therefore delete posts by non-subscribers. if you wish to regularly > post from an address that is not subscribed to this mailing list, send a > message to -owner@ops.ietf.org and ask to have the alternate > address added to the list of addresses from which submissions are > automatically accepted. ] > >Hi, > >I have some doubts on Upstream Labels in GMPLS. >First, GMPLS supports both "unidirectional LSPs" and "bidirectional LSPs" ??? >I would like to know if when a initiator node send a request message >(Path/RSVP or Label Request/CR-LDP) with a Upstream Label, and this label is >not suitable for use at the next LSR, it must reject the request message >and send a "Error message" to the initiator node. In this case, the Error >message may include an acceptable Label Set to tell the Upstream LSR wich >labels would have been succeful. >But if Upstream LSR decide to fail the LSP set up, my doubt is: The >unidirectional LSP will set up and just the bidirectional LSP not is set >up ?? or both uniderectional and bidirectional will fail, and LSR >initiator will try again ?? > >Thanks, > > Marcos > >_________________________________________________________________ > > Marcos Antônio de Almeida Corá > School of Electrical and Computer Engineering > Departament of Telematics > State University of Campinas/Brazil - UNICAMP > Phone: +55 (19) 3788.3711 - Branch: 73723 > Home Page: www.dt.fee.unicamp.br/~cora >_________________________________________________________________ > > > > > > ____________________________ __________________________ NIIT supports World Computer Literacy Day on 2nd December. Enroll for NIIT SWIFT Jyoti till 2nd December for only Rs. 749 and get free Indian Languages Office software worth Rs. 2500. For details contact your nearest NIIT centre, SWIFT Point or click here http://swift.rediff.com/ From owner-mpls@UU.NET Mon Dec 2 14:45: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 OAA06450 for ; Mon, 2 Dec 2002 14:45:54 -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 QQnrnr18342 for ; Mon, 2 Dec 2002 19:48: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 QQnrnr16688; Mon, 2 Dec 2002 19:47:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrnr10968 for mpls-outgoing; Mon, 2 Dec 2002 19:47: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 QQnrnr10962 for ; Mon, 2 Dec 2002 19:47: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 QQnrnr09730 for ; Mon, 2 Dec 2002 19:46:07 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 QQnrnr01562 for ; Mon, 2 Dec 2002 19:46: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 QQnrnr01552 for ; Mon, 2 Dec 2002 19:46:06 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 OAA07150 for ; Mon, 2 Dec 2002 14:46:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB2Jk5r25628 for mpls@uu.net; Mon, 2 Dec 2002 14:46: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 QQnrnr10384 for ; Mon, 2 Dec 2002 19:45: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 QQnrnq07798 for ; Mon, 2 Dec 2002 19:44: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 QQnrnq00380 for ; Mon, 2 Dec 2002 19:44:18 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 QQnrnq00373 for ; Mon, 2 Dec 2002 19:44:17 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 OAA06992; Mon, 2 Dec 2002 14:44:17 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA19839; Mon, 2 Dec 2002 14:44:17 -0500 (EST) Message-Id: <200212021944.OAA19839@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: idr@merit.edu, mpls@UU.NET Subject: Close of Last Call Date: Mon, 02 Dec 2002 14:44:17 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk The last call on "Graceful Restart Mechanisms for BGP with MPLS" draft-ietf-mpls-bgp-mpls-restart-02.txt has ended. ...George ====================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Mon Dec 2 19:00:13 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 TAA18558 for ; Mon, 2 Dec 2002 19:00:13 -0500 (EST) 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 QQnrnz10265; Mon, 2 Dec 2002 21:49:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrnz27783 for mpls-outgoing; Mon, 2 Dec 2002 21:49:24 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 QQnrnz27776 for ; Mon, 2 Dec 2002 21:49: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 QQnrnz20082 for ; Mon, 2 Dec 2002 21:48:16 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 QQnrnz04398 for ; Mon, 2 Dec 2002 21:48:16 GMT Received: from johnson.mail.mindspring.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: johnson.mail.mindspring.net [207.69.200.177]) id QQnrnz04393 for ; Mon, 2 Dec 2002 21:48:15 GMT Received: from smui02.slb.mindspring.net ([199.174.114.25]) by johnson.mail.mindspring.net with esmtp (Exim 3.33 #1) id 18IyQJ-0006D0-00; Mon, 02 Dec 2002 16:48:15 -0500 Received: by smui02.slb.mindspring.net id QAA0000008895; Mon, 2 Dec 2002 16:48:14 -0500 (EST) Date: Mon, 02 Dec 2002 16:48:14 -0500 To: "Wijnen, Bert (Bert)" Cc: Adrian Farrel , "Thomas D. Nadeau" , "Wijnen, Bert (Bert)" , "Mpls (E-mail)" Reply-To: jcucchiara@mindspring.com Subject: RE: review of mpls-mgmt-overview revision 02 Message-ID: X-Originating-IP: 65.89.226.30 Sender: owner-mpls@UU.NET Precedence: bulk On Mon, 2 Dec 2002 19:10:33 +0100 "Wijnen, Bert (Bert)" wrote: > > Aaagh! > > > > Let's try to get this straight. > > > > There is only one MIB. > > There is a series of MIB documents, such as > MPLS-TE MIB. > Add "document" at the end > > > Each MIB document describes one or more MIB > modules, such as > > MPLS-TE-MIB. > > > > Is that agreed? > > > Yep. I agree also (and prefer this convention). thanks, Joan > > See also below > > > Adrian > > (Sorry if I am stating the obvious, but I'd > rather only make > > the change once!) > > > > > > > - I see you use mib module names with > an underscore, for example > > > > > MPLS-LDP_MIB, but the real module > name is MPLS-LDP-MIB > > > > > Better get that in sync. True for > most mib module names I believe > > > > > > > >Ah! I made this global change after I > thought I heard Tom suggest that you > > > >said > > > >that the use of underscore was a > requirement. At least one of us is out of > > > >synch here - I will change back to hyphen. > > > > > > Shouldn't it be written as > MPLS-LDP MIB when referring to the actual > > > MIB and not the SMI MODULE-NAME macro? > > > > > That would be fine with me too. But the > underscore seemed to show the MIB > module name (incorrectly). > > Bert > From owner-mpls@UU.NET Mon Dec 2 23:42:25 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 XAA25956 for ; Mon, 2 Dec 2002 23:42:24 -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 QQnrpb09526 for ; Tue, 3 Dec 2002 04:45:06 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 QQnrpa07095; Tue, 3 Dec 2002 04:43:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrpa14010 for mpls-outgoing; Tue, 3 Dec 2002 04:43: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 QQnrpa14003 for ; Tue, 3 Dec 2002 04:42:43 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 QQnrpa03941 for ; Tue, 3 Dec 2002 04:42: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 QQnrpa23768 for ; Tue, 3 Dec 2002 04:42:30 GMT Received: from mail1.lge.co.kr by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [156.147.1.151]) id QQnrpa23732 for ; Tue, 3 Dec 2002 04:42:27 GMT Received: from lgekrhqmh01.lge.com (lgekrhqmh01.lge.com [156.147.51.51]) by mail1.lge.co.kr (8.11.3/8.11.3) with ESMTP id gB34eRA25433; Tue, 3 Dec 2002 13:40:27 +0900 (KST) Received: from yongjuni ([150.150.40.133]) by lgekrhqmh01.lge.com (Lotus Domino Release 5.0.9a) with SMTP id 2002120313454703:1378665 ; Tue, 3 Dec 2002 13:45:47 +0900 Message-ID: <01c401c29a86$2fac9590$85289696@lge.com> Reply-To: "Yongjun Im" From: "Yongjun Im" To: "Shahram Davari" , "'Carlos M. Pignataro'" , , Cc: =?ks_c_5601-1987?B?wOXA57+1?= , =?ks_c_5601-1987?B?uejDtrnO?= References: <4B6D09F3B826D411A67300D0B706EFDEB03B1D@nt-exch-yow.pmc-sierra.bc.ca> Subject: Re: Regarding LDP scalability Date: Tue, 3 Dec 2002 13:41:03 +0900 Organization: LG Electronics, Inc. MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MIMETrack: Itemize by SMTP Server on LGEKRHQMH01/LGE/LG Group(Release 5.0.9a |January 7, 2002) at 12/03/2002 01:45:47 PM, Serialize by Router on LGEKRHQMH01/LGE/LG Group(Release 5.0.9a |January 7, 2002) at 12/03/2002 01:45:48 PM, Serialize complete at 12/03/2002 01:45:48 PM Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C1_01C29AD1.9F5586E0" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_01C1_01C29AD1.9F5586E0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SSBhZ3JlZSBpdCdzIG9uZSBvZiBiZXN0IGFwcHJvYWNoZXMsIGRlc2NyaWJlZCBieSBTaGFocmFt IGJlbG93LCB0byByZWR1Y2UgDQp0aGUgbnVtYmVyIG9mIExTUCdzIHNpZ25hbGxlZCBieSBMRFAu IEFGQUlLLCBvbmUgdmVkbm9yIGFscmVhZHkgc3VwcG9ydCBpdC4NCkhvd2V2ZXIsIGluIG9yZGVy IHRvIHN1cHBvcnQgdGhhdCBraW5kIG9mIHNjaGVtZSwgaXQgaXMgcmVxdWlyZWQgdGhhdCB3aGVu ZXZlciANCmFuIExTUCBpcyBlc3RhYmxpc2hlZCBiZXR3ZWVuIHR3byBMRVIncywgYWRkaXRpb25h bCBJUCBzdWJpbnRlcmZhY2UgYmV0d2VlbiANCmFuIExFUiBhbmQgaXRzIG5laWdoYm9yaW5nIExT Uiwgb3BlcmF0aW5nIElHUCwgc2hvdWxkIGJlIGluc3RhbGxlZCB3aXRoIHJlc3BlY3QgdG8gDQp0 aGF0IExTUC4gTm9ybWFseSwgc2luZ2xlIElQIGludGVyZmFjZSBpcyBtYWludGFpbmVkIGJldHdl ZW4gYW4gaW5ncmVzcyBBVE0gTEVSIA0KYW5kIGl0cyBhZGphY2VudCBMU1IsIHRocm91Z2ggTVBM UyBjb250cm9sIGNoYW5uZWwgKFZQSS9WQ0k9MC8zMikuIEhvd2V2ZXIsIA0KaW4gb3JkZXIgdG8g c3VwcG9ydCB0aGUgbWVjaGFuaXNtIGRlc2NyaWJlZCBiZWxvdywgd2UgaGF2ZSB0byBwcm92aWRl IGFkZGl0aW9uYWwgDQpmdW5jdGlvbmFsaXR5IHN1cHBvcnRpbmcgYSByb3V0aW5nIHByb3RvY29s IGZvciBMU1Agc3ViaW50ZXJmYWNlLCB3aGljaCBjYW4gYmUgDQplc3RhYmxpc2hlZCBvciByZWxl YXNlZCBkeW5hbWljYWxseS4gSSBhbHNvIGJlbGlldmUgdGhpcyBtZWNoYW5pbSBjb3VsZCBib2ls IGRvd24NCnRvIGZ1bGwtbWVzaCBJUG9BIG5ldHdvcmsgY29uZmlndXJhdGlvbiwgcmVxdWlyaW5n IFBWQydzIGFuZCByb3V0aW5nIGFkamFjZW5jaWVzIA0KYmV0d2VlbiByb3V0ZXJzIHRocm91Z2gg QVRNIG5ldHdvcmsuDQpJJ20gd29uZGVyaW5nIHdoZXRoZXIgdGhlcmUgaXMgYW55IG1lY2hhbmlz bSBub3QgcmVxdXJpbmcgYW55IGNoYW5nZSB0byBJUCBpbnRlcmZhY2UgDQpvciByb3V0aW5nIHBy b3RvY29sIG1hbmFnZW1lbnQuDQoNCllvbmdqdW4uDQoNCiAgLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLSANCiAgRnJvbTogU2hhaHJhbSBEYXZhcmkgDQogIFRvOiAnQ2FybG9zIE0uIFBpZ25h dGFybycgOyBJbnRhZSBKdW5nIDsgbXBscy1vcHNAbXBsc3JjLmNvbSA7IG1wbHNAVVUuTkVUIA0K ICBTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAwMywgMjAwMiA0OjA3IEFNDQogIFN1YmplY3Q6IFJF OiBSZWdhcmRpbmcgTERQIHNjYWxhYmlsaXR5DQoNCg0KICBIZXJlIGlzIGhvdyB5b3UgZG8gaXQ6 DQoNCiAgTmV0d29yazEgLSBSMSA8LT4gTEVSMSA8LT4gTFNSMSA8LT4gTFNSMiA8LT4gTEVSMiA8 LT4gUjIgLSBOZXR3b3JrMg0KDQogIDwtLS1JUCBOZXR3b3JrLS0tPjwtLS0tLS0tLS0tLS1NUExT IE5ldHdvcmstLS0tLS0tLS0+PC0tLUlQIE5ldHdvcmstLS0+DQoNCiAgTEVSMSBydW5zIERvRCBM RFAgYW5kIHJlcXVlc3RzIGEgbGFiZWwgZm9yIFByZWZpeD1MRVIyIGFkZHJlc3MgKExTUDEyKQ0K ICBMRVIyIGRvZXMgdGhlIHNhbWUgYW5kIHJlcXVlc3RzIGEgbGFiZWwgZm9yIFByZWZpeD1MRVIx IGFkZHJlc3MgKExTUDIxKQ0KICBMU1AxMiBjb3VsZCBiZSB2aWV3ZWQgYXMgYSBzaW5nbGUgbGlu ayBjb25uZWN0aW5nIExFUjEgYW5kIExFUjIsDQogIGFuZCB0aGVyZWZvcmUgY291bGQgYmUgYWR2 ZXJ0aXNlZCAoYXMgRkEpIGluIElHUC4gU2FtZSB0aGluZyBmb3IgTFNQMjEuDQogIExldCdzIHNh eSBQcmVmaXggWCBpcyBpbiBOZXR3b3JrMi4gTEVSMiBhZHZlcnRpc2VzIFggdG8gYWxsIGl0cyBu ZWlnYm9ycw0KICBpbmNsdWRpbmcgTFNSMiBhbmQgTEVSMSAod2hpY2ggbG9va3MgbGlrZSBhIG5l aWdoYm9yLCBkdWUgdG8gTFNQMjEpLiANCiAgV2hlbiBMRVIxIGlzIGNvbXB1dGluZyB0aGUgU1BG LCB0aGUgc2hvcnRlc3QgcGF0aCB0byBOZXR3b3JrMiBpcyBvYnZpb3VzbHkNCiAgTEVSMiB2aWEg TFNQMTIuDQoNCiAgLVNoYWhyYW0NCiAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAg IEZyb206IENhcmxvcyBNLiBQaWduYXRhcm8gW21haWx0bzpjcGlnbmF0YUBjaXNjby5jb21dDQog ICAgU2VudDogTW9uZGF5LCBEZWNlbWJlciAwMiwgMjAwMiAxMDo1MiBBTQ0KICAgIFRvOiBTaGFo cmFtIERhdmFyaTsgSW50YWUgSnVuZzsgbXBscy1vcHNAbXBsc3JjLmNvbTsgbXBsc0BVVS5ORVQN CiAgICBTdWJqZWN0OiBSRTogUmVnYXJkaW5nIExEUCBzY2FsYWJpbGl0eQ0KDQoNCiAgICBTaGFo cmFtLA0KDQogICAgQXQgMDc6MjAgQU0gMTIvMi8yMDAyIC0wODAwLCBTaGFocmFtIERhdmFyaSB3 cm90ZToNCg0KICAgICAgQ2FybG9zLA0KICAgICAgIA0KICAgICAgMS4gUnVuIE1QTFMgVEUgVHVu bmVscyBiZXR3ZWVuIHRoZSBlZGdlIHJvdXRlcnMgYW5kIGhhdmUgdGhlIGVkZ2Ugcm91dGVycyBs ZWFybiB0aGVzZSByb3V0ZXMgdGhyb3VnaCB0aGUgVHVubmVsIChidXQgeW91IG1lbnRpb24gb25s eSBMRFAgZGlzdHJpYnV0aW5nIGxhYmVscykuDQogICAgICAgDQogICAgICBXaHkgZG8gd2UgbmVl ZCB0byBydW4gVEUuIENhbid0IHlvdSBlc3RhYmxpc2ggZnVsbCBtZXNoIExTUHMgYmV0d2VlbiBl ZGdlIHJvdXRlcnMsIGJ5IHJ1bm5pbmcgTERQIERvRCwgb25seSBmb3IgZWRnZSByb3V0ZXIgYWRk cmVzc2VzLiANCg0KICAgIE5vcm1hbGx5LCBpbiBhIG5vbi12Yy1tZXJnZSBlbnZpcm9ubWVudCwg YW4gTEVSIHdpbGwgcmVxdWVzdCBsYWJlbHMgKExEUCBEb0QpIGZvciBhbGwgZW50cmllcyBpbiBp dHMgcm91dGluZyB0YWJsZS4gRXZlbiBpZiB0aGUgbmV4dCBob3AgaXMgdGhlIHNhbWUsIGRpZmZl cmVudCBMU1BzIHdpbGwgYmUgc2lnbmFsbGVkLiBUaGF0J3Mgd2h5IG9wdGlvbiAyIHN1bW1hcml6 ZSB0aGUgSUdQLg0KDQoNCiAgICAgIFRoZW4gYWxsIHByZWZpeGVzIGNvdWxkIGJlIGFkdmVydGlz ZWQgYWxzbyBpbnNpZGUgdGhlc2UgTFNQcyBhbmQNCiAgICAgIGJlIHVzZWQgYnkgaW5ncmVzcyBM RVJzLg0KDQogICAgSG93IHdvdWxkIHdlIGRvIHRoYXQuIEFuIExEUCBzaWduYWxlZCBMU1AgaXMg Zm9yIGEgcGFydGljdWxhciBGRUMuIChGRUMtTGFiZWwgbWFwcGluZykuIE5ldyBwcmVmaXggLT4g bmV3IExTUC4gQ2hlY2sgUkNGIDMwMzEgc2VjdGlvbiA1LjEuMS40LiBQdWxsZWRDb25kaXRpb25h bCBhbmQgUkZDIDMwMzUgc2VjdGlvbiA4LjEuIEVkZ2UgTFNSIEJlaGF2aW9yLg0KICAgIElmIExE UCBzaWduYWxzIExTUHMgZm9yIG9ubHkgdGhlIGVkZ2Ugcm91dGVyIGFkZHJlc3NlcywgYWxsIG90 aGVyIHByZWZpeGVzIHdpbGwgbm90IHVzZSB0aGF0IExTUC4NCg0KICAgIFJlZ2FyZHMsDQoNCiAg ICBDYXJsb3MuDQoNCg0KDQogICAgICBZb3VycywNCiAgICAgIC1TaGFocmFtIA0KDQogICAgICAg IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgICAgIEZyb206IENhcmxvcyBNLiBQaWdu YXRhcm8gW21haWx0bzpjcGlnbmF0YUBjaXNjby5jb21dDQogICAgICAgIFNlbnQ6IE1vbmRheSwg RGVjZW1iZXIgMDIsIDIwMDIgOTo1MiBBTQ0KICAgICAgICBUbzogSW50YWUgSnVuZzsgbXBscy1v cHNAbXBsc3JjLmNvbTsgbXBsc0BVVS5ORVQNCiAgICAgICAgU3ViamVjdDogUmU6IFJlZ2FyZGlu ZyBMRFAgc2NhbGFiaWxpdHkNCg0KICAgICAgICBJbnRhZSwNCg0KDQogICAgICAgIEF0IDEyOjA5 IEFNIDExLzMwLzIwMDIgKzA5MDAsIEludGFlIEp1bmcgd3JvdGU6DQoNCiAgICAgICAgICBIZWxs bywNCiAgICAgICAgICBJJ2QgbGlrZSB0byBhc2sgYSBjb3VwbGUgb2YgcXVlc3Rpb25zIHJlZ2Fy ZGluZyBhIHNjYWxhYmlsaXR5IG9mIExEUCwgDQogICAgICAgICAgZXNwZWNpYWxseSB3aGVuIGl0 IGlzIGRlcGxveWVkIGluIGFuIEFUTS1MU1IsIGFkb3B0aW5nIERvd25zdHJlYW0gb24NCiAgICAg ICAgICBEZW1hbmQgZGlzdHJpYnV0aW9uIHdpdGggY29uc2VydmF0aXZlIGxhYmVsIHJldGVuc2lv biBhbmQgb3JkZXJlZCBjb250cm9sLA0KICAgICAgICAgIHdoZXJlIGxhYmVscyAoVlBJL1ZDSSkg YXJlIGEgcmVsYXRpdmVseSBzY2FyY2UgcmVzb3VyY2UgdGhhdCBtdXN0IGJlIGNvbnNlcnZlZA0K ICAgICAgICAgIGluIEFUTSBzd2l0Y2guIFRoZSBWUEkvVkNJIGlzIGEgcGFydGljdWxhcmx5IHZh bHVhYmxlIGFuZCBsaW1pdGVkIHJlc291cmNlIHRoYXQgDQogICAgICAgICAgc2hvdWxkIGJlIHNh dmVkIHdoZW4gYW4gQVRNIExTUiBpcyBub3QgYWJsZSB0byBzdXBwb3J0IFZDLW1lcmdpbmcgY2Fw YWJpbGl0eS4NCiAgICAgICAgICBVbmZvcnR1bmF0ZWx5IHRoZSBzeXN0ZW0gSSdtIG1hbmFnaW5n IGhhcyBubyBWQy1tZXJnaW5nIGNhcGFiaWxpdHkuDQogICAgICAgICAgQXMgZGVmaW5lZCBpbiB0 aGUgc3RhbmRhcmQsIExEUCBhdHRlbXB0cyB0byBzZXR1cCBvciByZWxlYXNlIGEgaG9wLWJ5LWhv cCBMU1AgDQogICAgICAgICAgd2hlbmV2ZXIgYSBuZXcgcm91dGUgaXMgYWRkZWQgb3IgZGVsZXRl ZCBpbiBhbiBBVE0gTEVSIHRocm91Z2ggcm91dGluZyBwcm90b2NvbHMsIA0KICAgICAgICAgIG1h aW5seSBJR1Agc3VjaCBhcyBPU1BGLCBJU0lTIG9yIFJJUC4NCiAgICAgICAgICBMZXQgbWUgYXNz dW1lIGEgc2FtcGxlIEFUTS1NUExTIG5ldHdvcmsgYXMgZm9sbG93cy4NCg0KICAgICAgICAgIE5l dHdvcmsxIC0gUjEgPC0+IExFUjEgPC0+IExTUjEgPC0+IExTUjIgPC0+IExFUjIgPC0+IFIyIC0g TmV0d29yazINCg0KICAgICAgICAgIDwtLS1JUCBOZXR3b3JrLS0tPjwtLS0tLS0tLS0tLS1NUExT IE5ldHdvcmstLS0tLS0tLS0+PC0tLUlQIE5ldHdvcmstLS0+DQoNCiAgICAgICAgICBSMSwgUjI6 IFJvdXRlciBvcGVyYXRpbmcgSUdQIChPU1BGIG9yIFJJUCkNCiAgICAgICAgICBMRVIxLCBMRVIy OiBFZGdlIEFUTSBMU1Igb3BlcmF0aW5nIExEUCBhbmQgSUdQIChpQkdQIGlmIG5lZWRlZCkNCiAg ICAgICAgICBMU1IxLCBMU1IyOiBBVE0gTFNSIG9wZXJhdGluZyBMRFAgYW5kIElHUCAoT1NQRiBv ciBJUy1JUykNCg0KICAgICAgICAgIE9TUEYgb3IgUklQIGlzIHVzZWQgaW4gdGhlIElQIE5ldHdv cmsgYW5kIE9TUEYgb3IgSVMtSVMgaXMgZGVwbG95ZWQgDQogICAgICAgICAgaW4gdGhlIE1QTFMg TmV0d29yay4gQW4gaS1CR1Agc2Vzc2lvbiBjb3VsZCBiZSBzZXR1cCBiZXR3ZWVuIExFUjEgYW5k IExFUjINCiAgICAgICAgICBpZiBuZWVkZWQsIGJ1dCBub3QgbmVjZXNzYXJpbHkgc2luY2UgTEVS MSBhbmQgTEVSMiBhcmUgbm90IHN1cHBvc2VkIHRvIHByb3ZpZGUgDQogICAgICAgICAgQkdQL01Q TFMgZnVuY3Rpb25hbGl0eSwgaW4gb3RoZXIgd29yZHMsIHRoZXkgZG9uJ3Qgd29yayBhcyBhIFBF KFByb3ZpZGVyIEVkZ2UpIHJvdXRlci4gDQogICAgICAgICAgTEVSMSwgTEVSMiwgTFNSMSBhbmQg TFNSMiBzdXBwb3J0IG9ubHkgTERQIGFzIGFuIE1QTFMgc2lnbmFsaW5nIHByb3RvY29sLg0KDQog ICAgICAgICAgVGhlIHByb2JsZW0gaXMgdGhhdCB0aGUgbnVtYmVyIG9mIExTUCdzIGZyb20gTEVS MSB0byBMRVIyIGluY3JlYXNlcw0KICAgICAgICAgIGFzIHRoZSBudW1iZXIgb2YgbmV0d29ya3Mg aW5jcmVhc2VzIGluIHRoZSBOZXR3b3JrMiwgbWVhbmluZyB0aGF0IHRoZSBudW1iZXIgb2YNCiAg ICAgICAgICByb3V0aW5nIGVudHJpZXMgaW4gTEVSMSBpbmNyZWFzZXMgYWNjb3JkaW5nbHksIHdo ZXJlYXNlIHRoZSBudW1iZXIgb2YgTFNQcyBzdXBwb3J0ZWQNCiAgICAgICAgICBieSBMRVIxIGlz IGEgbG90IHNtYWxsZXIgdGhhbiB0aGUgbnVtYmVyIG9mIGl0cyByb3V0ZSBlbnRyaWVzLg0KICAg ICAgICAgIEV2ZW50dWFsbHksIGFzIHRoZSBudW1iZXIgb2YgTFNQcyBzZXR1cCBleGNlZWRzIHRo ZSBtYXhpbXVtIG51bWJlciBvZiBMU1AncywNCiAgICAgICAgICB3ZSdsbCBub3QgYmUgYWJsZSB0 byBzZXR1cCBhbiBMU1AgYW55IG1vcmUgZXZlbiB0aG91Z2ggbmV3IHJvdXRlcyBhcmUgYWRkZWQu DQogICAgICAgICAgQXMgSSBtZW50aW9uZWQgYWJvdmUsIExTUjEgYW5kIExTUjIgZG9uJ3Qgc3Vw cG9ydCBWQy1tZXJnaW5nIGNhcGFiaWxpdHksIA0KICAgICAgICAgIHRodXMgdGhlIHNjYWxhYmls aXR5IGJlY29tZXMgcXVpdGUgc2VydmVyZS4NCiAgICAgICAgICBUaGVyZWZvcmUgdydyZSB0cnlp bmcgdG8gZmlndXJlIG91dCBob3cgdG8gc3VwcG9ydCBhIGxvdCBvZiByb3V0aW5nIGVudHJpZXMg dXNpbmcNCiAgICAgICAgICBhIGxpbWl0ZWQgbnVtYmVyIG9mIExTUCdzLiBXZSBhcmUgdHJ5aW5n IHRvIGNvbWUgdXAgd2l0aCBhIG1lY2hhbmlzbSB0aGF0IHNldHVwcyANCiAgICAgICAgICBqdXN0 IG9uZSBMU1AgYmV0d2VlbiBMRVIxIGFuZCBMRVIyLCB3aGljaCBjb3VsZCBiZSBzaGFyZWQgYmV0 d2VlbiBhbGwgYmVzdC1lZmZvcnQNCiAgICAgICAgICB0cmFmZmljIGJldHdlZW4gTmV0d29yazEg YW5kIE5ldHdvcmtzMi4NCg0KICAgICAgICBTb21lIG9wdGlvbnMgdG8gcmVkdWNlIHRoZSAjIG9m IExTUHMgd291bGQgYmU6IA0KICAgICAgICAxLiBSdW4gTVBMUyBURSBUdW5uZWxzIGJldHdlZW4g dGhlIGVkZ2Ugcm91dGVycyBhbmQgaGF2ZSB0aGUgZWRnZSByb3V0ZXJzIGxlYXJuIHRoZXNlIHJv dXRlcyB0aHJvdWdoIHRoZSBUdW5uZWwgKGJ1dCB5b3UgbWVudGlvbiBvbmx5IExEUCBkaXN0cmli dXRpbmcgbGFiZWxzKS4NCiAgICAgICAgMi4gU3VtbWFyaXplIHRoZSBuZXR3b3JrcyBvbiB0aGUg ZWRnZSByb3V0ZXJzICh1c2luZyB5b3VyIElHUCkuDQogICAgICAgIDMuIEFzIHlvdSBtZW50aW9u LCB1c2UgaUJHUC4NCg0KICAgICAgICBTb21lIGltcGxlbWVudGF0aW9ucyBhbHNvIGltcHJvdmUg c2NhbGFiaWxpdHkgYnkgYWxsb3dpbmcgYW4gZWRnZSByb3V0ZXIsIGJ5IGNvbmZpZ3VyYXRpb24s IHRvIHNlbGVjdHMgRkVDcyBmb3Igd2hpY2ggdG8gcmVxdWVzdCBhIGxhYmVsICh1c2luZyBEb0Qp LCBhcyB3ZWxsIGFzIGRpc2FibGluZyBBVE0gTFNScyBmcm9tIHJlcXVlc3RpbmcgbGFiZWxzLg0K DQogICAgICAgIFRoYW5rcywNCg0KICAgICAgICBDYXJsb3MuDQoNCg0KICAgICAgICAgIFRoZSBw cm9ibGVtIHdlIGZhY2VkIGlzIGhvdyB0byBzZXR1cCBvbmx5IDEgTFNQcyBiZXR3ZWVuIExFUnMg YXV0b21hdGljYWxseSwgDQogICAgICAgICAgYW5kIHRoZW4gaG93IHRvIG1hcCBhIGxvdCBvZiBy b3V0ZSBlbnRyaWVzIHRvIHRoZSBzaGFyZWQgTFNQLg0KICAgICAgICAgIEFsdGhvdWdoIHR3byBM RVIncyBhcmUgc2hvd24gaW4gdGhlIGV4YW1wbGUsIHRoZSBudW1iZXIgb2YgTFNQJ3MgYmV0d2Vl biBMRVIncw0KICAgICAgICAgIGNhbiBiZSBxdWl0ZSBsYXJnZSBhcyB0aGUgbnVtYmVyIG9mIExF UidzIGluY3JlYXNlcy4NCiAgICAgICAgICBXZSdyZSBjb25zaWRlcmluZyB0byBzZXR1cCBhIGZ1 bGwtbWVzaCBpQkdQIHNlc3Npb25zIGJldHdlZW4gYWxsIExFUidzLCBhbmQNCiAgICAgICAgICB0 byB1c2UgQkdQIG5leHQgaG9wIGdhdGV3YXkgaW4gb3JkZXIgdG8gZ2V0IGFuIEZFQy10by1OSEZM RSBtYXBwaW5nLg0KICAgICAgICAgIEluIG90aGVyIHdvcmRzLCByb3V0ZXMgZnJvbSBOZXR3b3Jr MiB3aWxsIGJlIHJlZGlzdHJpYnV0ZWQgdG8gTEVSMSB2aWEgaUJHUCBzZXNzaW9uDQogICAgICAg ICAgYmV0d2VlbiBMRVIxIGFuZCBMRVIyLCBhbmQgdGhlbiBMRVIxIHdpbGwgc2V0dXAganVzdCBv bmUgTFNQIGZvciB0aGUgQkdQIG5leHQgaG9wDQogICAgICAgICAgYWRkcmVzcyBhbmQgbWFwIGFs bCByb3V0ZXMgZnJvbSBOZXR3b3JrMSB0byB0aGUgTFNQLg0KICAgICAgICAgIEhvd2V2ZXIgaXQg ZW5mb3JjZXMgdXMgdG8gc2V0dXAgaUJHUCBzZXNzaW9ucyBiZXR3ZWVuIGFsbCBvZiBMRVIncyBl dmVuIHRob3VnaA0KICAgICAgICAgIHdlIGRvbid0IG5lZWQgdGhlbSB1bmxlc3Mgd2UgZGVwbG95 IE1QTFMuIFdlJ3JlIGFsc28gd29uZGVyaW5nIHdoZXRoZXINCiAgICAgICAgICB3ZSdsbCBiZSBh YmxlIHRvIHNvbHZlIHRoZSBwcm9ibGVtIHVzaW5nIGFueSBJR1AgY2FwYWJpbGl0eSwgbGlrZSB0 YWcgZmllbGQgb2YgQVMtZXh0ZXJuYWwgDQogICAgICAgICAgTFNBIGluIE9TUEYuDQoNCiAgICAg ICAgICBQbGVhc2UgZW5saWdodGVuIHVzIG9uIHRoaXMgaXNzdWUuIA0KICAgICAgICAgIEFueSBl eHBlcmllbmNlIG9yIGlkZWEgd2lsbCBiZSBncmVhdGx5IGFwcHJlY2lhdGVkLg0KICAgICAgICAg IFRoYW5rcyBpbiBhZHZhbmNlLg0KDQogICAgICAgICAgUmVnYXJkcywNCg0KICAgICAgICAgIEp1 bmcuDQoNCiAgICAgICAgPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgIENhcmxvcyBQaWduYXRhcm8gLSBDQ0lFIDQ2MTkNCiAgICAgICAgICAgICBjaXNjbyBT eXN0ZW1zLCBJbmMuICAgIHwgIEVzY2FsYXRpb24gUlRQDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8ICBjcGlnbmF0YUBjaXNjby5jb20NCiAgICAgICAgICAgICAgIHx8ICAg ICAgICAgfHwgICAgICAgIHwgICsxIDkxOSAzOTIgNzQyOCAtIG9mZmljZQ0KICAgICAgICAgICAg ICAufHwuICAgICAgIC58fC4gICAgICAgfCAgKzEgOTE5IDM0NSAzMDI4IC0gbW9iaWxlDQogICAg ICAgICAgICAgLnx8fHwuICAgICAufHx8fC4gICAgICB8ICArMSA5MTkgMzkyIDY0NzAgLSBmYXgN CiAgICAgICAgICAuOnx8fHx8fHx8Oi46fHx8fHx8fHw6LiAgIHwgIDcwMjUgS2l0IENyZWVrIFJv YWQsIFBPIEJveCAxNDk4Nw0KICAgICAgICAgICAgICBBcmUgeW91IFJlYWR5ID8gICAgICAgfCAg UmVzZWFyY2ggVHJpYW5nbGUgUGFyaywgTkMgMjc3MDkNCiAgICAgICAgPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0gDQoNCiAg ICA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICBDYXJsb3MgUGln bmF0YXJvIC0gQ0NJRSA0NjE5DQogICAgICAgICBjaXNjbyBTeXN0ZW1zLCBJbmMuICAgIHwgIEVz Y2FsYXRpb24gUlRQDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIGNwaWduYXRh QGNpc2NvLmNvbQ0KICAgICAgICAgICB8fCAgICAgICAgIHx8ICAgICAgICB8ICArMSA5MTkgMzky IDc0MjggLSBvZmZpY2UNCiAgICAgICAgICAufHwuICAgICAgIC58fC4gICAgICAgfCAgKzEgOTE5 IDM0NSAzMDI4IC0gbW9iaWxlDQogICAgICAgICAufHx8fC4gICAgIC58fHx8LiAgICAgIHwgICsx IDkxOSAzOTIgNjQ3MCAtIGZheA0KICAgICAgLjp8fHx8fHx8fDouOnx8fHx8fHx8Oi4gICB8ICA3 MDI1IEtpdCBDcmVlayBSb2FkLCBQTyBCb3ggMTQ5ODcNCiAgICAgICAgICBBcmUgeW91IFJlYWR5 ID8gICAgICAgfCAgUmVzZWFyY2ggVHJpYW5nbGUgUGFyaywgTkMgMjc3MDkNCiAgICA9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PSA= ------=_NextPart_000_01C1_01C29AD1.9F5586E0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI4MDAuMTEyNiIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkkgYWdyZWUm bmJzcDtpdCdzIG9uZSBvZiBiZXN0IGFwcHJvYWNoZXMsJm5ic3A7ZGVzY3JpYmVkIGJ5IA0KU2hh aHJhbSBiZWxvdywgPC9GT05UPjxGT05UIHNpemU9Mj50byByZWR1Y2UgPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBzaXplPTI+dGhlIG51bWJlciBvZiBMU1AncyZuYnNwOzwvRk9OVD48Rk9OVCBz aXplPTI+c2lnbmFsbGVkIGJ5IExEUC4gDQpBRkFJSywgb25lIHZlZG5vciBhbHJlYWR5IDwvRk9O VD48Rk9OVCBzaXplPTI+c3VwcG9ydCBpdC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj5Ib3dldmVyLCBpbiBvcmRlciB0byBzdXBwb3J0IHRoYXQga2luZCBvZiBzY2hlbWUsIGl0IGlz IA0KcmVxdWlyZWQgdGhhdCB3aGVuZXZlciA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj5hbiBMU1AgaXMgZXN0YWJsaXNoZWQgYmV0d2VlbiB0d28gDQpMRVIncywmbmJzcDthZGRpdGlv bmFsJm5ic3A7SVAgc3ViaW50ZXJmYWNlIGJldHdlZW4gPC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBzaXplPTI+YW4gTEVSIDwvRk9OVD48Rk9OVCBzaXplPTI+YW5kIGl0cyZuYnNwO25laWdoYm9y aW5nIExTUiwgDQpvcGVyYXRpbmcgSUdQLCZuYnNwO3Nob3VsZDwvRk9OVD48Rk9OVCBzaXplPTI+ IGJlJm5ic3A7aW5zdGFsbGVkIHdpdGggcmVzcGVjdCB0byANCjwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPnRoYXQgTFNQLiZuYnNwOzwvRk9OVD48Rk9OVCBzaXplPTI+Tm9ybWFseSwg c2luZ2xlIElQIA0KaW50ZXJmYWNlIGlzIG1haW50YWluZWQgYmV0d2VlbiBhbiBpbmdyZXNzIEFU TSZuYnNwO0xFUiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5hbmQgaXRzIDwvRk9O VD48Rk9OVCBzaXplPTI+YWRqYWNlbnQgTFNSLCB0aHJvdWdoIE1QTFMgY29udHJvbCANCmNoYW5u ZWwgKFZQSS9WQ0k9MC8zMikuIEhvd2V2ZXIsIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6 ZT0yPmluIG9yZGVyIHRvIDwvRk9OVD48Rk9OVCBzaXplPTI+c3VwcG9ydCB0aGUgbWVjaGFuaXNt IA0KZGVzY3JpYmVkIGJlbG93LCB3ZSBoYXZlIHRvIHByb3ZpZGUgYWRkaXRpb25hbCA8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5mdW5jdGlvbmFsaXR5IDwvRk9OVD48Rk9OVCBzaXpl PTI+c3VwcG9ydGluZyBhIHJvdXRpbmcgDQpwcm90b2NvbCZuYnNwO2ZvciBMU1Agc3ViaW50ZXJm YWNlLCB3aGljaCBjYW4gYmUgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ZXN0YWJs aXNoZWQmbmJzcDs8L0ZPTlQ+PEZPTlQgc2l6ZT0yPm9yIHJlbGVhc2VkIGR5bmFtaWNhbGx5LiAN CkkgYWxzbyBiZWxpZXZlIHRoaXMgbWVjaGFuaW0gY291bGQgYm9pbCBkb3duPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTI+dG8gZnVsbC1tZXNoIElQb0EgbmV0d29yayBjb25maWd1cmF0 aW9uLCByZXF1aXJpbmcgUFZDJ3MgYW5kIA0Kcm91dGluZyBhZGphY2VuY2llcyA8L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj5iZXR3ZWVuIHJvdXRlcnMgdGhyb3VnaCBBVE0gbmV0d29y ay48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5JJ20gd29uZGVyaW5nIHdoZXRoZXIg dGhlcmUgaXMgYW55IG1lY2hhbmlzbSBub3QgcmVxdXJpbmcgYW55IA0KY2hhbmdlIHRvJm5ic3A7 PC9GT05UPjxGT05UIHNpemU9Mj5JUCA8L0ZPTlQ+PEZPTlQgc2l6ZT0yPmludGVyZmFjZSANCjwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPm9yIHJvdXRpbmcgcHJvdG9jb2wgbWFuYWdl bWVudC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj5Zb25nanVuLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6 ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxCTE9DS1FVT1RFIGRpcj1sdHIgDQpzdHlsZT0iUEFE RElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9S REVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYg c3R5bGU9IkZPTlQ6IDEwcHQgsby4siI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8L0RJ Vj4NCiAgPERJViANCiAgc3R5bGU9IkJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IEZPTlQ6IDEwcHQgsby4 sjsgZm9udC1jb2xvcjogYmxhY2siPjxCPkZyb206PC9CPiA8QSANCiAgdGl0bGU9U2hhaHJhbV9E YXZhcmlAcG1jLXNpZXJyYS5jb20gDQogIGhyZWY9Im1haWx0bzpTaGFocmFtX0RhdmFyaUBwbWMt c2llcnJhLmNvbSI+U2hhaHJhbSBEYXZhcmk8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05U OiAxMHB0ILG8uLIiPjxCPlRvOjwvQj4gPEEgdGl0bGU9Y3BpZ25hdGFAY2lzY28uY29tIA0KICBo cmVmPSJtYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tIj4nQ2FybG9zIE0uIFBpZ25hdGFybyc8L0E+ IDsgPEEgDQogIHRpdGxlPXlqaW1AbGdlLmNvbSBocmVmPSJtYWlsdG86eWppbUBsZ2UuY29tIj5J bnRhZSBKdW5nPC9BPiA7IDxBIA0KICB0aXRsZT1tcGxzLW9wc0BtcGxzcmMuY29tIA0KICBocmVm PSJtYWlsdG86bXBscy1vcHNAbXBsc3JjLmNvbSI+bXBscy1vcHNAbXBsc3JjLmNvbTwvQT4gOyA8 QSANCiAgdGl0bGU9bXBsc0BVVS5ORVQgaHJlZj0ibWFpbHRvOm1wbHNAVVUuTkVUIj5tcGxzQFVV Lk5FVDwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgsby4siI+PEI+U2VudDo8 L0I+IFR1ZXNkYXksIERlY2VtYmVyIDAzLCAyMDAyIDQ6MDcgDQogIEFNPC9ESVY+DQogIDxESVYg c3R5bGU9IkZPTlQ6IDEwcHQgsby4siI+PEI+U3ViamVjdDo8L0I+IFJFOiBSZWdhcmRpbmcgTERQ IHNjYWxhYmlsaXR5PC9ESVY+DQogIDxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD48Rk9OVCBzaXpl PTI+PC9GT05UPjxCUj48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAw ZmYgc2l6ZT0yPjxTUEFOIGNsYXNzPTM4NjIzNTYxOC0wMjEyMjAwMj5IZXJlIA0KICBpcyBob3cg eW91IGRvIGl0OjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBj b2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCiAgY2xhc3M9Mzg2MjM1NjE4LTAyMTIyMDAyPjwv U1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0j MDAwMGZmIHNpemU9Mj5OZXR3b3JrMSAtIFIxICZsdDstJmd0OyBMRVIxIA0KICAmbHQ7LSZndDsg TFNSMSAmbHQ7LSZndDsgTFNSMiAmbHQ7LSZndDsgTEVSMiAmbHQ7LSZndDsgUjIgLSANCiAgTmV0 d29yazI8QlI+PEJSPiZsdDstLS1JUCBOZXR3b3JrLS0tJmd0OyZsdDstLS0tLS0tLS0tLS1NUExT IA0KICBOZXR3b3JrLS0tLS0tLS0tJmd0OyZsdDstLS1JUCBOZXR3b3JrLS0tJmd0OzwvRk9OVD48 L0RJVj4NCiAgPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElWPjxG T05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gY2xhc3M9Mzg2MjM1NjE4 LTAyMTIyMDAyPkxFUjEgDQogIHJ1bnMgRG9EIExEUCBhbmQmbmJzcDtyZXF1ZXN0cyBhIGxhYmVs IGZvciBQcmVmaXg9TEVSMiBhZGRyZXNzIA0KICAoTFNQMTIpPC9TUEFOPjwvRk9OVD48L0RJVj4N CiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIGNsYXNz PTM4NjIzNTYxOC0wMjEyMjAwMj5MRVIyIA0KICBkb2VzIHRoZSBzYW1lIGFuZCByZXF1ZXN0cyBh IGxhYmVsIGZvciBQcmVmaXg9TEVSMSBhZGRyZXNzIA0KICAoTFNQMjEpPC9TUEFOPjwvRk9OVD48 L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFO IA0KICBjbGFzcz0zODYyMzU2MTgtMDIxMjIwMDI+TFNQMTIgY291bGQgYmUgdmlld2VkIGFzIGEg c2luZ2xlIGxpbmsgY29ubmVjdGluZyANCiAgTEVSMSBhbmQgTEVSMiw8L1NQQU4+PC9GT05UPjwv RElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4g Y2xhc3M9Mzg2MjM1NjE4LTAyMTIyMDAyPmFuZCANCiAgdGhlcmVmb3JlIGNvdWxkIGJlIGFkdmVy dGlzZWQgKGFzIEZBKSBpbiBJR1AuIFNhbWUgdGhpbmcgZm9yIA0KICBMU1AyMS48L1NQQU4+PC9G T05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+ PFNQQU4gDQogIGNsYXNzPTM4NjIzNTYxOC0wMjEyMjAwMj5MZXQncyBzYXkgUHJlZml4IFggaXMg aW4gTmV0d29yazIuIExFUjIgYWR2ZXJ0aXNlcyBYIA0KICB0byBhbGwgaXRzIG5laWdib3JzPC9T UEFOPjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYg c2l6ZT0yPjxTUEFOIA0KICBjbGFzcz0zODYyMzU2MTgtMDIxMjIwMDI+aW5jbHVkaW5nIExTUjIg YW5kIExFUjEgKHdoaWNoIGxvb2tzIGxpa2UgYSBuZWlnaGJvciwgDQogIGR1ZSB0byBMU1AyMSku IDwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAw MGZmIHNpemU9Mj48U1BBTiBjbGFzcz0zODYyMzU2MTgtMDIxMjIwMDI+V2hlbiANCiAgTEVSMSBp cyBjb21wdXRpbmcgdGhlIFNQRiwgdGhlIHNob3J0ZXN0IHBhdGggdG8gTmV0d29yazIgaXMgDQog IDwvU1BBTj48L0ZPTlQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BB TiANCiAgY2xhc3M9Mzg2MjM1NjE4LTAyMTIyMDAyPm9idmlvdXNseTwvU1BBTj48L0ZPTlQ+PC9E SVY+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiBj bGFzcz0zODYyMzU2MTgtMDIxMjIwMDI+TEVSMiANCiAgdmlhIExTUDEyLjwvU1BBTj48L0ZPTlQ+ PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BB TiANCiAgY2xhc3M9Mzg2MjM1NjE4LTAyMTIyMDAyPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCiAg Y2xhc3M9Mzg2MjM1NjE4LTAyMTIyMDAyPi1TaGFocmFtPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAg PEJMT0NLUVVPVEUgDQogIHN0eWxlPSJQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVw eDsgQk9SREVSLUxFRlQ6ICMwMDAwZmYgMnB4IHNvbGlkIj4NCiAgICA8RElWIGNsYXNzPU91dGxv b2tNZXNzYWdlSGVhZGVyIGRpcj1sdHIgYWxpZ249bGVmdD48Rk9OVCBmYWNlPVRhaG9tYSANCiAg ICBzaXplPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+PEI+RnJvbTo8L0I+IENhcmxv cyBNLiBQaWduYXRhcm8gDQogICAgW21haWx0bzpjcGlnbmF0YUBjaXNjby5jb21dPEJSPjxCPlNl bnQ6PC9CPiBNb25kYXksIERlY2VtYmVyIDAyLCAyMDAyIDEwOjUyIA0KICAgIEFNPEJSPjxCPlRv OjwvQj4gU2hhaHJhbSBEYXZhcmk7IEludGFlIEp1bmc7IG1wbHMtb3BzQG1wbHNyYy5jb207IA0K ICAgIG1wbHNAVVUuTkVUPEJSPjxCPlN1YmplY3Q6PC9CPiBSRTogUmVnYXJkaW5nIExEUCANCiAg ICBzY2FsYWJpbGl0eTxCUj48QlI+PC9ESVY+PC9GT05UPlNoYWhyYW0sPEJSPjxCUj5BdCAwNzoy MCBBTSAxMi8yLzIwMDIgLTA4MDAsIA0KICAgIFNoYWhyYW0gRGF2YXJpIHdyb3RlOjxCUj4NCiAg ICA8QkxPQ0tRVU9URSBjaXRlPSIiIHR5cGU9ImNpdGUiPjxGT05UIGZhY2U9YXJpYWwgY29sb3I9 IzAwMDBmZiANCiAgICAgIHNpemU9Mj5DYXJsb3MsPC9GT05UPjxCUj4mbmJzcDs8QlI+PEZPTlQg ZmFjZT1hcmlhbCBzaXplPTI+MS4gUnVuIE1QTFMgVEUgDQogICAgICBUdW5uZWxzIGJldHdlZW4g dGhlIGVkZ2Ugcm91dGVycyBhbmQgaGF2ZSB0aGUgZWRnZSByb3V0ZXJzIGxlYXJuIHRoZXNlIA0K ICAgICAgcm91dGVzIHRocm91Z2ggdGhlIFR1bm5lbCAoYnV0IHlvdSBtZW50aW9uIG9ubHkgTERQ IGRpc3RyaWJ1dGluZyANCiAgICAgIGxhYmVscykuPC9GT05UPjxCUj4mbmJzcDs8QlI+PEZPTlQg ZmFjZT1hcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj5XaHkgZG8gDQogICAgICB3ZSBuZWVkIHRv IHJ1biBURS4gQ2FuJ3QgeW91IGVzdGFibGlzaCBmdWxsIG1lc2ggTFNQcyBiZXR3ZWVuIGVkZ2Ug DQogICAgICByb3V0ZXJzLCBieSBydW5uaW5nIExEUCBEb0QsIG9ubHkgZm9yIGVkZ2Ugcm91dGVy IGFkZHJlc3Nlcy4gDQogICAgPC9GT05UPjwvQkxPQ0tRVU9URT48QlI+Tm9ybWFsbHksIGluIGEg bm9uLXZjLW1lcmdlIGVudmlyb25tZW50LCBhbiBMRVIgd2lsbCANCiAgICByZXF1ZXN0IGxhYmVs cyAoTERQIERvRCkgZm9yIGFsbCBlbnRyaWVzIGluIGl0cyByb3V0aW5nIHRhYmxlLiBFdmVuIGlm IHRoZSANCiAgICBuZXh0IGhvcCBpcyB0aGUgc2FtZSwgZGlmZmVyZW50IExTUHMgd2lsbCBiZSBz aWduYWxsZWQuIFRoYXQncyB3aHkgb3B0aW9uIDIgDQogICAgc3VtbWFyaXplIHRoZSBJR1AuPEJS PjxCUj4NCiAgICA8QkxPQ0tRVU9URSBjaXRlPSIiIHR5cGU9ImNpdGUiPjxGT05UIGZhY2U9YXJp YWwgY29sb3I9IzAwMDBmZiBzaXplPTI+VGhlbiANCiAgICAgIGFsbCBwcmVmaXhlcyBjb3VsZCBi ZSBhZHZlcnRpc2VkIGFsc28gaW5zaWRlIHRoZXNlIExTUHMgDQogICAgICBhbmQ8L0ZPTlQ+PEJS PjxGT05UIGZhY2U9YXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+YmUgdXNlZCBieSBpbmdyZXNz IA0KICAgICAgTEVScy48L0ZPTlQ+PC9CTE9DS1FVT1RFPjxCUj5Ib3cgd291bGQgd2UgZG8gdGhh dC4gQW4gTERQIHNpZ25hbGVkIExTUCBpcyANCiAgICBmb3IgYSBwYXJ0aWN1bGFyIEZFQy4gKEZF Qy1MYWJlbCBtYXBwaW5nKS4gTmV3IHByZWZpeCAtJmd0OyBuZXcgTFNQLiBDaGVjayANCiAgICBS Q0YgMzAzMSBzZWN0aW9uIDUuMS4xLjQuIFB1bGxlZENvbmRpdGlvbmFsIGFuZCBSRkMgMzAzNSBz ZWN0aW9uIDguMS4gRWRnZSANCiAgICBMU1IgQmVoYXZpb3IuPEJSPklmIExEUCBzaWduYWxzIExT UHMgZm9yIG9ubHkgdGhlIGVkZ2Ugcm91dGVyIGFkZHJlc3NlcywgYWxsIA0KICAgIG90aGVyIHBy ZWZpeGVzIHdpbGwgbm90IHVzZSB0aGF0IExTUC48QlI+PEJSPlJlZ2FyZHMsPEJSPjxCUj5DYXJs b3MuPEJSPjxCUj4NCiAgICA8QkxPQ0tRVU9URSBjaXRlPSIiIHR5cGU9ImNpdGUiPjxCUj48Rk9O VCBmYWNlPWFyaWFsIGNvbG9yPSMwMDAwZmYgDQogICAgICBzaXplPTI+WW91cnMsPC9GT05UPjxC Uj48Rk9OVCBmYWNlPWFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPi1TaGFocmFtIA0KICAgICAg PC9GT05UPjxCUj4NCiAgICAgIDxCTE9DS1FVT1RFIGNpdGU9IiIgdHlwZT0iY2l0ZSI+PEZPTlQg ZmFjZT10YWhvbWEgc2l6ZT0yPi0tLS0tT3JpZ2luYWwgDQogICAgICAgIE1lc3NhZ2UtLS0tLTxC Uj48Qj5Gcm9tOjwvQj4gQ2FybG9zIE0uIFBpZ25hdGFybyBbPEEgDQogICAgICAgIGhyZWY9Im1h aWx0bzpjcGlnbmF0YUBjaXNjby5jb20iIA0KICAgICAgICBldWRvcmE9ImF1dG91cmwiPm1haWx0 bzpjcGlnbmF0YUBjaXNjby5jb208L0E+XTxCUj48Qj5TZW50OjwvQj4gTW9uZGF5LCANCiAgICAg ICAgRGVjZW1iZXIgMDIsIDIwMDIgOTo1MiBBTTxCUj48Qj5Ubzo8L0I+IEludGFlIEp1bmc7IG1w bHMtb3BzQG1wbHNyYy5jb207IA0KICAgICAgICBtcGxzQFVVLk5FVDxCUj48Qj5TdWJqZWN0Ojwv Qj4gUmU6IFJlZ2FyZGluZyBMRFAgDQogICAgICAgIHNjYWxhYmlsaXR5PEJSPjxCUj48L0ZPTlQ+ SW50YWUsPEJSPjxCUj48QlI+QXQgMTI6MDkgQU0gMTEvMzAvMjAwMiANCiAgICAgICAgKzA5MDAs IEludGFlIEp1bmcgd3JvdGU6PEJSPg0KICAgICAgICA8QkxPQ0tRVU9URSBjaXRlPSIiIHR5cGU9 ImNpdGUiPjxGT05UIA0KICAgICAgICAgIGZhY2U9IlRpbWVzIE5ldyBSb21hbiwgVGltZXMiPkhl bGxvLDxCUj5JJ2QgbGlrZSB0byBhc2sgYSBjb3VwbGUgb2YgDQogICAgICAgICAgcXVlc3Rpb25z IHJlZ2FyZGluZyBhIHNjYWxhYmlsaXR5IG9mIExEUCwgPEJSPmVzcGVjaWFsbHkgd2hlbiBpdCBp cyANCiAgICAgICAgICBkZXBsb3llZCBpbiBhbiBBVE0tTFNSLCBhZG9wdGluZyBEb3duc3RyZWFt IG9uPEJSPkRlbWFuZCBkaXN0cmlidXRpb24gDQogICAgICAgICAgd2l0aCBjb25zZXJ2YXRpdmUg bGFiZWwgcmV0ZW5zaW9uIGFuZCBvcmRlcmVkIGNvbnRyb2wsPEJSPndoZXJlIGxhYmVscyANCiAg ICAgICAgICAoVlBJL1ZDSSkgYXJlIGEgcmVsYXRpdmVseSBzY2FyY2UgcmVzb3VyY2UgdGhhdCBt dXN0IGJlIA0KICAgICAgICAgIGNvbnNlcnZlZDxCUj5pbiBBVE0gc3dpdGNoLiBUaGUgVlBJL1ZD SSBpcyBhIHBhcnRpY3VsYXJseSB2YWx1YWJsZSBhbmQgDQogICAgICAgICAgbGltaXRlZCByZXNv dXJjZSB0aGF0IDxCUj5zaG91bGQgYmUgc2F2ZWQgd2hlbiBhbiBBVE0gTFNSIGlzIG5vdCBhYmxl IA0KICAgICAgICAgIHRvIHN1cHBvcnQgVkMtbWVyZ2luZyBjYXBhYmlsaXR5LjxCUj5VbmZvcnR1 bmF0ZWx5IHRoZSBzeXN0ZW0gSSdtIA0KICAgICAgICAgIG1hbmFnaW5nIGhhcyBubyBWQy1tZXJn aW5nIGNhcGFiaWxpdHkuPEJSPkFzIGRlZmluZWQgaW4gdGhlIHN0YW5kYXJkLCANCiAgICAgICAg ICBMRFAgYXR0ZW1wdHMgdG8gc2V0dXAgb3IgcmVsZWFzZSBhIGhvcC1ieS1ob3AgTFNQIDxCUj53 aGVuZXZlciBhIG5ldyANCiAgICAgICAgICByb3V0ZSBpcyBhZGRlZCBvciBkZWxldGVkIGluIGFu IEFUTSBMRVIgdGhyb3VnaCByb3V0aW5nIHByb3RvY29scywgDQogICAgICAgICAgPEJSPm1haW5s eSBJR1Agc3VjaCBhcyBPU1BGLCBJU0lTIG9yIFJJUC48QlI+TGV0IG1lIGFzc3VtZSBhIHNhbXBs ZSANCiAgICAgICAgICBBVE0tTVBMUyBuZXR3b3JrIGFzIGZvbGxvd3MuPEJSPjxCUj5OZXR3b3Jr MSAtIFIxICZsdDstJmd0OyBMRVIxIA0KICAgICAgICAgICZsdDstJmd0OyBMU1IxICZsdDstJmd0 OyBMU1IyICZsdDstJmd0OyBMRVIyICZsdDstJmd0OyBSMiAtIA0KICAgICAgICAgIE5ldHdvcmsy PEJSPjxCUj4mbHQ7LS0tSVAgTmV0d29yay0tLSZndDsmbHQ7LS0tLS0tLS0tLS0tTVBMUyANCiAg ICAgICAgICBOZXR3b3JrLS0tLS0tLS0tJmd0OyZsdDstLS1JUCBOZXR3b3JrLS0tJmd0OzxCUj48 QlI+UjEsIFIyOiBSb3V0ZXIgDQogICAgICAgICAgb3BlcmF0aW5nIElHUCAoT1NQRiBvciBSSVAp PEJSPkxFUjEsIExFUjI6IEVkZ2UgQVRNIExTUiBvcGVyYXRpbmcgTERQIA0KICAgICAgICAgIGFu ZCBJR1AgKGlCR1AgaWYgbmVlZGVkKTxCUj5MU1IxLCBMU1IyOiBBVE0gTFNSIG9wZXJhdGluZyBM RFAgYW5kIElHUCANCiAgICAgICAgICAoT1NQRiBvciBJUy1JUyk8QlI+PEJSPk9TUEYgb3IgUklQ IGlzIHVzZWQgaW4gdGhlIElQIE5ldHdvcmsgYW5kIE9TUEYgDQogICAgICAgICAgb3IgSVMtSVMg aXMgZGVwbG95ZWQgPEJSPmluIHRoZSBNUExTIE5ldHdvcmsuIEFuIGktQkdQIHNlc3Npb24gY291 bGQgDQogICAgICAgICAgYmUgc2V0dXAgYmV0d2VlbiBMRVIxIGFuZCBMRVIyPEJSPmlmIG5lZWRl ZCwgYnV0IG5vdCBuZWNlc3NhcmlseSBzaW5jZSANCiAgICAgICAgICBMRVIxIGFuZCBMRVIyIGFy ZSBub3Qgc3VwcG9zZWQgdG8gcHJvdmlkZSA8QlI+QkdQL01QTFMgZnVuY3Rpb25hbGl0eSwgDQog ICAgICAgICAgaW4gb3RoZXIgd29yZHMsIHRoZXkgZG9uJ3Qgd29yayBhcyBhIFBFKFByb3ZpZGVy IEVkZ2UpIHJvdXRlci4gDQogICAgICAgICAgPEJSPkxFUjEsIExFUjIsIExTUjEgYW5kIExTUjIg c3VwcG9ydCBvbmx5IExEUCBhcyBhbiBNUExTIHNpZ25hbGluZyANCiAgICAgICAgICBwcm90b2Nv bC48QlI+PEJSPlRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIG51bWJlciBvZiBMU1AncyBmcm9tIExF UjEgdG8gDQogICAgICAgICAgTEVSMiBpbmNyZWFzZXM8QlI+YXMgdGhlIG51bWJlciBvZiBuZXR3 b3JrcyBpbmNyZWFzZXMgaW4gdGhlIE5ldHdvcmsyLCANCiAgICAgICAgICBtZWFuaW5nIHRoYXQg dGhlIG51bWJlciBvZjxCUj5yb3V0aW5nIGVudHJpZXMgaW4gTEVSMSBpbmNyZWFzZXMgDQogICAg ICAgICAgYWNjb3JkaW5nbHksIHdoZXJlYXNlIHRoZSBudW1iZXIgb2YgTFNQcyBzdXBwb3J0ZWQ8 QlI+YnkgTEVSMSBpcyBhIGxvdCANCiAgICAgICAgICBzbWFsbGVyIHRoYW4gdGhlIG51bWJlciBv ZiBpdHMgcm91dGUgZW50cmllcy48QlI+RXZlbnR1YWxseSwgYXMgdGhlIA0KICAgICAgICAgIG51 bWJlciBvZiBMU1BzIHNldHVwIGV4Y2VlZHMgdGhlIG1heGltdW0gbnVtYmVyIG9mIExTUCdzLDxC Uj53ZSdsbCBub3QgDQogICAgICAgICAgYmUgYWJsZSB0byBzZXR1cCBhbiBMU1AgYW55IG1vcmUg ZXZlbiB0aG91Z2ggbmV3IHJvdXRlcyBhcmUgDQogICAgICAgICAgYWRkZWQuPEJSPkFzIEkgbWVu dGlvbmVkIGFib3ZlLCBMU1IxIGFuZCBMU1IyIGRvbid0IHN1cHBvcnQgVkMtbWVyZ2luZyANCiAg ICAgICAgICBjYXBhYmlsaXR5LCA8QlI+dGh1cyB0aGUgc2NhbGFiaWxpdHkgYmVjb21lcyBxdWl0 ZSANCiAgICAgICAgICBzZXJ2ZXJlLjxCUj5UaGVyZWZvcmUgdydyZSB0cnlpbmcgdG8gZmlndXJl IG91dCBob3cgdG8gc3VwcG9ydCBhIGxvdCANCiAgICAgICAgICBvZiByb3V0aW5nIGVudHJpZXMg dXNpbmc8QlI+YSBsaW1pdGVkIG51bWJlciBvZiBMU1Ancy4gV2UgYXJlIHRyeWluZyANCiAgICAg ICAgICB0byBjb21lIHVwIHdpdGggYSBtZWNoYW5pc20gdGhhdCBzZXR1cHMgPEJSPmp1c3Qgb25l IExTUCBiZXR3ZWVuIExFUjEgDQogICAgICAgICAgYW5kIExFUjIsIHdoaWNoIGNvdWxkIGJlIHNo YXJlZCBiZXR3ZWVuIGFsbCBiZXN0LWVmZm9ydDxCUj50cmFmZmljIA0KICAgICAgICAgIGJldHdl ZW4gTmV0d29yazEgYW5kIE5ldHdvcmtzMi48L0ZPTlQ+PC9CTE9DS1FVT1RFPjxCUj5Tb21lIG9w dGlvbnMgdG8gDQogICAgICAgIHJlZHVjZSB0aGUgIyBvZiBMU1BzIHdvdWxkIGJlOiA8QlI+MS4g UnVuIE1QTFMgVEUgVHVubmVscyBiZXR3ZWVuIHRoZSANCiAgICAgICAgZWRnZSByb3V0ZXJzIGFu ZCBoYXZlIHRoZSBlZGdlIHJvdXRlcnMgbGVhcm4gdGhlc2Ugcm91dGVzIHRocm91Z2ggdGhlIA0K ICAgICAgICBUdW5uZWwgKGJ1dCB5b3UgbWVudGlvbiBvbmx5IExEUCBkaXN0cmlidXRpbmcgbGFi ZWxzKS48QlI+Mi4gU3VtbWFyaXplIA0KICAgICAgICB0aGUgbmV0d29ya3Mgb24gdGhlIGVkZ2Ug cm91dGVycyAodXNpbmcgeW91ciBJR1ApLjxCUj4zLiBBcyB5b3UgbWVudGlvbiwgDQogICAgICAg IHVzZSBpQkdQLjxCUj48QlI+U29tZSBpbXBsZW1lbnRhdGlvbnMgYWxzbyBpbXByb3ZlIHNjYWxh YmlsaXR5IGJ5IA0KICAgICAgICBhbGxvd2luZyBhbiBlZGdlIHJvdXRlciwgYnkgY29uZmlndXJh dGlvbiwgdG8gc2VsZWN0cyBGRUNzIGZvciB3aGljaCB0byANCiAgICAgICAgcmVxdWVzdCBhIGxh YmVsICh1c2luZyBEb0QpLCBhcyB3ZWxsIGFzIGRpc2FibGluZyBBVE0gTFNScyBmcm9tIA0KICAg ICAgICByZXF1ZXN0aW5nIGxhYmVscy48QlI+PEJSPlRoYW5rcyw8QlI+PEJSPkNhcmxvcy48QlI+ PEJSPg0KICAgICAgICA8QkxPQ0tRVU9URSBjaXRlPSIiIHR5cGU9ImNpdGUiPjxGT05UIA0KICAg ICAgICAgIGZhY2U9IlRpbWVzIE5ldyBSb21hbiwgVGltZXMiPlRoZSBwcm9ibGVtIHdlIGZhY2Vk IGlzIGhvdyB0byBzZXR1cCANCiAgICAgICAgICBvbmx5IDEgTFNQcyBiZXR3ZWVuIExFUnMgYXV0 b21hdGljYWxseSwgPEJSPmFuZCB0aGVuIGhvdyB0byBtYXAgYSBsb3QgDQogICAgICAgICAgb2Yg cm91dGUgZW50cmllcyB0byB0aGUgc2hhcmVkIExTUC48QlI+QWx0aG91Z2ggdHdvIExFUidzIGFy ZSBzaG93biBpbiANCiAgICAgICAgICB0aGUgZXhhbXBsZSwgdGhlIG51bWJlciBvZiBMU1AncyBi ZXR3ZWVuIExFUidzPEJSPmNhbiBiZSBxdWl0ZSBsYXJnZSANCiAgICAgICAgICBhcyB0aGUgbnVt YmVyIG9mIExFUidzIGluY3JlYXNlcy48QlI+V2UncmUgY29uc2lkZXJpbmcgdG8gc2V0dXAgYSAN CiAgICAgICAgICBmdWxsLW1lc2ggaUJHUCBzZXNzaW9ucyBiZXR3ZWVuIGFsbCBMRVIncywgYW5k PEJSPnRvIHVzZSBCR1AgbmV4dCBob3AgDQogICAgICAgICAgZ2F0ZXdheSBpbiBvcmRlciB0byBn ZXQgYW4gRkVDLXRvLU5IRkxFIG1hcHBpbmcuPEJSPkluIG90aGVyIHdvcmRzLCANCiAgICAgICAg ICByb3V0ZXMgZnJvbSBOZXR3b3JrMiB3aWxsIGJlIHJlZGlzdHJpYnV0ZWQgdG8gTEVSMSB2aWEg aUJHUCANCiAgICAgICAgICBzZXNzaW9uPEJSPmJldHdlZW4gTEVSMSBhbmQgTEVSMiwgYW5kIHRo ZW4gTEVSMSB3aWxsIHNldHVwIGp1c3Qgb25lIA0KICAgICAgICAgIExTUCBmb3IgdGhlIEJHUCBu ZXh0IGhvcDxCUj5hZGRyZXNzIGFuZCBtYXAgYWxsIHJvdXRlcyBmcm9tIE5ldHdvcmsxIA0KICAg ICAgICAgIHRvIHRoZSBMU1AuPEJSPkhvd2V2ZXIgaXQgZW5mb3JjZXMgdXMgdG8gc2V0dXAgaUJH UCBzZXNzaW9ucyBiZXR3ZWVuIA0KICAgICAgICAgIGFsbCBvZiBMRVIncyBldmVuIHRob3VnaDxC Uj53ZSBkb24ndCBuZWVkIHRoZW0gdW5sZXNzIHdlIGRlcGxveSBNUExTLiANCiAgICAgICAgICBX ZSdyZSBhbHNvIHdvbmRlcmluZyB3aGV0aGVyPEJSPndlJ2xsIGJlIGFibGUgdG8gc29sdmUgdGhl IHByb2JsZW0gDQogICAgICAgICAgdXNpbmcgYW55IElHUCBjYXBhYmlsaXR5LCBsaWtlIHRhZyBm aWVsZCBvZiBBUy1leHRlcm5hbCA8QlI+TFNBIGluIA0KICAgICAgICAgIE9TUEYuPEJSPjxCUj5Q bGVhc2UgZW5saWdodGVuIHVzIG9uIHRoaXMgaXNzdWUuIDxCUj5BbnkgZXhwZXJpZW5jZSBvciAN CiAgICAgICAgICBpZGVhIHdpbGwgYmUgZ3JlYXRseSBhcHByZWNpYXRlZC48QlI+VGhhbmtzIGlu IA0KICAgICAgICAgIGFkdmFuY2UuPEJSPjxCUj5SZWdhcmRzLDxCUj48QlI+SnVuZy48L0ZPTlQ+ PC9CTE9DS1FVT1RFPjxCUj48VFQ+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAgICAgICB8Jm5ic3A7IENhcmxvcyBQaWduYXRh cm8gLSBDQ0lFIDQ2MTk8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNpc2NvIA0KICAgICAg ICBTeXN0ZW1zLCBJbmMuJm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgRXNjYWxhdGlvbiANCiAg ICAgICAgUlRQPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyANCiAgICAgICAgfCZuYnNwOyBjcGlnbmF0YUBjaXNjby5jb208QlI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAgICAgICB8fCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICAgICAgfHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyArMSA5MTkgMzkyIDc0MjggLSANCiAg ICAgICAgb2ZmaWNlPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICAgICAg Lnx8LiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICAgICAgLnx8LiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICsxIDkxOSAzNDUgMzAy OCAtIA0KICAgICAgICBtb2JpbGU8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC58fHx8LiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICAgICAgLnx8fHwuJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgKzEgOTE5IDM5MiA2NDcwIC0gDQogICAgICAgIGZheDxCUj4m bmJzcDsgLjp8fHx8fHx8fDouOnx8fHx8fHx8Oi4mbmJzcDsmbmJzcDsgfCZuYnNwOyA3MDI1IEtp dCBDcmVlayANCiAgICAgICAgUm9hZCwgUE8gQm94IDE0OTg3PEJSPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBBcmUgeW91IFJlYWR5IA0KICAgICAgICA/Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgUmVzZWFyY2ggVHJpYW5nbGUgUGFyaywgTkMgDQog ICAgICAgIDI3NzA5PEJSPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09IA0KICAgICAgPC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9U RT48QlI+PFRUPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyANCiAgICB8Jm5ic3A7IENhcmxvcyBQaWduYXRhcm8gLSBDQ0lFIDQ2MTk8 QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNpc2NvIA0KICAgIFN5c3RlbXMsIEluYy4mbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyBFc2NhbGF0aW9uIA0KICAgIFJUUDxCUj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogICAgfCZuYnNwOyBjcGln bmF0YUBjaXNjby5jb208QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0K ICAgIHx8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0K ICAgIHx8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsg KzEgOTE5IDM5MiA3NDI4IC0gDQogICAgb2ZmaWNlPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyANCiAgICAufHwuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0K ICAgIC58fC4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyArMSA5 MTkgMzQ1IDMwMjggLSANCiAgICBtb2JpbGU8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC58 fHx8LiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICAufHx8fC4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyArMSA5MTkgMzkyIDY0NzAgLSBmYXg8QlI+Jm5ic3A7IA0K ICAgIC46fHx8fHx8fHw6Ljp8fHx8fHx8fDouJm5ic3A7Jm5ic3A7IHwmbmJzcDsgNzAyNSBLaXQg Q3JlZWsgUm9hZCwgUE8gQm94IA0KICAgIDE0OTg3PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBBcmUgeW91IFJlYWR5IA0KICAgID8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyBSZXNlYXJjaCBUcmlhbmdsZSBQYXJrLCBOQyANCiAgICAyNzcwOTxC Uj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PSANCiAgICA8L1RUPjwvVFQ+PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9URT48L0JP RFk+PC9IVE1MPg0K ------=_NextPart_000_01C1_01C29AD1.9F5586E0-- From owner-mpls@UU.NET Tue Dec 3 01:05: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 BAA28571 for ; Tue, 3 Dec 2002 01:05:04 -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 QQnrpg07161 for ; Tue, 3 Dec 2002 06:07:51 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 QQnrpg04972; Tue, 3 Dec 2002 06:06:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrpg26283 for mpls-outgoing; Tue, 3 Dec 2002 06:06:23 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 QQnrpg26249 for ; Tue, 3 Dec 2002 06:06:14 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 QQnrpg20610 for ; Tue, 3 Dec 2002 06:05:33 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 QQnrpg03737 for ; Tue, 3 Dec 2002 06:05:33 GMT Received: from dharti.aplion.stpn.soft.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.190.133.225]) id QQnrpg03711 for ; Tue, 3 Dec 2002 06:05:29 GMT Received: from cyborg (localhost [127.0.0.1]) by dharti.aplion.stpn.soft.net (8.11.2/8.11.2) with SMTP id gB366hq32689 for ; Tue, 3 Dec 2002 11:36:53 +0530 Reply-To: From: "Mayank Kumar" To: "Mpls \(E-mail\)" Date: Tue, 3 Dec 2002 11:38:51 +0530 Message-ID: <001001c29a92$7487e140$fe04a8c0@cyborg> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit HI would somebody tell me if there was a paper or rfc talking about the security issues of mpls architecture and ways in which it can be handled. i know of a draft that talks about the security issues of mpls/bgp vpn's and martini vpn's and compares it security aspects with other layer 2 vpn's method. i would like to have a paper detailing about the security issues in the rfc 3031 arch and the signalling protocols used for lsp setup. any help or useful pointers in this regard will be highly appreciated. thanks and regards Mayank From owner-mpls@UU.NET Tue Dec 3 01:29: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 BAA29182 for ; Tue, 3 Dec 2002 01:29:30 -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 QQnrpi10365 for ; Tue, 3 Dec 2002 06:32: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 QQnrph29217; Tue, 3 Dec 2002 06:27:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrph28790 for mpls-outgoing; Tue, 3 Dec 2002 06:26: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 QQnrph28785 for ; Tue, 3 Dec 2002 06:26: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 QQnrph24766 for ; Tue, 3 Dec 2002 06:26:25 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 QQnrph09206 for ; Tue, 3 Dec 2002 06:26:24 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dav54.sea2.hotmail.com [207.68.164.47]) id QQnrph09199 for ; Tue, 3 Dec 2002 06:26:24 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 2 Dec 2002 22:26:23 -0800 X-Originating-IP: [64.104.129.137] From: "Rajesh R A" To: , "Mpls \(E-mail\)" References: <001001c29a92$7487e140$fe04a8c0@cyborg> Subject: Re: MPLS Security Date: Tue, 3 Dec 2002 11:56:22 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 03 Dec 2002 06:26:23.0622 (UTC) FILETIME=[E6B47A60:01C29A94] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Mayank, A draft entitled "Analysis of the Security of the MPLS Architecture" is available. http://www.ietf.org/internet-drafts/draft-behringer-mpls-security-03.txt HTH, Rajesh ----- Original Message ----- From: "Mayank Kumar" To: "Mpls (E-mail)" Sent: Tuesday, December 03, 2002 11:38 AM > HI > would somebody tell me if there was a paper or rfc talking about the > security issues of mpls architecture and ways in which it can be handled. i > know of a draft that talks about the security issues of mpls/bgp vpn's and > martini vpn's and compares it security aspects with other layer 2 vpn's > method. i would like to have a paper detailing about the security issues in > the rfc 3031 arch and the signalling protocols used for lsp setup. > any help or useful pointers in this regard will be highly appreciated. > thanks and regards > Mayank > From owner-mpls@UU.NET Tue Dec 3 08:46:44 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 IAA19461 for ; Tue, 3 Dec 2002 08:46:44 -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 QQnrql04348 for ; Tue, 3 Dec 2002 13:49:26 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 QQnrql27736; Tue, 3 Dec 2002 13:46:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrql09187 for mpls-outgoing; Tue, 3 Dec 2002 13:46:03 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 QQnrql09149 for ; Tue, 3 Dec 2002 13:46:01 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 QQnrql23827 for ; Tue, 3 Dec 2002 13:45:58 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 QQnrql26144 for ; Tue, 3 Dec 2002 13:45:57 GMT Received: from tokyo.ccrle.nec.de by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tokyo.ccrle.nec.de [195.37.70.2]) id QQnrql26121 for ; Tue, 3 Dec 2002 13:45:55 GMT Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gB3DjpF93549 for ; Tue, 3 Dec 2002 14:45:51 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id E77B4449F9 for ; Tue, 3 Dec 2002 14:43:53 +0100 (CET) Date: Tue, 03 Dec 2002 14:43:54 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: mpls@UU.NET Subject: MPLS MIB review meeting minutes Message-ID: <18447716.1038926634@[192.168.102.207]> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit The WG-chairs asked me to send the MPLS MIB review meeting minutes to the list. So here they are. Marcus ----------------------------------------- MPLS MIB Review meeting Atlanta, November 16, 2002 ---------------------------------------------- Minute taker: Marcus Brunner Goals of the meeting: -internal consistency of MIBs -check interdependencies and structure -check for commonality and non-overlap -close open issues -gather nits - should be sent to the list Non-goals - not requiremnts meeting - not change everything 0. General Check field name consistency over all MIBs (is not consistent for e.g. framerelay/atm fields Bert) Check all the MIBs about destroying rows and what happens with dangling row pointers. (Problem of referential integrity) E.g.,don't do delayed destroy see ) Check for the general problem of persistent row pointers pointing to non-persistent objects (also affects referential integrity after reboot). Check for split references in normative and non-normative and the other ID-nits. Check for IPR section Check whether Enums start at 1 (otherwise give the reason) Use always Unknown = 1 consistent over all MIBs 1. Management Overview (-02) Add some text about the layering of interfaces. Improves understanding of the dependence of the MIBs. Action: Tom to cut and paste some text. Andrew will rewrite it. Add text to explain the difference between TEWG TE-MIB and the MPLS-TE-MIB. Action: Kireeti has promised some text. Add text where routing information/objects can be found in the MIBs: Action: Sharon to suggest some text to be added to reduce confusion of people new to the MIBs around what's relevant for the various flavors of MPLS. Add some text to help MPLS management application developers. Action: Sharon to look at the overview document and see if it meets the needs of a generic application developer. Add explanation of tunnel instances. Action: Andrew add a paragraph. (Same text might be useful in TE-MIB). 2. LSR-MIB (-09) Add some text about the differences in terminology or newly introduced terminology not available in the base technology (e.g. cross connects and segments). Split references in normative and non-normative and the other ID-nits (not done in this one) Add IPR section (is missing here) Clarifying text why using OutSegmentIndex instead of interface index and label as an index. Issue with Label object/index beeing an octet string, solution will be discussed off-line and proposed on the mailing list. Traffic Parameters table is similar to TE-MIB Resource Table. Proposal: In the LSR-MIB remove the Traffic Parameter Table. Reuse the TE-MIB Resources Table. Change conformance statement in the TE-MIB that the Resource table is mandatory for intermediate LSRs. 3. LDP-MIB (-09) Problem of the semantic of an entity and how to use (add text for clarification) Problem with targeted sessions. It is unclear in the MIB. Might need an additional object for targeted sessions or block the acceptance of the session. Issue on mapping tables/entity table. Potentially putting back the mapping tables, this needs some work (Currently there is a table with entities (might need a direction object) (Joan) The MIB does not allow configuring the transport address for setting up sessions (only tcp port) add an object to entity table. In operational tables some parameters are negotiated. The negotiated values should appear in the MIB. FEC table allows an admin to configure the FECs. It is unclear what this table's semantic is and what the setting of FECs mean. Specifically the problem appear when configuring the table in ingress/egress LSRs. (Probably other table needed) Suggestion for getting the interface specifics better covered (E-Mail from 15. Nov 2002) Compilation problem (it looks likes augmenting two tables at the same time) Bert to send all other compile errors via E-Mail Add ifIndex in session down notification (probably also for session up to make it symmetric) Check whether Enums should start at 1 4. FTN-MIB Problem EXPbit object in the FTN table should be DSCP (in FTNMask and the object name). Use TC from DiffServ MIB for DSCP specification. Change text "protocol id field" into "protocol field" (add reference) Add text about why using address ranges compared to addr and prefix length. mplsFTNRowStatus behaviour for destroy. Proposed: you can not destroy the row until no references is pointing to it anymore. mplsFTNActionType: remove drop action (it is not a firewall) add text why this actions are there. 5. TE-MIB Make AS id work also with 4 byte AS number (Kireeti) Clarify text for the hop tables (3). Specifically explain how the indices are used. Change example IP address (ID-nits) Add text how tunnel instance indices map to protocol fields (LSPid, Tunnel Id), might also be needed in the mgt overview. 6. TC-MIB Problem with tunnel hop address having several object but it is type of a union only some used. Add textual convention for tunnel hop address (use TC from TEWG TE-MIB but use enum starting at 1) Problem with MPLSOwner. Clarify text what modifications means, who is allowed to change what. Unknown = 1 consistent over the whole thing MPLSBitRate define range as [ 0|1..]. MPLSTunnelInstanceIndex might be zero clarify the text and explain why it is a MUST. 7. bundle-mib Change module name of link bundle mib (proposal TE Link MIB). the MIB does not much about bundling. Remove OSPF specifics Check for consistency with base documents (OSPF-TE mainly) 8. GMPLS MIBs Problem of enums that match protocol fields in MIBs. Instruct IANA that they keep it in synch. Operational statistics of mpls how to deal with for optical? Deferred, media specifics in the future releases of the MIBs. Time frame for a new release is one month after MPLS MIB specs are done. -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus From owner-mpls@UU.NET Tue Dec 3 10:04:54 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 KAA24280 for ; Tue, 3 Dec 2002 10:04:54 -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 QQnrqq02160 for ; Tue, 3 Dec 2002 15:07: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 QQnrqq20424; Tue, 3 Dec 2002 15:01:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrqq08978 for mpls-outgoing; Tue, 3 Dec 2002 15:01:24 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 QQnrqq08862 for ; Tue, 3 Dec 2002 15:01:16 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 QQnrqq07895 for ; Tue, 3 Dec 2002 15:00:55 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 QQnrqq19673 for ; Tue, 3 Dec 2002 15:00:55 GMT Received: from nero.doit.wisc.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: nero.doit.wisc.edu [128.104.17.130]) id QQnrqq19654 for ; Tue, 3 Dec 2002 15:00:54 GMT Received: (from jleu@localhost) by nero.doit.wisc.edu (8.11.6/8.11.6) id gB3H3Ke12852; Tue, 3 Dec 2002 11:03:20 -0600 Date: Tue, 3 Dec 2002 11:03:19 -0600 From: "James R. Leu" To: Yongjun Im Cc: Shahram Davari , "'Carlos M. Pignataro'" , mpls-ops@mplsrc.com, mpls@UU.NET, =?iso-8859-1?Q?=C0=E5=C0=E7=BF=B5?= , =?iso-8859-1?Q?=B9=E8=C3=B6=B9=CE?= Subject: Re: Regarding LDP scalability Message-ID: <20021203110319.A12818@nero.doit.wisc.edu> Reply-To: jleu@mindspring.com References: <4B6D09F3B826D411A67300D0B706EFDEB03B1D@nt-exch-yow.pmc-sierra.bc.ca> <01c401c29a86$2fac9590$85289696@lge.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <01c401c29a86$2fac9590$85289696@lge.com>; from yjim@lge.com on Tue, Dec 03, 2002 at 01:41:03PM +0900 Organization: none Sender: owner-mpls@UU.NET Precedence: bulk In January of 2001 I published a draft which addressed this problem. It has since expired. http://www.alternic.org/drafts/drafts-l-m/draft-leu-mpls-ldp-label-aggregation-00.html On Tue, Dec 03, 2002 at 01:41:03PM +0900, Yongjun Im wrote: > I agree it's one of best approaches, described by Shahram below, to reduce > the number of LSP's signalled by LDP. AFAIK, one vednor already support it. > However, in order to support that kind of scheme, it is required that whenever > an LSP is established between two LER's, additional IP subinterface between > an LER and its neighboring LSR, operating IGP, should be installed with respect to > that LSP. Normaly, single IP interface is maintained between an ingress ATM LER > and its adjacent LSR, through MPLS control channel (VPI/VCI=0/32). However, > in order to support the mechanism described below, we have to provide additional > functionality supporting a routing protocol for LSP subinterface, which can be > established or released dynamically. I also believe this mechanim could boil down > to full-mesh IPoA network configuration, requiring PVC's and routing adjacencies > between routers through ATM network. > I'm wondering whether there is any mechanism not requring any change to IP interface > or routing protocol management. > > Yongjun. > > ----- Original Message ----- > From: Shahram Davari > To: 'Carlos M. Pignataro' ; Intae Jung ; mpls-ops@mplsrc.com ; mpls@UU.NET > Sent: Tuesday, December 03, 2002 4:07 AM > Subject: RE: Regarding LDP scalability > > > Here is how you do it: > > Network1 - R1 <-> LER1 <-> LSR1 <-> LSR2 <-> LER2 <-> R2 - Network2 > > <---IP Network---><------------MPLS Network---------><---IP Network---> > > LER1 runs DoD LDP and requests a label for Prefix=LER2 address (LSP12) > LER2 does the same and requests a label for Prefix=LER1 address (LSP21) > LSP12 could be viewed as a single link connecting LER1 and LER2, > and therefore could be advertised (as FA) in IGP. Same thing for LSP21. > Let's say Prefix X is in Network2. LER2 advertises X to all its neigbors > including LSR2 and LER1 (which looks like a neighbor, due to LSP21). > When LER1 is computing the SPF, the shortest path to Network2 is obviously > LER2 via LSP12. > > -Shahram > -----Original Message----- > From: Carlos M. Pignataro [mailto:cpignata@cisco.com] > Sent: Monday, December 02, 2002 10:52 AM > To: Shahram Davari; Intae Jung; mpls-ops@mplsrc.com; mpls@UU.NET > Subject: RE: Regarding LDP scalability > > > Shahram, > > At 07:20 AM 12/2/2002 -0800, Shahram Davari wrote: > > Carlos, > > 1. Run MPLS TE Tunnels between the edge routers and have the edge routers learn these routes through the Tunnel (but you mention only LDP distributing labels). > > Why do we need to run TE. Can't you establish full mesh LSPs between edge routers, by running LDP DoD, only for edge router addresses. > > Normally, in a non-vc-merge environment, an LER will request labels (LDP DoD) for all entries in its routing table. Even if the next hop is the same, different LSPs will be signalled. That's why option 2 summarize the IGP. > > > Then all prefixes could be advertised also inside these LSPs and > be used by ingress LERs. > > How would we do that. An LDP signaled LSP is for a particular FEC. (FEC-Label mapping). New prefix -> new LSP. Check RCF 3031 section 5.1.1.4. PulledConditional and RFC 3035 section 8.1. Edge LSR Behavior. > If LDP signals LSPs for only the edge router addresses, all other prefixes will not use that LSP. > > Regards, > > Carlos. > > > > Yours, > -Shahram > > -----Original Message----- > From: Carlos M. Pignataro [mailto:cpignata@cisco.com] > Sent: Monday, December 02, 2002 9:52 AM > To: Intae Jung; mpls-ops@mplsrc.com; mpls@UU.NET > Subject: Re: Regarding LDP scalability > > Intae, > > > At 12:09 AM 11/30/2002 +0900, Intae Jung wrote: > > Hello, > I'd like to ask a couple of questions regarding a scalability of LDP, > especially when it is deployed in an ATM-LSR, adopting Downstream on > Demand distribution with conservative label retension and ordered control, > where labels (VPI/VCI) are a relatively scarce resource that must be conserved > in ATM switch. The VPI/VCI is a particularly valuable and limited resource that > should be saved when an ATM LSR is not able to support VC-merging capability. > Unfortunately the system I'm managing has no VC-merging capability. > As defined in the standard, LDP attempts to setup or release a hop-by-hop LSP > whenever a new route is added or deleted in an ATM LER through routing protocols, > mainly IGP such as OSPF, ISIS or RIP. > Let me assume a sample ATM-MPLS network as follows. > > Network1 - R1 <-> LER1 <-> LSR1 <-> LSR2 <-> LER2 <-> R2 - Network2 > > <---IP Network---><------------MPLS Network---------><---IP Network---> > > R1, R2: Router operating IGP (OSPF or RIP) > LER1, LER2: Edge ATM LSR operating LDP and IGP (iBGP if needed) > LSR1, LSR2: ATM LSR operating LDP and IGP (OSPF or IS-IS) > > OSPF or RIP is used in the IP Network and OSPF or IS-IS is deployed > in the MPLS Network. An i-BGP session could be setup between LER1 and LER2 > if needed, but not necessarily since LER1 and LER2 are not supposed to provide > BGP/MPLS functionality, in other words, they don't work as a PE(Provider Edge) router. > LER1, LER2, LSR1 and LSR2 support only LDP as an MPLS signaling protocol. > > The problem is that the number of LSP's from LER1 to LER2 increases > as the number of networks increases in the Network2, meaning that the number of > routing entries in LER1 increases accordingly, wherease the number of LSPs supported > by LER1 is a lot smaller than the number of its route entries. > Eventually, as the number of LSPs setup exceeds the maximum number of LSP's, > we'll not be able to setup an LSP any more even though new routes are added. > As I mentioned above, LSR1 and LSR2 don't support VC-merging capability, > thus the scalability becomes quite servere. > Therefore w're trying to figure out how to support a lot of routing entries using > a limited number of LSP's. We are trying to come up with a mechanism that setups > just one LSP between LER1 and LER2, which could be shared between all best-effort > traffic between Network1 and Networks2. > > Some options to reduce the # of LSPs would be: > 1. Run MPLS TE Tunnels between the edge routers and have the edge routers learn these routes through the Tunnel (but you mention only LDP distributing labels). > 2. Summarize the networks on the edge routers (using your IGP). > 3. As you mention, use iBGP. > > Some implementations also improve scalability by allowing an edge router, by configuration, to selects FECs for which to request a label (using DoD), as well as disabling ATM LSRs from requesting labels. > > Thanks, > > Carlos. > > > The problem we faced is how to setup only 1 LSPs between LERs automatically, > and then how to map a lot of route entries to the shared LSP. > Although two LER's are shown in the example, the number of LSP's between LER's > can be quite large as the number of LER's increases. > We're considering to setup a full-mesh iBGP sessions between all LER's, and > to use BGP next hop gateway in order to get an FEC-to-NHFLE mapping. > In other words, routes from Network2 will be redistributed to LER1 via iBGP session > between LER1 and LER2, and then LER1 will setup just one LSP for the BGP next hop > address and map all routes from Network1 to the LSP. > However it enforces us to setup iBGP sessions between all of LER's even though > we don't need them unless we deploy MPLS. We're also wondering whether > we'll be able to solve the problem using any IGP capability, like tag field of AS-external > LSA in OSPF. > > Please enlighten us on this issue. > Any experience or idea will be greatly appreciated. > Thanks in advance. > > Regards, > > Jung. > > ================================================================= > | Carlos Pignataro - CCIE 4619 > cisco Systems, Inc. | Escalation RTP > | cpignata@cisco.com > || || | +1 919 392 7428 - office > .||. .||. | +1 919 345 3028 - mobile > .||||. .||||. | +1 919 392 6470 - fax > .:||||||||:.:||||||||:. | 7025 Kit Creek Road, PO Box 14987 > Are you Ready ? | Research Triangle Park, NC 27709 > ================================================================= > > ================================================================= > | Carlos Pignataro - CCIE 4619 > cisco Systems, Inc. | Escalation RTP > | cpignata@cisco.com > || || | +1 919 392 7428 - office > .||. .||. | +1 919 345 3028 - mobile > .||||. .||||. | +1 919 392 6470 - fax > .:||||||||:.:||||||||:. | 7025 Kit Creek Road, PO Box 14987 > Are you Ready ? | Research Triangle Park, NC 27709 > ================================================================= -- James R. Leu From owner-mpls@UU.NET Tue Dec 3 10:40:27 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 KAA27233 for ; Tue, 3 Dec 2002 10:40:27 -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 QQnrqs11606 for ; Tue, 3 Dec 2002 15:43: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 QQnrqs07563; Tue, 3 Dec 2002 15:41:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrqs25380 for mpls-outgoing; Tue, 3 Dec 2002 15:40:56 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 QQnrqs25359 for ; Tue, 3 Dec 2002 15:40:51 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 QQnrqs18245 for ; Tue, 3 Dec 2002 15:38:43 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 QQnrqs08863 for ; Tue, 3 Dec 2002 15:38:42 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQnrqs08847 for ; Tue, 3 Dec 2002 15:38:42 GMT Received: from cisco.com (erosen-u10.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB3FcSK0016061; Tue, 3 Dec 2002 07:38:29 -0800 (PST) Message-Id: <200212031538.gB3FcSK0016061@sj-msg-core-1.cisco.com> To: "Yongjun Im" cc: "Shahram Davari" , "'Carlos M. Pignataro'" , mpls-ops@mplsrc.com, mpls@UU.NET, =?ks_c_5601-1987?B?wOXA57+1?= , =?ks_c_5601-1987?B?uejDtrnO?= Subject: Re: Regarding LDP scalability In-reply-to: Your message of Tue, 03 Dec 2002 13:41:03 +0900. <01c401c29a86$2fac9590$85289696@lge.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 03 Dec 2002 10:38:28 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Generally the number of VCs which an ATM switch can support is larger than the number of IGP routes, and it's only the IGP routes that need to have labels assigned to them. Are you leaking BGP routes into your IGP? From owner-mpls@UU.NET Tue Dec 3 11:16: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 LAA00095 for ; Tue, 3 Dec 2002 11:16:01 -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 QQnrqv14513 for ; Tue, 3 Dec 2002 16:18: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 QQnrqv11738; Tue, 3 Dec 2002 16:17:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrqv16545 for mpls-outgoing; Tue, 3 Dec 2002 16:16: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 QQnrqv16536 for ; Tue, 3 Dec 2002 16:16:53 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 QQnrqu18275 for ; Tue, 3 Dec 2002 16:14: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 QQnrqu21457 for ; Tue, 3 Dec 2002 16:14:56 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 QQnrqu21441 for ; Tue, 3 Dec 2002 16:14:56 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Dec 2002 11:14:56 -0500 Message-ID: <1117F7D44159934FB116E36F4ABF221B0267ED1B@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'erosen@cisco.com'" , Yongjun Im Cc: Shahram Davari , "'Carlos M. Pignataro'" , mpls-ops@mplsrc.com, mpls@UU.NET, ??? , ??? Subject: RE: Regarding LDP scalability Date: Tue, 3 Dec 2002 11:14:55 -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 Eric (Rosen), As a general "scalability issue", the fact that Yongjun's LSRs do not support VC Merge is problematic - if you assume a large enough IGP*MPLS domain. If all hosts in the network are reached via non-MPLS links, this could result in a very large number of egress points. Further, if the LSR implementations are "lazy", each LSR with non-MPLS interfaces will provide distinct labels for each of those interfaces (rather than using either an implicit or explicit NULL label) to save an IP forwarding lookup. This would further compound the scaling issues introduced as a result of using non VC-merge capable LSRs. You could argue that it is hard to justify implementing an LSR with no VC-merge capability that also is a lazy egress - but this might be justifiable if the network is primarily comprised of ATM switches that have been augmented with LSR functionality and operate in ships in the night mode. In this case, scarcity of labels might also be considerably more pronounced. However, even as a scalability issue, it should not be a major concern. Implementations such as this would be known to have scalability limitations and should, at best, be thought of as a stop-gap interim solution. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Tuesday, December 03, 2002 10:38 AM > To: Yongjun Im > Cc: Shahram Davari; 'Carlos M. Pignataro'; mpls-ops@mplsrc.com; > mpls@UU.NET; ???; ??? > Subject: Re: Regarding LDP scalability > > > Generally the number of VCs which an ATM switch can support is larger > than the number of IGP routes, and it's only the IGP routes that need > to have labels assigned to them. Are you leaking BGP routes into your > IGP? From owner-mpls@UU.NET Tue Dec 3 15:55:06 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 PAA17720 for ; Tue, 3 Dec 2002 15:55:06 -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 QQnrrn10157 for ; Tue, 3 Dec 2002 20:57:31 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 QQnrrn03441; Tue, 3 Dec 2002 20:53:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrrn19820 for mpls-outgoing; Tue, 3 Dec 2002 20:53:29 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 QQnrrn19796 for ; Tue, 3 Dec 2002 20:53: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 QQnrrn29824 for ; Tue, 3 Dec 2002 20:52: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 QQnrrn02407 for ; Tue, 3 Dec 2002 20:52:51 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 QQnrrn02401 for ; Tue, 3 Dec 2002 20:52:51 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB3Kq9vx015346 for ; Tue, 3 Dec 2002 15:53:16 -0500 (EST) 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 JAA07711 for ; Tue, 3 Dec 2002 09:49:32 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB3EnWF23751 for mpls@uu.net; Tue, 3 Dec 2002 09:49:32 -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 QQnrpr16089 for ; Tue, 3 Dec 2002 08:51:52 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 QQnrpr03160 for ; Tue, 3 Dec 2002 08:50:46 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 QQnrpr24836 for ; Tue, 3 Dec 2002 08:50:46 GMT Received: from mailhost.metro-optix.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.219.248.6]) id QQnrpr24831 for ; Tue, 3 Dec 2002 08:50:45 GMT Received: by mailhost.metro-optix.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Dec 2002 02:48:55 -0600 Message-ID: <99EC34181384D611BE56000347227B2C0151FF@MAILHOSTNB> From: Manoj Agiwal To: "'Ccamp (E-mail)" Cc: "'mpls@UU.NET'" , "Gmpls-Ops (E-mail)" Subject: make-before-break in Gmpls Date: Tue, 3 Dec 2002 02:48:25 -0600 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 , The gmpls architecture documents says "GMPLS does not add anything new. Elegant re-routing is possible with the concept of "make-before-break" whereby an old path is still used while a new path is set up by avoiding double reservation of resources. Then, the node performing the re-routing can swap on the new path and close the old path. This feature is supported with RSVP-TE (using shared explicit filters) and CR-LDP (using the action indicator flag). Will this feature will hold good for optical networks as well , where we have TDM , LSC LSPs. This would require use of SE style in optical networks . Does signaling has to take care of not reserving extra resources ( bandwidth / time slot ) across the common path of the two LSPs , what will happen at the nodes where the two routes diverge and converge . Is it expected that the signal will get multicast to both the routes , and at the node where the route converge the signal is selected from the better of the two paths till the rerouted LSP is torn down . Regards, Manoj From owner-mpls@UU.NET Tue Dec 3 15:59:32 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 PAA17978 for ; Tue, 3 Dec 2002 15:59:32 -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 QQnrrn19633 for ; Tue, 3 Dec 2002 20:59: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 QQnrrn14583; Tue, 3 Dec 2002 20:56:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrrn19982 for mpls-outgoing; Tue, 3 Dec 2002 20:56: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 QQnrrn19935 for ; Tue, 3 Dec 2002 20:55:50 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 QQnrrn09821 for ; Tue, 3 Dec 2002 20:54: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 QQnrrn03529 for ; Tue, 3 Dec 2002 20:54:29 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 QQnrrn03517 for ; Tue, 3 Dec 2002 20:54:28 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB3KsoDH016579 for ; Tue, 3 Dec 2002 15:54:50 -0500 (EST) 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 PAA09907 for ; Tue, 3 Dec 2002 15:54:22 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB3KsMB12317 for mpls@uu.net; Tue, 3 Dec 2002 15:54:22 -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 QQnrrn19794 for ; Tue, 3 Dec 2002 20:53: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 QQnrrn00185 for ; Tue, 3 Dec 2002 20:52:59 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 QQnrrn02499 for ; Tue, 3 Dec 2002 20:52:58 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 QQnrrn02489 for ; Tue, 3 Dec 2002 20:52:58 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB3Kq8wL015343; Tue, 3 Dec 2002 15:52:35 -0500 (EST) Received: from shaqzilla.cisco.com (shaqzilla.cisco.com [161.44.135.23]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA10993; Tue, 3 Dec 2002 10:31:29 -0500 (EST) Subject: Re: Message Transmission in GMPLS From: Ashok Narayanan To: Manoj Agiwal Cc: "'Ccamp (E-mail)" , "Gmpls-Ops (E-mail)" , "'mpls@UU.NET'" In-Reply-To: <99EC34181384D611BE56000347227B2C015200@MAILHOSTNB> References: <99EC34181384D611BE56000347227B2C015200@MAILHOSTNB> Content-Type: text/plain Organization: Cisco Systems Message-Id: <1038929488.32113.84.camel@shaqzilla.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.2 (Preview Release) Date: 03 Dec 2002 10:31:29 -0500 Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 2002-12-03 at 03:56, Manoj Agiwal wrote: > Hi , > When RSVP messages are transmitted , what should be the source and > destination IP addresses , should these IP addresses > be that of control plane or should these IP address be Node ID . Some > vendors have chosen GRE tunnel to tunnel Signaling > message across the control plane to the next node . The inside IP address > being that of Nodes while routable address that of > control plane ethernet interface . > This can result in Interop Issues , IETF should enforce using one of > the mechanism , or should the nodes be flexible enough > to expect both . Problem might come where the logic resolves around > Source IP address from where the Signaling message Nodes should be flexible enough to accept both. The use of a stable address (e.g. Router-ID or some shared GRE address) is better in that it reduces messaging in the case of control channel failover. But it needs routing. In any case, the receiving node should accept what it gets. Source address is probably not as relevant for messages that carry HOP objects (like a Path) as the reliable messaging peer is also extracted from there. For messages that don't carry HOP objects the source address may be important; but RFC2961 defines source address behaviour for ACK & SREFRESH messages. With the exception of reliable messaging (perhaps), there should really be no reason to have trouble with any source address of a message. > arrived . > Regards , > Manoj > > From owner-mpls@UU.NET Tue Dec 3 16:00:31 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 QAA18060 for ; Tue, 3 Dec 2002 16:00:31 -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 QQnrro20040 for ; Tue, 3 Dec 2002 21:03:17 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 QQnrrn06052; Tue, 3 Dec 2002 20:55:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrrn19873 for mpls-outgoing; Tue, 3 Dec 2002 20:54:30 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 QQnrrn19852 for ; Tue, 3 Dec 2002 20:54:21 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 QQnrrn03050 for ; Tue, 3 Dec 2002 20:53:59 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 QQnrrn03027 for ; Tue, 3 Dec 2002 20:53:59 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 QQnrrn03016 for ; Tue, 3 Dec 2002 20:53:59 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB3KqAhq015351 for ; Tue, 3 Dec 2002 15:54:16 -0500 (EST) 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 IAA01623 for ; Tue, 3 Dec 2002 08:04:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB3D46p18478 for mpls@uu.net; Tue, 3 Dec 2002 08:04:06 -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 QQnrqi04457 for ; Tue, 3 Dec 2002 13:03:34 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 QQnrqi02942 for ; Tue, 3 Dec 2002 13:03: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 QQnrqi04755 for ; Tue, 3 Dec 2002 13:03:21 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQnrqi04734 for ; Tue, 3 Dec 2002 13:03:20 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17289; Tue, 3 Dec 2002 08:00:30 -0500 (EST) Message-Id: <200212031300.IAA17289@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-ttl-04.txt Date: Tue, 03 Dec 2002 08:00:30 -0500 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 : Time to Live (TTL) Processing in MPLS Networks (Updates RFC 3032) Author(s) : P. Agarwal, B. Akyol Filename : draft-ietf-mpls-ttl-04.txt Pages : 8 Date : 2002-12-2 This document describes TTL processing in hierarchical MPLS networks and is motivated by the need to formalize a TTL-transparent mode of operation for an MPLS label-switched path. It updates RFC-3032 'MPLS Label Stack Encoding'. TTL processing in both pipe and uniform model hierarchical tunnels are specified with examples for both 'push' and 'pop' cases. The document also complements RFC-3270 'MPLS Support of Differentiated Services' and ties together the terminology introduced in that document with TTL processing in hierarchical MPLS networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ttl-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-ttl-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-ttl-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-12-2140147.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ttl-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ttl-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-2140147.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Dec 3 17:02: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 RAA21304 for ; Tue, 3 Dec 2002 17:02:01 -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 QQnrrs27891 for ; Tue, 3 Dec 2002 22:04:50 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 QQnrrs26409; Tue, 3 Dec 2002 22:04:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrrs01251 for mpls-outgoing; Tue, 3 Dec 2002 22:03: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 QQnrrs01228 for ; Tue, 3 Dec 2002 22:03: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 QQnrrs09839 for ; Tue, 3 Dec 2002 22:03: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 QQnrrs13381 for ; Tue, 3 Dec 2002 22:03:42 GMT Received: from ns2.vivacenetworks.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [64.221.212.135]) id QQnrrs13362 for ; Tue, 3 Dec 2002 22:03:41 GMT Received: from AMALIS.vivacenetworks.com ([10.120.0.2]) by vivacenetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 14:03:20 -0800 Message-Id: <5.1.0.14.2.20021203170239.0613f590@po1.vivacenetworks.com> X-Sender: vivacenet\amalis@po1.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 03 Dec 2002 17:03:13 -0500 To: "Adrian Farrel" From: "Andrew G. Malis" Subject: Re: LDP Restart Applicablity Statement - Comments please Cc: "'mpls@uu.net'" In-Reply-To: <002b01c29820$fa957730$ef13588a@movaz.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 03 Dec 2002 22:03:20.0347 (UTC) FILETIME=[CA7BF6B0:01C29B17] Sender: owner-mpls@UU.NET Precedence: bulk Adrian, read it, looks good Cheers, Andy ------ At 11/29/2002 10:31 PM -0500, Adrian Farrel wrote: >Hi, > >I gave a brief overview of draft-farrel0mpls-ldp-restart-applic-01.txt in >Atlanta and asked that it move forward as WG document not least because it was >requested by the chairs and because its existence will help the progress of >draft-ietf-mpls-ldp-ft and draft-ietf-mpls-ldp-restart as they try to become >RFCs. > >It seemed to be the case in Atlanta that very few people had read the >draft and >as Bert has commented elsewhere we should at least get 10 or 20 people to read >drafts before they become WG documents. So... > >I believe implementers of LDP need to give serious consideration to at >least one >of draft-ietf-mpls-ldp-ft and draft-ietf-mpls-ldp-restart. This applicability >statement should help them decide whether and which to implement. > >It would be a great help if all those concerned with LDP could cast an eye >over >the draft and send comments to the mailing list. At the moment, comments such >as "read it, looks good" or "read it, don't like it" would be as useful as >detailed feedback since they will give us some feeling about the value of the >draft. > >Thanks, >Adrian From owner-mpls@UU.NET Tue Dec 3 17:55: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 RAA23635 for ; Tue, 3 Dec 2002 17:55: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 QQnrrv28719 for ; Tue, 3 Dec 2002 22:58: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 QQnrrv24556; Tue, 3 Dec 2002 22:56:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrrv07223 for mpls-outgoing; Tue, 3 Dec 2002 22:55:44 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 QQnrrv07186 for ; Tue, 3 Dec 2002 22: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 QQnrrv14869 for ; Tue, 3 Dec 2002 22:54: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 QQnrrv07799 for ; Tue, 3 Dec 2002 22:54:08 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 QQnrrv07785 for ; Tue, 3 Dec 2002 22:54:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB3MsYJ3007608 for ; Tue, 3 Dec 2002 17:54:34 -0500 (EST) 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 RAA21068 for ; Tue, 3 Dec 2002 17:54:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB3Ms6D25756 for mpls@uu.net; Tue, 3 Dec 2002 17:54:06 -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 QQnrrv07011 for ; Tue, 3 Dec 2002 22:52:37 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 QQnrrv05458 for ; Tue, 3 Dec 2002 22:51:37 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 QQnrrv04225 for ; Tue, 3 Dec 2002 22:51:37 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 QQnrrv04214 for ; Tue, 3 Dec 2002 22:51:36 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB3Mq37g007311 for ; Tue, 3 Dec 2002 17:52:03 -0500 (EST) 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 RAA20896 for ; Tue, 3 Dec 2002 17:51:35 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA01985 for ; Tue, 3 Dec 2002 17:51:34 -0500 (EST) Message-Id: <200212032251.RAA01985@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Subject: Last call on LSP Ping Date: Tue, 03 Dec 2002 17:51:34 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk This message begins a workgroup last call on: Detecting MPLS Data Plane Liveness draft-ietf-mpls-lsp-ping-01.txt The last call ends on Dec 16, 2002 2400H GMT. George & Loa ====================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Tue Dec 3 17:57:56 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 RAA23739 for ; Tue, 3 Dec 2002 17:57:56 -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 QQnrrw11223 for ; Tue, 3 Dec 2002 23:00: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 QQnrrv26955; Tue, 3 Dec 2002 22:53:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrrv07023 for mpls-outgoing; Tue, 3 Dec 2002 22:52: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 QQnrrv07013 for ; Tue, 3 Dec 2002 22:52: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 QQnrrv20168 for ; Tue, 3 Dec 2002 22:52: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 QQnrrv04949 for ; Tue, 3 Dec 2002 22:52:09 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 QQnrrv04931 for ; Tue, 3 Dec 2002 22:52:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB3MqYQT007348 for ; Tue, 3 Dec 2002 17:52:34 -0500 (EST) 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 RAA20926 for ; Tue, 3 Dec 2002 17:52:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB3Mq5T25659 for mpls@uu.net; Tue, 3 Dec 2002 17:52:05 -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 QQnrrv06827 for ; Tue, 3 Dec 2002 22:51:16 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 QQnrrv16233 for ; Tue, 3 Dec 2002 22:50: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 QQnrrv01553 for ; Tue, 3 Dec 2002 22:50:02 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 QQnrrv01521 for ; Tue, 3 Dec 2002 22:49:58 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB3MoPnA007021 for ; Tue, 3 Dec 2002 17:50:25 -0500 (EST) 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 RAA20696 for ; Tue, 3 Dec 2002 17:49:56 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA01896 for ; Tue, 3 Dec 2002 17:49:56 -0500 (EST) Message-Id: <200212032249.RAA01896@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Subject: Last Call on Fast Reroute Date: Tue, 03 Dec 2002 17:49:56 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk This message begins a workgroup last call on: Fast Reroute Extensions to RSVP-TE for LSP Tunnels draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt The last call ends on Dec 16, 2002 2400H GMT. George & Loa ====================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Tue Dec 3 18:10:10 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 SAA24135 for ; Tue, 3 Dec 2002 18:10:10 -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 QQnrrw23620 for ; Tue, 3 Dec 2002 23:12:54 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 QQnrrw18675; Tue, 3 Dec 2002 23:10:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrrw26624 for mpls-outgoing; Tue, 3 Dec 2002 23:10: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 QQnrrw26610 for ; Tue, 3 Dec 2002 23:10:02 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 QQnrrw07941 for ; Tue, 3 Dec 2002 23:09: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 QQnrrw01713 for ; Tue, 3 Dec 2002 23:09:08 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 QQnrrw01708 for ; Tue, 3 Dec 2002 23:09:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB3N9Y3N009481 for ; Tue, 3 Dec 2002 18:09:34 -0500 (EST) 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 SAA22031 for ; Tue, 3 Dec 2002 18:09:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB3N96500368 for mpls@uu.net; Tue, 3 Dec 2002 18:09:06 -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 QQnrrw26423 for ; Tue, 3 Dec 2002 23:08:21 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 QQnrrw02838 for ; Tue, 3 Dec 2002 23:07: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 QQnrrw14277 for ; Tue, 3 Dec 2002 23:07:37 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 QQnrrw14272 for ; Tue, 3 Dec 2002 23:07:37 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23952; Tue, 3 Dec 2002 18:04:43 -0500 (EST) Message-Id: <200212032304.SAA23952@ietf.org> To: IETF-Announce:; Cc: RFC Editor , Internet Architecture Board , mpls@UU.NET From: The IESG Subject: Protocol Action: Signalling Unnumbered Links in RSVP-TE to Proposed Standard Date: Tue, 03 Dec 2002 18:04:43 -0500 Sender: owner-mpls@UU.NET Precedence: bulk The IESG has approved the Internet-Draft Signalling Unnumbered Links in RSVP-TE as a Proposed Standard. This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Bert Wijnen and Scott Bradner. Technical Summary Supporting MPLS TE over unnumbered links (i.e., links that do not have IP addresses) involves two components: (a) the ability to carry (TE) information about unnumbered links in IGP TE extensions (ISIS or OSPF), and (b) the ability to specify unnumbered links in MPLS TE signalling. The former is covered in other documents. The focus of this document is on the latter. Current signalling used by MPLS TE doesn't provide support for unnumbered links because the current signalling doesn't provide a way to indicate an unnumbered link in its Explicit Route and Record Route Objects. This document defines simple procedures and extensions that allow RSVP-TE signalling [GMPLS-RSVP] to be used with unnumbered links. Working Group Summary The MPLS working group supported publication of this document. Protocol Quality This document was reviewed for the IESG by Scott Bradner. RFC Editor Note: In section 5 replace An unnumbered link has to be a point-to-point link. An LSR at each end of an unnumbered link assigns an identifier to that link. This identifier is a non-zero 32-bit number that is unique within the scope of the LSR that assigns it. The IS-IS and/or OSPF and RSVP modules on an LSR must agree on the identifiers. with An unnumbered link has to be a point-to-point link. An LSR at each end of an unnumbered link assigns an identifier to that link. This identifier is a non-zero 32-bit number that is unique within the scope of the LSR that assigns it. If one is using OSPF or ISIS as the IGP in support of traffic engineering, then the IS-IS and/or OSPF and RSVP modules on an LSR must agree on the identifiers. In section 5 replace In the context of this document the term "Router ID" refers to the "Router Address" as defined in [OSPF-TE], or "Traffic Engineering Router ID" as defined in [ISIS-TE]. with In the context of this document the term "Router ID" means a stable IP address of an LSR that is always reachable if there is any connectivity to the LSR. This is typically implemented as a "loopback address"; the key attribute is that the address does not become unusable if an interface on the LSR is down. In some case this value will need to be configured. If one is using OSPF or ISIS as the IGP in support of traffic engineering, then it is RECOMMENDED to set the Router ID to the "Router Address" as defined in [OSPF-TE], or "Traffic Engineering Router ID" as defined in [ISIS-TE]. From owner-mpls@UU.NET Tue Dec 3 18:18:26 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 SAA24472 for ; Tue, 3 Dec 2002 18:18:26 -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 QQnrrx11322 for ; Tue, 3 Dec 2002 23:21:02 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 QQnrrx03774; Tue, 3 Dec 2002 23:17:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrrx28252 for mpls-outgoing; Tue, 3 Dec 2002 23:16:44 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 QQnrrx28244 for ; Tue, 3 Dec 2002 23:16:38 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 QQnrrx27115 for ; Tue, 3 Dec 2002 23:16:23 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 QQnrrx11225 for ; Tue, 3 Dec 2002 23:16:22 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 QQnrrx11202 for ; Tue, 3 Dec 2002 23:16:22 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB3NGnG0010262 for ; Tue, 3 Dec 2002 18:16:49 -0500 (EST) 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 SAA22577 for ; Tue, 3 Dec 2002 18:16:21 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB3NGKo01382 for mpls@uu.net; Tue, 3 Dec 2002 18:16:20 -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 QQnrrw27650 for ; Tue, 3 Dec 2002 23:14: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 QQnrrw22130 for ; Tue, 3 Dec 2002 23:14: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 QQnrrw26421 for ; Tue, 3 Dec 2002 23:14:23 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 QQnrrw26349 for ; Tue, 3 Dec 2002 23:14:21 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24186; Tue, 3 Dec 2002 18:11:11 -0500 (EST) Message-Id: <200212032311.SAA24186@ietf.org> To: IETF-Announce:; Cc: RFC Editor , Internet Architecture Board , mpls@UU.NET From: The IESG Subject: Protocol Action: Link Bundling in MPLS Traffic Engineering to Proposed Standard Date: Tue, 03 Dec 2002 18:11:11 -0500 Sender: owner-mpls@UU.NET Precedence: bulk ------------- The IESG has approved the Internet-Draft Link Bundling in MPLS Traffic Engineering as a Proposed Standard. This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Bert Wijnen and Scott Bradner. Technical Summary A MPLS Traffic Engineering (TE) link is a logical construct that represents a way to group/map the information about certain physical resources (and their properties) that interconnect Label Switch Routers into the information that is used by Constrained SPF for the purpose of path computation, and by GMPLS signaling. Depending on the nature of resources that form a particular MPLS TE link, for the purpose of GMPLS signaling in some cases a combination of is sufficient to unambiguously identify the appropriate resource used by an Label Switched Path. In other cases, a combination of is not sufficient. The latter cases are handled by using the link bundling construct that is described in this document. Working Group Summary The MPLS working group supported publication of this document. Protocol Quality This document was reviewed for the IESG by Scott Bradner. RFC Editor: Insert the following paragraph after the second paragraph in Section 4 (Link Bundling): As an example consider a TE link between a pair of SONET/SDH cross connects, where this TE link is composed of several fibers. In this case the label is a TDM time slot, and moreover, this time slot is significant only within a particular fiber. Thus, when signaling an LSP over such a TE link, one needs to specify not just the identity of the link, but also the identity of a particular fiber within that TE link, as well as a particular label (time slot) within that fiber. From owner-mpls@UU.NET Tue Dec 3 18:53: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 SAA25673 for ; Tue, 3 Dec 2002 18:53:36 -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 QQnrrz04156 for ; Tue, 3 Dec 2002 23:56: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 QQnrrz29480; Tue, 3 Dec 2002 23:53:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrrz01130 for mpls-outgoing; Tue, 3 Dec 2002 23:53:37 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 QQnrrz01125 for ; Tue, 3 Dec 2002 23:53:36 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 QQnrrz27690 for ; Tue, 3 Dec 2002 23:52: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 QQnrrz02035 for ; Tue, 3 Dec 2002 23:52:50 GMT Received: from mail1.lge.co.kr by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [156.147.1.151]) id QQnrrz01980 for ; Tue, 3 Dec 2002 23:52:49 GMT Received: from lgekrhqmh01.lge.com (lgekrhqmh01.lge.com [156.147.51.51]) by mail1.lge.co.kr (8.11.3/8.11.3) with ESMTP id gB3NpRA12712; Wed, 4 Dec 2002 08:51:27 +0900 (KST) Received: from yongjuni ([150.150.40.133]) by lgekrhqmh01.lge.com (Lotus Domino Release 5.0.9a) with SMTP id 2002120408565026:1536513 ; Wed, 4 Dec 2002 08:56:50 +0900 Message-ID: <00e801c29b26$f8e07f80$85289696@lge.com> Reply-To: "Yongjun Im" From: "Yongjun Im" To: Cc: "Shahram Davari" , "'Carlos M. Pignataro'" , , , =?iso-8859-1?B?wOXA57+1?= , =?iso-8859-1?B?uejDtrnO?= References: <200212031538.gB3FcSK0016061@sj-msg-core-1.cisco.com> Subject: Re: Regarding LDP scalability Date: Wed, 4 Dec 2002 08:51:59 +0900 Organization: LG Electronics, Inc. MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MIMETrack: Itemize by SMTP Server on LGEKRHQMH01/LGE/LG Group(Release 5.0.9a |January 7, 2002) at 12/04/2002 08:56:50 AM, Serialize by Router on LGEKRHQMH01/LGE/LG Group(Release 5.0.9a |January 7, 2002) at 12/04/2002 08:56:51 AM 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 SAA25673 It could be true, but the number of VCs per PORT/LINK which an ATM switch can support could be a lot smaller than the number of IGP routes, which could share the same next hop link to an LSR. In addition, it simply cannot be assumed that IGP routes only need to have labels assigned to them, since eBGP routes from an LER can be redistributed into an iBGP peer that is another LER. As you stated, it is well known that BGP routes are seldom redisributed into IGP. Yongjun. ----- Original Message ----- From: "Eric Rosen" To: "Yongjun Im" Cc: "Shahram Davari" ; "'Carlos M. Pignataro'" ; ; ; "ÀåÀ翵" ; "¹èö¹Î" Sent: Wednesday, December 04, 2002 12:38 AM Subject: Re: Regarding LDP scalability Generally the number of VCs which an ATM switch can support is larger than the number of IGP routes, and it's only the IGP routes that need to have labels assigned to them. Are you leaking BGP routes into your IGP? From owner-mpls@UU.NET Tue Dec 3 19:19: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 TAA26587 for ; Tue, 3 Dec 2002 19:19:51 -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 QQnrsb19106 for ; Wed, 4 Dec 2002 00:22:30 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 QQnrsb13851; Wed, 4 Dec 2002 00:19:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrsb21786 for mpls-outgoing; Wed, 4 Dec 2002 00:19:24 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 QQnrsb21779 for ; Wed, 4 Dec 2002 00:19:23 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 QQnrsb15953 for ; Wed, 4 Dec 2002 00:19: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 QQnrsb10940 for ; Wed, 4 Dec 2002 00:19:22 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 QQnrsb10930 for ; Wed, 4 Dec 2002 00:19:22 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB40JmDV016169 for ; Tue, 3 Dec 2002 19:19:49 -0500 (EST) 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 TAA26532 for ; Tue, 3 Dec 2002 19:19:20 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB40JKr07564 for mpls@uu.net; Tue, 3 Dec 2002 19:19:20 -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 QQnrsb21714 for ; Wed, 4 Dec 2002 00:18:03 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 QQnrsb06851 for ; Wed, 4 Dec 2002 00:15: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 QQnrsb05957 for ; Wed, 4 Dec 2002 00:15:41 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 QQnrsb05945 for ; Wed, 4 Dec 2002 00:15: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 TAA26389; Tue, 3 Dec 2002 19:12:49 -0500 (EST) Message-Id: <200212040012.TAA26389@ietf.org> To: IETF-Announce:; Cc: mpls@UU.NET From: The IESG SUBJECT: Last Call: Improving Topology Data Base Accuracy with Label Switched Path Feedback in Constraint Based Label Distribution Protocol to Proposed Standard Reply-to: iesg@ietf.org Date: Tue, 03 Dec 2002 19:12:49 -0500 Sender: owner-mpls@UU.NET Precedence: bulk The IESG has received a request from the Multiprotocol Label Switching Working Group to consider Improving Topology Data Base Accuracy with Label Switched Path Feedback in Constraint Based Label Distribution Protocol 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-12-17. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-05.txt From owner-mpls@UU.NET Tue Dec 3 20:34:30 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 UAA28956 for ; Tue, 3 Dec 2002 20:34:30 -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 QQnrsg18850 for ; Wed, 4 Dec 2002 01:37: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 QQnrsg17160; Wed, 4 Dec 2002 01:36:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrsg16199 for mpls-outgoing; Wed, 4 Dec 2002 01:35:57 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 QQnrsg16194 for ; Wed, 4 Dec 2002 01:35:49 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 QQnrsg17067 for ; Wed, 4 Dec 2002 01:35: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 QQnrsg11664 for ; Wed, 4 Dec 2002 01:35:01 GMT Received: from mail.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc250.alcatel.be [195.207.101.250]) id QQnrsg11627 for ; Wed, 4 Dec 2002 01:35:00 GMT Received: from bemail05.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id gB41YqE05242; Wed, 4 Dec 2002 02:34:52 +0100 Received: from alcatel.be ([138.203.64.17]) by bemail05.net.alcatel.be (Lotus Domino Release 5.0.9a) with ESMTP id 2002120402345036:452 ; Wed, 4 Dec 2002 02:34:50 +0100 Message-ID: <3DED5C9E.A4679846@alcatel.be> Date: Wed, 04 Dec 2002 02:38:38 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: Optical Network Architecture (NTA - Antwerpen) X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Manoj Agiwal Cc: "'Ccamp (E-mail)" , "'mpls@UU.NET'" Subject: Re: make-before-break in Gmpls References: <99EC34181384D611BE56000347227B2C0151FF@MAILHOSTNB> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.9a |January 7, 2002) at 12/04/2002 02:34:50, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.9a |January 7, 2002) at 12/04/2002 02:34:52, Serialize complete at 12/04/2002 02:34:52 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit hi, i think this issue concerning "se style" has been discussed some time ago but let's try here to give a bit more details, lsp's in gmpls are control plane entities mapping data plane ones, merging here does get sense if and only if the data plane would deliver the same capability, since the soft- provisioning that we can expect in shared meshed restoration is purely a control plane driven mechanism the corresponding entity doesn't occur at the data plane level and in particular for tdm, lsc and fsc lsp's, once committed you find out the ff style as used today, as such there is no today something like you seem to assume as setup of an lsp "split" it when a recovery lsp is needed and then "merge" it back when the recovery lsp find back the working lsp path, then next even if the methods that are under definition may be thought as similar to the frr ones, the following for instance wouldn't strictly apply (see fast-reroute): "When using the sender-template-specific approach, the protected LSPs and the backup paths SHOULD use the Shared Explicit (SE) style. This allows bandwidth sharing between multiple backup paths. The backup paths and the protected LSP MAY be merged by the Detour Merge Points, when the ERO from the MP to the egress is the same on each LSP to be merged, as specified in [RSVP-TE]." this because for non-packet networks do soft-provisioning means let the capability to share the bandwidth on a control plane view of the resource basis otherwise just provision it (commit it) since having a dedicated soft-provisioning on a per lsp basis just means be dedicated at the data plane level (if we assume a consistent usage of the mechanisms), and on the other side have merging (not multiplexing) of lsc or tdm at the data plane level is impossible (afaik) thus the fact that one knows that the requested lsp is for recovery purposes (link protection tlv s bit set) and its resources have to allocated within a pool but not committed (ie reserved) something which is needed in any case, do the job here. hope this clarifies a bit, - dimitri. Manoj Agiwal wrote: > > Hi , > The gmpls architecture documents says > "GMPLS does not add anything new. Elegant re-routing is possible with the > concept of "make-before-break" whereby an old path is still used while a new > path is set up by avoiding double reservation of resources. Then, the node > performing the re-routing can swap on the new path and close the old path. > This feature is supported with RSVP-TE (using shared explicit filters) and > CR-LDP (using the action indicator flag). > Will this feature will hold good for optical networks as well , > where we have TDM , LSC LSPs. This would require use of > SE style in optical networks . Does signaling has to take care of not > reserving extra resources ( bandwidth / time slot ) > across the common path of the two LSPs , what will happen at the nodes > where the two routes diverge and converge . > Is it expected that the signal will get multicast to both the routes , > and at the node where the route converge the signal > is selected from the better of the two paths till the rerouted LSP is > torn down . > Regards, > Manoj -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : Work: +32 3 2408491 - Home: +32 2 3434361 From owner-mpls@UU.NET Wed Dec 4 00:12:41 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 AAA03843 for ; Wed, 4 Dec 2002 00:12:40 -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 QQnrsv16154 for ; Wed, 4 Dec 2002 05:15: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 QQnrsu12071; Wed, 4 Dec 2002 05:10:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrsu15807 for mpls-outgoing; Wed, 4 Dec 2002 05:09:58 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 QQnrsu15801 for ; Wed, 4 Dec 2002 05:09:51 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 QQnrsu13007 for ; Wed, 4 Dec 2002 05:09: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 QQnrsu10519 for ; Wed, 4 Dec 2002 05:09:31 GMT Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQnrsu10482 for ; Wed, 4 Dec 2002 05:09:29 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 10:47:54 +0530 Message-ID: <55E277B99171E041ABF5F4B1C6DDCA06DF954F@haritha.hclt.com> From: "Vijayanand C - CTD, Chennai." To: mpls@UU.NET Cc: manis@futsoft.com Subject: FW: I-D ACTION:draft-vijay-mpls-rsvpte-lspsubobject-01.txt Date: Wed, 4 Dec 2002 10:41:43 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C29B53.A2B5CED0" 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_01C29B53.A2B5CED0 Content-Type: text/plain; charset="iso-8859-1" Hello all, Request your comments and feedbacks on the attached draft. Thanks and Regards Vijay "Where protocols are a passion, MPLS is a religion " -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, December 03, 2002 6:29 PM Subject: I-D ACTION:draft-vijay-mpls-rsvpte-lspsubobject-01.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-01.txt Pages : 8 Date : 2002-12-2 This document describes the use of 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-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-vijay-mpls-rsvpte-lspsubobject-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-vijay-mpls-rsvpte-lspsubobject-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_000_01C29B53.A2B5CED0 Content-Type: message/rfc822 To: Subject: Date: Tue, 3 Dec 2002 21:15:14 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C29B53.A2B5CED0" ------_=_NextPart_002_01C29B53.A2B5CED0 Content-Type: text/plain ------_=_NextPart_002_01C29B53.A2B5CED0 Content-Type: application/octet-stream; name="ATT04018.txt" Content-Disposition: attachment; filename="ATT04018.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-12-2135921.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-vijay-mpls-rsvpte-lspsubobject-01.txt ------_=_NextPart_002_01C29B53.A2B5CED0 Content-Type: message/external-body; site="internet-drafts"; dir="draft-vijay-mpls-rsvpte-lspsubobject-01.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C29B53.A2B5CED0-- ------_=_NextPart_000_01C29B53.A2B5CED0-- From owner-mpls@UU.NET Wed Dec 4 03:00: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 DAA01474 for ; Wed, 4 Dec 2002 03:00:55 -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 QQnrtg21809 for ; Wed, 4 Dec 2002 08:03:39 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 QQnrtg17292; Wed, 4 Dec 2002 08:01:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrtg13049 for mpls-outgoing; Wed, 4 Dec 2002 08:01: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 QQnrtg12428 for ; Wed, 4 Dec 2002 08:01:13 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 QQnrtg26523 for ; Wed, 4 Dec 2002 08:00:28 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 QQnrtg16189 for ; Wed, 4 Dec 2002 08:00:28 GMT Received: from mailhost.metro-optix.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.219.248.6]) id QQnrtg16172 for ; Wed, 4 Dec 2002 08:00:28 GMT Received: by mailhost.metro-optix.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 01:58:33 -0600 Message-ID: <99EC34181384D611BE56000347227B2C01EB38@MAILHOSTNB> From: Apratim Mukherjee To: "'Ccamp (E-mail)" , "'mpls@UU.NET'" Subject: Source IP Address in GMPLS messages Date: Wed, 4 Dec 2002 01:57:50 -0600 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 These are the lines from RFC 2961 for refresh reduction . "The source IP address of an Srefresh message is an address of the node that generates the message. The source IP address MUST match the address associate with the MESSAGE_ID objects when they were included in a standard RSVP message. As previously mentioned, the source address associated with a MESSAGE_ID object is represented in a per RSVP message type specific fashion. For messages with RSVP_HOP objects, such as Path and Resv messages, the address is found in the RSVP_HOP object." In a gmpls network , for a node with multiple interfaces say with address a1,a2,a3 and a node ip a,if the node is sending address a1 as the address in the control channel part of PHOP in Path message , does the above lines make it a MUST for that node to also send a1 as the source IP for the SRefresh message corresponding to that Path message ? ( This is assuming that it is NOT using 'a' as the source IP , in which case we dont have a problem ) Or should we be ready to get the Path message with 'a1' as the ip address in the control channel part of PHop and subsequently , the SRefresh corresponding to this path message with say a2 or even 'a' as the node ip ? Thanks a lot , Apratim From owner-mpls@UU.NET Wed Dec 4 06:12: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 GAA06073 for ; Wed, 4 Dec 2002 06:12:52 -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 QQnrtt12584 for ; Wed, 4 Dec 2002 11:15: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 QQnrts07842; Wed, 4 Dec 2002 11:12:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrts02959 for mpls-outgoing; Wed, 4 Dec 2002 11:12:27 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 QQnrts02954 for ; Wed, 4 Dec 2002 11:12:23 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 QQnrts04735 for ; Wed, 4 Dec 2002 11:12: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 QQnrts28570 for ; Wed, 4 Dec 2002 11:12:09 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 QQnrts28539 for ; Wed, 4 Dec 2002 11:12:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB4BCYuN003298 for ; Wed, 4 Dec 2002 06:12:34 -0500 (EST) 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 GAA26466 for ; Wed, 4 Dec 2002 06:12:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB4BC5410401 for mpls@uu.net; Wed, 4 Dec 2002 06:12:05 -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 QQnrts02862 for ; Wed, 4 Dec 2002 11:11:10 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 QQnrts29448 for ; Wed, 4 Dec 2002 11:10:14 GMT From: Roberto.Guglielmi@alcatel.it 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 QQnrts03583 for ; Wed, 4 Dec 2002 11:10:14 GMT Received: from tlvsca.vim.tlt.alcatel.it by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [194.243.74.245]) id QQnrts03564 for ; Wed, 4 Dec 2002 11:10:13 GMT Received: from itmail02.prod.alcatel.it (localhost [127.0.0.1]) by tlvsca.vim.tlt.alcatel.it (8.12.5/8.12.5) with ESMTP id gB4BA0rt003614 for ; Wed, 4 Dec 2002 12:10:01 +0100 (MET) Received: from alcatel.it ([151.98.36.75]) by itmail02.prod.alcatel.it (Lotus Domino Release 5.0.8) with ESMTP id 2002120412121439:2213 ; Wed, 4 Dec 2002 12:12:14 +0100 Message-ID: <3DEDE0EA.3000909@alcatel.it> Date: Wed, 04 Dec 2002 12:03:06 +0100 User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@UU.NET Subject: Question about lsp hierarchy X-MIMETrack: Itemize by SMTP Server on ITMAIL02/IT/ALCATEL(Release 5.0.8 |June 18, 2001) at 12/04/2002 12:12:14, Serialize by Router on ITMAIL02/IT/ALCATEL(Release 5.0.8 |June 18, 2001) at 12/04/2002 12:12:15, Serialize complete at 12/04/2002 12:12:15 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, draft-ietf-mpls-lsp-hierarchy-08.txt, paragraph 8.1.1. RSVP-TE states: "...An alternative method is to encapsulate the Path message in an IP tunnel (or, in the case that the Interface Switching Capability of the FA-LSP is PSC[1-4], in the FA-LSP itself), and unicast the message to the tail end of the FA-LSP, without the Router Alert option..." while paragraph 8.1.2. CR-LDP states: "...Furthermore, the head end LSR must create a targetted LDP session with the tail end LSR. The Request (Mapping) message is unicast from the head end (tail end) to the tail end (head end)..." Are CR-LDP messages unicast to the tail end in the FA-LSP itself? That is, can they be encapsulated in MPLS to get to the targetted LDP peer? Thanks for your help. Regards Roberto From owner-mpls@UU.NET Wed Dec 4 07:52:41 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 HAA08401 for ; Wed, 4 Dec 2002 07:52:41 -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 QQnrtz22152 for ; Wed, 4 Dec 2002 12:55:29 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 QQnrtz09276; Wed, 4 Dec 2002 12:49:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrtz28611 for mpls-outgoing; Wed, 4 Dec 2002 12:48: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 QQnrtz28597 for ; Wed, 4 Dec 2002 12:48:32 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 QQnrtz12687 for ; Wed, 4 Dec 2002 12:48: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 QQnrtz07625 for ; Wed, 4 Dec 2002 12:48:09 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 QQnrtz07616 for ; Wed, 4 Dec 2002 12:48:08 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB4CmYlg009301 for ; Wed, 4 Dec 2002 07:48:35 -0500 (EST) 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 HAA29840 for ; Wed, 4 Dec 2002 07:48:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB4Cm6016521 for mpls@uu.net; Wed, 4 Dec 2002 07:48:06 -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 QQnrtz28498 for ; Wed, 4 Dec 2002 12:46:43 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 QQnrtz19591 for ; Wed, 4 Dec 2002 12:45:52 GMT From: Roberto.Guglielmi@alcatel.it 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 QQnrtz05798 for ; Wed, 4 Dec 2002 12:45:52 GMT Received: from tlvsdy.vim.tlt.alcatel.it by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [194.243.74.244]) id QQnrtz05762 for ; Wed, 4 Dec 2002 12:45:51 GMT Received: from itmail02.prod.alcatel.it (localhost [127.0.0.1]) by tlvsdy.vim.tlt.alcatel.it (8.12.5/8.12.5) with ESMTP id gB4Cm7of027672 for ; Wed, 4 Dec 2002 13:48:07 +0100 (MET) Received: from alcatel.it ([151.98.36.75]) by itmail02.prod.alcatel.it (Lotus Domino Release 5.0.8) with ESMTP id 2002120413474794:2788 ; Wed, 4 Dec 2002 13:47:47 +0100 Message-ID: <3DEDF74F.1020700@alcatel.it> Date: Wed, 04 Dec 2002 13:38:39 +0100 User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@UU.NET Subject: TTL processing in Ethernet Pseudowire X-MIMETrack: Itemize by SMTP Server on ITMAIL02/IT/ALCATEL(Release 5.0.8 |June 18, 2001) at 12/04/2002 13:47:48, Serialize by Router on ITMAIL02/IT/ALCATEL(Release 5.0.8 |June 18, 2001) at 12/04/2002 13:47:49, Serialize complete at 12/04/2002 13:47:49 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, An Ethernet Pseudowire (PW) allows Ethernet frames to be carried over MPLS. In this scenario, Ethernet frames entering the MPLS network should be encapsulated with a stack of 2 labels: the top label being the one transporting the packet to the end of the network; the bottom label being the VC label identifying the flow. I have the following questions regarding TTL values: 1) The obsolete draft-martini-l2circuit-encap-mpls-04 states: "The ingress LSR, R1, SHOULD set the TTL field of the VC label to a value of 2." Is this still valid? 2) What should the TTL be for the outer label? Where is it inferred from? 3) How does the outer TTL have to be processed in the core nodes? Should it be decremented at every node? Can it be decremented only by 1, seeing the entire MPLS network as a single hop? Thanks for your help. Regards Roberto From owner-mpls@UU.NET Wed Dec 4 11:04:13 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 LAA18680 for ; Wed, 4 Dec 2002 11:04:12 -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 QQnrum09673 for ; Wed, 4 Dec 2002 16:06: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 QQnrum03431; Wed, 4 Dec 2002 16:03:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrum19913 for mpls-outgoing; Wed, 4 Dec 2002 16:03:34 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 QQnrum19775 for ; Wed, 4 Dec 2002 16:03:33 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 QQnrum05447 for ; Wed, 4 Dec 2002 16:02: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 QQnrum06090 for ; Wed, 4 Dec 2002 16:02:54 GMT Received: from zcars04e.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQnrum06075 for ; Wed, 4 Dec 2002 16:02:53 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 gB4G2bv23709 for ; Wed, 4 Dec 2002 11:02:37 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 11:02:37 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C06565472@zcard031.ca.nortel.com> From: "David Allan" To: mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Wed, 4 Dec 2002 11:02:36 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Hi: I have a concern with the draft. Embedded in the protocol are a number of features designed to test proprietary behaviors (load balancing). How these would be used IMHO is insufficiently well documented to ensure interoperability. On that basis I do not think the document is ready. One specific example that come to mind is the description of "downstream router". I consider to be poorly explained. Now the text: "a packet with outermost label L and TTL n>1 arrives at X"..... OK "X must be able to compute which LSRs could receive the packet with TTL=n+1" whoa, where the packet came from? I thought TTL decremented. I presume the correct text should be "what LSRs would receive the packet if forwarded from X with TTL=1". "the set of LSRs are the downstream routers....for X with respect to L", So what are we discussing here, the LSRs upstream of X, downstream of X, the specific NHLFE that load balancing resolves to given the specific details of the packet (src address and 127./8 and whatever else the propretary implementation considers) or the set that the FTN/ILM maps to prior to any actual load balancing computations (is it "a" packet or "any" packet mapping to the FEC associated with the LSP). If the intent is to provide a mechanism to fully exercise any and all potential load balancing configurations and to understand what configurations were tested, this would appear to come up short. When attempting to traceroute such a configuration, the LSR originating the trace either: - knows there is a problem and knows what specific 127./8 will supposedly reproduce the problem but knows little else about the network. - knows there is a problem but may not know what specific 127./8 will reproduce it, therefore wishes to exercise all possibilities AND needs to be able to verify that it did so. Therefore there is an element of "topology discovery" inherent to performing such a traceroute. - there may not be a problem but the LSR wishes to exercise the whole downstream construct anyway. Given the description, and the ambiguities in the text, it is not clear to me what I could build and successfully interoperate with the LSR next door.... BTW it would be useful to explicitly state in 3.2 that the downstream mapping TLV is only valid in "traceroute mode", and that it is optional in echo requests, and mandatory in echo replies. Other minor comments: - won't claim to be an expert, would TTL exhaust on an internal loopback address generate an ICMP message back to the ping originator (which it should be ignoring)? - downstream mapping permits multiple labels per interface to be described in an echo request, but the reply can only indicate that "it arrived on one of them" rather than which specific one (which may matter). IMHO it would be useful to have the sequence number explicitly correspond to the LSB of the 127./8 used as I would presume otherwise the echo request originating LSR would need to remember such details associated with the sequence number (as the reply would not contain the address). (I'm assuming that the sequence number is used uniquely with the LSP under test, and the handle exists as the indexing mechanism for replies independent of the specific LSP under consideration). T'would also facilitate picking out gaps due to black holes in load balancing constructs esp. in don't reply mode. - not clear how the example of testing stacked FECs would work in CSC scenarios, perhaps an author could comment? cheers Dave From owner-mpls@UU.NET Wed Dec 4 13:10:09 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 NAA26099 for ; Wed, 4 Dec 2002 13:10:09 -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 QQnruu06852 for ; Wed, 4 Dec 2002 18:12:56 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 QQnruu04205; Wed, 4 Dec 2002 18:11:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQnruu15048 for mpls-outgoing; Wed, 4 Dec 2002 18:11: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 QQnruu14879 for ; Wed, 4 Dec 2002 18:10: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 QQnruu09779 for ; Wed, 4 Dec 2002 18:10: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 QQnruu03456 for ; Wed, 4 Dec 2002 18:10:17 GMT Received: from hoemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQnruu03444 for ; Wed, 4 Dec 2002 18:10:17 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 gB4IAFY05189 for ; Wed, 4 Dec 2002 13:10:15 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 19:10:14 +0100 Message-ID: From: "Wijnen, Bert (Bert)" To: "Mpls (E-mail)" Subject: review of draft-ietf-mpls-ftn-mib-05.txt Date: Wed, 4 Dec 2002 19:10:14 +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 Here is my review comments for the FTN mib document First a complexity problem ---------- I have trouble understanding the complexity of the indexing in the mplsFTNMapTable. Can someone explain it to me? The document claims that entries can be inserted (see section 5.2 and DESCRIPTION clause of mplsFTNMapTable and mplsFTNMapEntry), but I wonder how you do that? For example, let us assume you have for ifIndex 1 these entries with these indices: 1.0.1 1.1.2 1.2.4 And you wanted to insert map entry 3, then how do you do that? If it turns out that the only way to do it is to first remove the last one and then add 2 new ones 1.2.3 1.3.4 then why is that handy? And does it justify the complexity. And that is just for inserting one entry... think about multiple entries? Does anyone by the way think that the figure on page 6 (sect 5.4) is easy to understand (or to understand at all) ?? This (complex) indexing is also the reason why we get an "inconsistent index" error from SMICng for the Perf Table. ------------ now the regular review comments/nits ------ - sect 3. references [2] but that one is not listed in references section probbaly easiest to reference [RFC2119] anyway and add that one. - sect 5.4 The 3 items at the bottom of the figure: | | | | | | (mplsFTNMapIndex = 1, ----------------| | | mplsFTNMapCurrIndex = 2) | | | | (mplsFTNMapIndex = 1, | | mplsFTNMapCurrIndex = 3) -----------------| | | mplsFTNPerfEntry: | (mplsFTNMapIndex = 1, -------------------| mplsFTNMapCurrIndex = 1) Are they the 3 entries in the mplsFTNPerfTable? cause that is not clear for the first two is it? - I tried to work through the example in sect 6. It seems OK now (at least it is much better than the one of half a year ago or so). Can someone else check it too please and confirm that it looks correct? - sect 7 You have fixed it based on earlier comment of mine. The 1st sentence is still incorrect: RowPointer is a textual convention used to identify a conceptual row in a conceptual Table in a MIB by pointing to one of its objects. s/one/the first accessible/ - MplsFTNIndexOrZero ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Index for a FTN entry or zero. If the number of unassigned entries is exhausted, this object MUST return a value of 0." SYNTAX Unsigned32 (0..4294967295) talks about "this object MUST return" !!! this is a TC, not an object. There can be an object that has this SYNTAX though. I think for objects that use this SYNTAX, it means that it does not point to an FTNEntry. That thing about "exhausted" is the next TC - The DESCRIPTION clauses of the MplsFTNIndexIntegerNextFree TC and the first usage of it in mplsFTNIndexNext object DESCRIPTION clause seem to conflict as far as I understand them. In any event, I donlt think you want the value to change after every GET or GETNEXT. - DESCRIPTION in mplsFTNTable ends with: The action pointer points at either an MPLS-LSR MIB mplsXCEntry when the NHLFE entry is a non-TE LSP, or it points at an mplsTunnelEntry in the MPLS-TE MIB if we wish to make the NHLFE the start of a TE tunnel." I don't this the "if we wish to make" is good language. Maybe better "in which case the NHLFE is the start of a TE tunnel." - mplsFTNRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Used for controlling the creation and deletion of this row. All writable objects in this row may be modified at any time. Setting this variable to 'destroy' when the MIB contains one or more RowPointers pointing to it results in destruction being delayed until the row is no longer used." ::= { mplsFTNEntry 2 } I think I already mentioned at the MPLS MIB meeting in Atalanta that "destruction being delayed until the row is no longer used." is not acceptable. - mplsFTNAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "Type of IP packet that this entry will match against. Values unknown(0) and dns(16) are disallowed. All source and destination IP address types MUST use the same address type." Are values (0) and (16) really disAllowed. Or is it better to say that only IPv4 and IPv6 need to be supported. In the future, that InetAddressType TC may get expanded, and there may be yet other values.... And in fact in the compliance section you do include value (0) as a valid value !!! Also. This is not the "Type of IP packet". but the "Type of address used for the following InetAddress fields/objects". So my DESCRIPTION would rather be something aka (using RFC3291 as example): "The type of Internet address to be used for the comparison. The only values that MUST be supported are unknown(0), ipv4(1) and ipv6(2). Note that both source and destinations Internet addresses must be of the same InetAddressType." - mplsFTNSourceAddrMin OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The lower end of source address range. The IP address type for this object MUST use the mplsFTNAddrType object defined for this row." ::= { mplsFTNEntry 6 } The way to describe it I think is not that this object MUST use ..... If I follow the example in RFC3291 (the INET-ADDRESS-MIB) then my descripion clause would be something aka: This address is "The lower end of source Internet address range. The type of this address is determined by the value of the mplsFTNAddrType object." -mplsFTNSourceAddrMax OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The upper end of source address range." ::= { mplsFTNEntry 7 } I think you need to change DESCRIPTION to something aka: "The upper end of source Internet address range. The type of this address is determined by the value of the mplsFTNAddrType object." Yep, you MUST repeat that which InetAddressType object controls format of this object as well - Same for next two InetAddress objects - mplsFTNExpBits OBJECT-TYPE SYNTAX Unsigned32 (0..127) If I remember correctly then we discussed and agreed at the Atlanta MPLS MIB meeting that this should probably be a Dscp or DscpOrAny TC from the DIFFSERV-DSCP-TC mib module in RFC3289. - mplsFTNMapIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interface index that this FTN entry is being applied to. An index with value zero is applied all interfaces. If this entry is created with index zero and other indexes are created with non-zero values, these entries superceede the entry with index zero." ::= { mplsFTNMapEntry 1 } To me it is still not exactly clear what the expected behaviour is. If I have and entry with MapIndex == 0 and one with MapIndex == 1, but not one woith MapIndex == 2. Now a packet comes in on Interface with ifIndex == 1, then what? I think that you mean in that case that it uses the row(s) with MapIndex == 1, and the row(s) with MapIndex == 0 is ignored/skipped. If a packet comes in on interface with ifIndex == 2, then (since the is no row with MapIndex == 2) it will be handled by the row(s) which have MapIndex == 0. That is not 100% clear from the description, or at least, I am not sure that I understand it correctly. Can you make it clearer? Or... if I am the only one who does not understand, then ignore me. - mplsFTNMapLastChanged OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the last time an entry was added, deleted or modified in this table. Management stations should consult this object to determine if the table has been modified and requires their attention." ::= { mplsFTNMapEntry 4 } This sounds so STRANGE to me. It says "the last time an entry..." So if any entry gets added or changed, then ALL rows in this table will be updated to reflect the new TimeStamp ??? If it is only meant to indicate when this RowWasLastChanged, then I wonder how much use it has. An object that indicates when a table was last changed is normally an object that is defined outside the table, e.g. as a scalar. - If you have this (compliance section) OBJECT mplsFTNAddrType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is only required to support IPv4 and IPv6 addresses." OBJECT mplsFTNSourceAddrMin MIN-ACCESS read-only DESCRIPTION "Write access is not required." then you normally also limit the sie of the InetAddress objects, so it would be OBJECT mplsFTNSourceAddrMin SYNTAX InetAddress (SIZE (0 | 4 | 20)) MIN-ACCESS read-only DESCRIPTION "Write access is not required." Same for otehr InetAddress objects And you do that also for the FullCompliance section. - I am not sure if Security ADs will be happy with security section. They tend to want to see details as to exactly which objects are sensitive and why. - Split of normative and informative references not correct. For you current SNMP references, the split is: > > > > Normative Informative > > ---------- ------------ > > 1905 1155 > > 1906 1157 > > 1212 > > 1215 > > 2571 1901 > > 2572 2570 > > 2573 > > 2574 > > 2575 > > 2578 > > 2579 > > 2580 > > Bert From owner-mpls@UU.NET Wed Dec 4 13:12:33 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 NAA26284 for ; Wed, 4 Dec 2002 13:12:32 -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 QQnruu08362 for ; Wed, 4 Dec 2002 18:14:57 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 QQnruu29912; Wed, 4 Dec 2002 18:10:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQnruu14362 for mpls-outgoing; Wed, 4 Dec 2002 18:09: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 QQnruu14354 for ; Wed, 4 Dec 2002 18:09:45 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 QQnruu23142 for ; Wed, 4 Dec 2002 18:09: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 QQnruu01573 for ; Wed, 4 Dec 2002 18:09:08 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 QQnruu01562 for ; Wed, 4 Dec 2002 18:09:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB4I9YfH014757 for ; Wed, 4 Dec 2002 13:09:34 -0500 (EST) 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 NAA23650 for ; Wed, 4 Dec 2002 13:09:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB4I95u04816 for mpls@uu.net; Wed, 4 Dec 2002 13:09: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 QQnruu14156 for ; Wed, 4 Dec 2002 18:08:22 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 QQnruu16096 for ; Wed, 4 Dec 2002 18:07: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 QQnruu27271 for ; Wed, 4 Dec 2002 18:07:09 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQnruu27261 for ; Wed, 4 Dec 2002 18:07:09 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25738; Wed, 4 Dec 2002 13:04:16 -0500 (EST) Message-Id: <200212041804.NAA25738@ietf.org> To: IETF-Announce:; Cc: RFC Editor , Internet Architecture Board , mpls@UU.NET From: The IESG Subject: Protocol Action: Time to Live (TTL) Processing in MPLS Networks (Updates RFC 3032) to Proposed Standard Date: Wed, 04 Dec 2002 13:04:16 -0500 Sender: owner-mpls@UU.NET Precedence: bulk The IESG has approved the Internet-Draft 'Time to Live (TTL) Processing in MPLS Networks (Updates RFC 3032)' as a Proposed Standard. This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Bert Wijnen and Scott Bradner. Technical Summary This document describes Time To Live (TTL) processing in hierarchical MPLS networks. It updates RFC 3032 "MPLS Label Stack Encoding". TTL processing in both pipe and uniform model hierarchical tunnels are specified with examples for both "push" and "pop" cases. The document also complements RFC 3270 "MPLS Support of Differentiated Services" and ties together the terminology introduced in that document with TTL processing in hierarchical MPLS networks. Working Group Summary The working group supported publication of this document. Protocol Quality This document was reviewed for the IESG by Scott Bradner. From owner-mpls@UU.NET Wed Dec 4 13:42: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 NAA27590 for ; Wed, 4 Dec 2002 13:42:04 -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 QQnruw08736 for ; Wed, 4 Dec 2002 18:44: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 QQnruw04387; Wed, 4 Dec 2002 18:42:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQnruw17836 for mpls-outgoing; Wed, 4 Dec 2002 18:41:37 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 QQnruw17819 for ; Wed, 4 Dec 2002 18:41:25 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 QQnruw20162 for ; Wed, 4 Dec 2002 18:41:09 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 QQnruw03609 for ; Wed, 4 Dec 2002 18:41:09 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 QQnruw03605 for ; Wed, 4 Dec 2002 18:41:09 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB4IfZBJ020066 for ; Wed, 4 Dec 2002 13:41:36 -0500 (EST) 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 NAA26663 for ; Wed, 4 Dec 2002 13:41:07 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB4If7L08597 for mpls@uu.net; Wed, 4 Dec 2002 13:41:07 -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 QQnruw17628 for ; Wed, 4 Dec 2002 18:40:17 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 QQnruw17073 for ; Wed, 4 Dec 2002 18:40: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 QQnruw02966 for ; Wed, 4 Dec 2002 18:40:02 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 QQnruw02955 for ; Wed, 4 Dec 2002 18:40: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 gB4IeMKi019867; Wed, 4 Dec 2002 13:40:23 -0500 (EST) Received: from tnadeau-w2k.cisco.com (dhcp-161-44-145-18.cisco.com [161.44.145.18]) by bucket.cisco.com (Mirapoint) with ESMTP id ACF28456; Wed, 4 Dec 2002 13:39:52 -0500 (EST) Message-Id: <5.2.0.9.2.20021204133620.0386bc10@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 04 Dec 2002 13:39:49 -0500 To: "Wijnen, Bert (Bert)" From: "Thomas D. Nadeau" Subject: Re: review of draft-ietf-mpls-ftn-mib-05.txt Cc: "Mpls (E-mail)" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 07:10 PM 12/4/2002 +0100, Wijnen, Bert (Bert) wrote: >Here is my review comments for the FTN mib document > >First a complexity problem ---------- > >I have trouble understanding the complexity of the >indexing in the mplsFTNMapTable. Can someone explain it to me? > >The document claims that entries can be inserted (see section >5.2 and DESCRIPTION clause of mplsFTNMapTable and mplsFTNMapEntry), >but I wonder how you do that? > >For example, let us assume you have for ifIndex 1 these entries >with these indices: > > 1.0.1 > 1.1.2 > 1.2.4 > >And you wanted to insert map entry 3, then how do you do that? > >If it turns out that the only way to do it is to first remove the >last one and then add 2 new ones > > 1.2.3 > 1.3.4 > >then why is that handy? And does it justify the complexity. >And that is just for inserting one entry... think about >multiple entries? I agree with Bert here, but I think I was overruled on this by the other co-authors a while back. I had proposed a simpler scheme that only had 2 indexes and only had the "previous" and "next"pointers as objects within the table: INDEX { mplsFTNMapIndex, mplsFTNMapCurrIndex } The problem is that if you rely on the ordering of these indexes to imply how to apply the rules, then you still run into the same problem you describe above where you have to move the entire list around. The best solution is to have the indexing with MapIndex and CurrIndex and have previous/next objects to show the relationship. This way you only move pointers around instead of having to create/destroy rows in the table. You create the entries for each interface and then move the pointers. This is actually an easy and painless change to the MIB that makes it work well for configuration cases. I would argue that it makes it easier to create entries for agents too. The only issue is that the agent has to keep track of the consistency if rows are deleted unless you allow configuration, in which case the manager should do this while deleting rows. >Does anyone by the way think that the figure on page 6 (sect 5.4) >is easy to understand (or to understand at all) ?? Sorry, my ASCII art isn't what it used to be (or ever was?). I think that if we change the indexing as described above, it will be greatly simplified. --Tom >This (complex) indexing is also the reason why we get an >"inconsistent index" error from SMICng for the Perf Table. > >------------ now the regular review comments/nits ------ > >- sect 3. > references [2] but that one is not listed in references section > probbaly easiest to reference [RFC2119] anyway and add that one. > >- sect 5.4 > The 3 items at the bottom of the figure: > | | | > | | | > (mplsFTNMapIndex = 1, ----------------| | | > mplsFTNMapCurrIndex = 2) | | > | | > (mplsFTNMapIndex = 1, | | > mplsFTNMapCurrIndex = 3) -----------------| | > | > mplsFTNPerfEntry: | > (mplsFTNMapIndex = 1, -------------------| > mplsFTNMapCurrIndex = 1) > > Are they the 3 entries in the mplsFTNPerfTable? cause that > is not clear for the first two is it? > >- I tried to work through the example in sect 6. > It seems OK now (at least it is much better than the one > of half a year ago or so). Can someone else check it too > please and confirm that it looks correct? > >- sect 7 > You have fixed it based on earlier comment of mine. > The 1st sentence is still incorrect: > RowPointer is a textual convention used to identify a conceptual > row in a conceptual Table in a MIB by pointing to one of its objects. > > s/one/the first accessible/ > >- MplsFTNIndexOrZero ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "Index for a FTN entry or zero. If > the number of unassigned entries is > exhausted, this object MUST return a > value of 0." > SYNTAX Unsigned32 (0..4294967295) > > talks about "this object MUST return" !!! > this is a TC, not an object. There can be an object that has > this SYNTAX though. > I think for objects that use this SYNTAX, it means that it does not > point to an FTNEntry. That thing about "exhausted" is the next TC > >- The DESCRIPTION clauses of the MplsFTNIndexIntegerNextFree TC > and the first usage of it in mplsFTNIndexNext object DESCRIPTION > clause seem to conflict as far as I understand them. > In any event, I donlt think you want the value to change after > every GET or GETNEXT. > >- DESCRIPTION in mplsFTNTable ends with: > > The action pointer points at either an MPLS-LSR MIB > mplsXCEntry when the NHLFE entry is a non-TE LSP, or > it points at an mplsTunnelEntry in the MPLS-TE MIB > if we wish to make the NHLFE the start of a TE tunnel." > > I don't this the "if we wish to make" is good language. > Maybe better "in which case the NHLFE is the start of a TE > tunnel." > >- mplsFTNRowStatus OBJECT-TYPE > SYNTAX RowStatus > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Used for controlling the creation and deletion of this > row. All writable objects in this row may be > modified at any time. Setting this variable to > 'destroy' when the MIB contains one or more RowPointers > pointing to it results in destruction being > delayed until the row is no longer used." > ::= { mplsFTNEntry 2 } > > I think I already mentioned at the MPLS MIB meeting in Atalanta that > "destruction being delayed until the row is no longer used." is > not acceptable. > >- mplsFTNAddrType OBJECT-TYPE > SYNTAX InetAddressType > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Type of IP packet that this entry will match against. > Values unknown(0) and dns(16) are disallowed. All > source and destination IP address types MUST use the > same address type." > > Are values (0) and (16) really disAllowed. Or is it better to say > that only IPv4 and IPv6 need to be supported. In the future, that > InetAddressType TC may get expanded, and there may be yet other > values.... > And in fact in the compliance section you do include value (0) > as a valid value !!! > Also. This is not the "Type of IP packet". but the "Type of address > used for the following InetAddress fields/objects". So my DESCRIPTION > would rather be something aka (using RFC3291 as example): > "The type of Internet address to be used for the comparison. > The only values that MUST be supported are unknown(0), ipv4(1) > and ipv6(2). Note that both source and destinations Internet > addresses must be of the same InetAddressType." > >- mplsFTNSourceAddrMin OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The lower end of source address range. > The IP address type for this object MUST > use the mplsFTNAddrType object defined > for this row." > ::= { mplsFTNEntry 6 } > > The way to describe it I think is not that this object MUST use > ..... > If I follow the example in RFC3291 (the INET-ADDRESS-MIB) then > my descripion clause would be something aka: > This address is > "The lower end of source Internet address range. > The type of this address is determined by the value of > the mplsFTNAddrType object." > >-mplsFTNSourceAddrMax OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The upper end of source address range." > ::= { mplsFTNEntry 7 } > > I think you need to change DESCRIPTION to something aka: > "The upper end of source Internet address range. > The type of this address is determined by the value of > the mplsFTNAddrType object." > > Yep, you MUST repeat that which InetAddressType object controls format > of this object as well > >- Same for next two InetAddress objects > >- mplsFTNExpBits OBJECT-TYPE > SYNTAX Unsigned32 (0..127) > > If I remember correctly then we discussed and agreed at the Atlanta > MPLS MIB meeting that this should probably be a Dscp or DscpOrAny TC > from the DIFFSERV-DSCP-TC mib module in RFC3289. > >- mplsFTNMapIndex OBJECT-TYPE > SYNTAX InterfaceIndexOrZero > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The interface index that this FTN entry is being > applied to. An index with value zero is applied all > interfaces. If this entry is created with index zero > and other indexes are created with non-zero values, > these entries superceede the entry with index zero." > ::= { mplsFTNMapEntry 1 } > > To me it is still not exactly clear what the expected behaviour is. > If I have and entry with MapIndex == 0 and one with MapIndex == 1, > but not one woith MapIndex == 2. > Now a packet comes in on Interface with ifIndex == 1, then what? > I think that you mean in that case that it uses the row(s) with > MapIndex == 1, and the row(s) with MapIndex == 0 is ignored/skipped. > If a packet comes in on interface with ifIndex == 2, then (since > the is no row with MapIndex == 2) it will be handled > by the row(s) which have MapIndex == 0. > > That is not 100% clear from the description, or at least, I am > not sure that I understand it correctly. Can you make it clearer? > Or... if I am the only one who does not understand, then ignore me. > >- mplsFTNMapLastChanged OBJECT-TYPE > SYNTAX TimeStamp > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Indicates the last time an entry was added, deleted > or modified in this table. Management stations should > consult this object to determine if the table has > been modified and requires their attention." > ::= { mplsFTNMapEntry 4 } > > This sounds so STRANGE to me. It says "the last time an entry..." > So if any entry gets added or changed, then ALL rows in this table > will be updated to reflect the new TimeStamp ??? > If it is only meant to indicate when this RowWasLastChanged, then I > wonder how much use it has. > > An object that indicates when a table was last changed is normally > an object that is defined outside the table, e.g. as a scalar. > >- If you have this (compliance section) > > OBJECT mplsFTNAddrType > SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required. An implementation is only required > to support IPv4 and IPv6 addresses." > > OBJECT mplsFTNSourceAddrMin > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > then you normally also limit the sie of the InetAddress objects, so > it would be > > OBJECT mplsFTNSourceAddrMin > SYNTAX InetAddress (SIZE (0 | 4 | 20)) > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > Same for otehr InetAddress objects > > And you do that also for the FullCompliance section. > >- I am not sure if Security ADs will be happy with security section. > They tend to want to see details as to exactly which objects are > sensitive and why. > >- Split of normative and informative references not correct. > For you current SNMP references, the split is: > > > > > > Normative Informative > > > ---------- ------------ > > > 1905 1155 > > > 1906 1157 > > > 1212 > > > 1215 > > > 2571 1901 > > > 2572 2570 > > > 2573 > > > 2574 > > > 2575 > > > 2578 > > > 2579 > > > 2580 > > > > > >Bert From owner-mpls@UU.NET Wed Dec 4 14:14:25 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 OAA29087 for ; Wed, 4 Dec 2002 14:14:24 -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 QQnruz09372 for ; Wed, 4 Dec 2002 19:17: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 QQnruz06465; Wed, 4 Dec 2002 19:15:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQnruz09333 for mpls-outgoing; Wed, 4 Dec 2002 19:15:28 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 QQnruz09328 for ; Wed, 4 Dec 2002 19:15:27 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 QQnruz22685 for ; Wed, 4 Dec 2002 19:15: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 QQnruz05880 for ; Wed, 4 Dec 2002 19:15:10 GMT Received: from newdev.harvard.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: newdev.eecs.harvard.edu [140.247.60.212]) id QQnruz05870 for ; Wed, 4 Dec 2002 19:15:10 GMT Received: (from sob@localhost) by newdev.harvard.edu (8.12.2/8.12.2) id gB4JDBp4001982 for mpls@uu.net; Wed, 4 Dec 2002 14:13:11 -0500 (EST) Date: Wed, 4 Dec 2002 14:13:11 -0500 (EST) From: Scott Bradner Message-Id: <200212041913.gB4JDBp4001982@newdev.harvard.edu> To: mpls@UU.NET Subject: in case you have not seen this: IETF Sub-IP area: request for input Sender: owner-mpls@UU.NET Precedence: bulk IETF SUB-IP area The IESG announced in November of 2000 that a new SUB-IP temporary pseudo-area would be formed as a part of an effort to develop a "systematic approach to dealing with what we used to describe as "sub-IP" technologies." At the time the IESG said: "Over the years the boundary between 'wires' and IP protocols has become harder to define and the interaction has become more intertwined. For example, what appear as 'wires' or 'circuits' in a virtual network may in fact be routed datagrams in an underlying IP network. The topology of dynamic underlying networks such as ATM and soon switched optical networks can interact with IP-level traffic engineering and routing. Additionally, with IETF technologies such as MPLS we are defining a whole new class of 'wires'." (http://www.ietf.org/IESG/STATEMENTS/new-area.txt) After the December 2000 IETF meeting and taking into account the discussion at that meeting the IESG formed a "temporary" SUB-IP Area. IN the announcement of this action the IESG said: "It is temporary because the IESG believes that this concentrated sub-IP effort will likely be of short duration, on the order of a year or two. We feel that much of the work will be done by then, and the working groups closed. Any working groups that have not finished when the IESG determines that the area should be closed will be moved into existing the IETF areas where they seem to have the best fit." and "The IESG expects to review the development process and charters, however; if we conclude that this expectation is incorrect, we will need to make this area more formal. At that point, the nominating committee will be asked to supply dedicated area directors." (http://www.ietf.org/IESG/STATEMENTS/sub_area.txt) Although the SUB-IP working groups have made considerable progress (with 7 RFCs published, another 12 IDs approved for publication, 9 IDs under IESG consideration and an additional 11 IDs having been passed to the ADs for their evaluation) their work is not yet done (with 53 working group IDs currently in progress). It does appear that some of the working groups could finish the work in their charters over the next 6 months but it could be a lot longer for others. Because the end is in sight for some of the working groups and since the IESG had generally assumed that the area would be a temporary one and the second anniversary of the creation of the SUB-IP area is next spring, analysis was started in the IESG to figure out which areas would be the best ones for the SUB-IP working groups to move to so that they could continue their work. As part of that analysis a SUB-IP area session was held during the IETF meeting in Atlanta where this topic was discussed. There was a spirited discussion during the session on the best path forward. The opinions ranged from following the distribution of working groups, to doing so with some specific changes to keeping the working groups in a separate SUB-IP area. A sense of the room was taken at the end of the discussion and that sense was very strongly that the SUB-IP Area should become a "long-term" (the description that was used during the consensus call) one and that the nomcom be asked to nominate a person (or persons) to become director(s) of the SUB-IP area. To help provide more information as input for the IESG discussion we would like to continue the discussion started in Atlanta on the mailing list. It is our intention to keep the discussion on the future of the SUB-IP area open, but short-lived, because it would be a very good idea to let the nomcom know ASAP what the future holds as they need to know what expertise is needed in the ADs for the existing areas and if they need to search for additional people. The IESG aim is to be able to let the nomcom know what the future of the SUB-IP work is by the end of the day of Thursday Dec 12th. That date was chosen because it is the date of the next IESG teleconference yet it provides some time for a public discussion. The options seem to be: 1/ move WGs (back) to permanent areas: migrate the SUB-IP working groups to other IETF areas sometime soon, likely before next summer and close the SUB-IP area. Also, reconstitute the SUB-IP (and/or other) directorates to ensure the continued coordination between the remaining WGs. 2/ establish a long-term area: decide that the SUB-IP area will be a long-term one, clearly define its charter, and ask the nomcom to select one or two people to be Area Directors 3/ status quo: continue the SUB-IP Area as a temporary, ad-hoc effort, much as it has been, with the IESG selecting two sitting ADs to continue the effort that Bert & Scott have been doing. But maybe give more responsibility to the working group's technical advisors, normally the AD from the area where the working group might otherwise live. Data points for the discussion: DP1. It does look like a number of the SUB-IP working groups will be finishing up their main work in the next year and be ready to be closed until it is time to revise the RFCs based on experience or to advance them on the standards track. The groups that should be finishing up include ipo, gsmp and tewg. That would leave mpls, ppvpn and ccamp. DP2. WGs in SUB-IP or the work pursued in them came from existing well-established areas, i.e., tewg came from OPS, gsmp, mpls (with ccamp and ppvpn as its derivatives) came from RTG. DP3. There's still a need for technical oversight from permanent areas, so some WGs have a technical advisor--normally the AD from the area where the working group might otherwise live (e.g. CCAMP, and PPVPN with a RTG AD as the TA). DP4. SUB-IP directorate was very useful when the area was just created. It is currently passive and WGs continue operating just fine. DP5. The sense of the SUB-IP session in Atlanta was that the SUB-IP Area was working and there is no compelling reason to break it up. There is a need to clarify the charters of some of the working groups so that the different groups understand what the division of tasks are but it is hard to identify what problem would be solved by breaking up the area. DP6. Extensions to specific IETF technologies should be done in the working groups responsible for those technologies based on requirements provided by other working groups. For example, extensions to OSPF should be done by the OSPF working group based on input from other working groups or individuals rather than being done someplace else. Discussions about the options: 1/ Move WGs (back) to permanent areas and close the area For: Each WG within SUB-IP definitely has a strong feature that maps it to a given permanent area [1]. The property that logically holds them together in SUB-IP now is the need for coordination wrt the technologies that are normally considered below the IP layer. While this was indeed necessary right after SUB-IP creation, DP4 suggests that the goal has been achieved and the focus is shifting back to coordination with permanent areas (e.g., DP3, as well as the fact that RTG WGs are already dealing with SUB-IP related extensions). DP1 suggests that there will be about three active WGs within a year; at least two of them can be argued to belong in RTG area (where they originally came from, see DP2), so it wouldn't make a lot of sense to have two separate areas overlapping so considerably. PPVPN does not map strongly to any area, however it doesn't map strongly to SUB-IP either (MPLS is just one possible encapsulation method) Against: DP5 suggests that the feeling in the room was against closing the area, though there was also some support for the idea that moving MPLS and CCAMP to RTG would be a fine idea if the area were to be closed. The feeling was that the area has been working and that there is no strong argument that there is a need to change things at this time. 2/ Establish a long-term area For: DP5 suggests that the community believes this is a good idea. See also the "Against" for option 1. In addition the opinion was expressed that having a specific area with specifically assigned management, knowledgeable in the field, would be an advantage. In addition, new SUP-IP work may develop in the future and it would be good to have a home for it. Against: See "For" arguments for option 1 above. Also, there was an assumption when the area was formed that it would be temporary and the size of the IESG is near max effective size. It is also expected that if the nomcom needs to find an AD(s) for SUB-IP, the set of required skills would be extremely similar to those needed for the RTG area, which again brings up the question of whether it makes sense to have two areas with so similar expertise scopes. 3/ Status quo For: DP5 suggests that the way the area operates is fine and does not need fixing at this time. As DP1 predicts, there may not be many active SUB-IP working groups within a year and it may be best to wait until a few of the working groups finish their work and close before deciding on the long term direction for this work. The IESG would decide which ADs would be asked to manage the area in March. Against: A decision has to be made sooner or later, delaying the decision will not make it any easier to make. The IESG would like to hear from the community on this topic - please direct your comments to the ietf@ietf.org list. The IESG will discuss the matter in its next telechat on December 12. -------------------------------------------------- [1] possible WG to area mappings: - IPO has the IP-over-foo property, which is usually addressed in INT, - GSMP came from RTG - MPLS (aside from the fact that it came from RTG) deals with a technology that is arguably another IP forwarding paradigm and relies heavily on regular routing functionality and/or protocols. - CCAMP works on a generalized version of MPLS, which could map it to RTG as well - TEWG came from O&M - PPVPN: suggestions have been made of INT, because its tunneling which is closest to INT, RTG because some of the suggested discovery and VPN routing mechanisms, and TSV, because its related to PWE3 (in TSV because of congestion control worries) From owner-mpls@UU.NET Wed Dec 4 16:33:25 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 QAA04827 for ; Wed, 4 Dec 2002 16:33:25 -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 QQnrvi29757 for ; Wed, 4 Dec 2002 21:36: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 QQnrvi23992; Wed, 4 Dec 2002 21:32:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrvi26086 for mpls-outgoing; Wed, 4 Dec 2002 21:32: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 QQnrvi26078 for ; Wed, 4 Dec 2002 21:32:15 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 QQnrvi28156 for ; Wed, 4 Dec 2002 21:32:09 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 QQnrvi23374 for ; Wed, 4 Dec 2002 21:32:08 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 QQnrvi23368 for ; Wed, 4 Dec 2002 21:32:08 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB4LWZTG023863 for ; Wed, 4 Dec 2002 16:32:35 -0500 (EST) 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 QAA12490 for ; Wed, 4 Dec 2002 16:32:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB4LW6i19215 for mpls@uu.net; Wed, 4 Dec 2002 16:32:06 -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 QQnrvi25935 for ; Wed, 4 Dec 2002 21:31:04 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 QQnrvi20339 for ; Wed, 4 Dec 2002 21:30:45 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 QQnrvi21407 for ; Wed, 4 Dec 2002 21:30:44 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 QQnrvi21391 for ; Wed, 4 Dec 2002 21:30:44 GMT Received: (qmail 571 invoked by uid 104); 4 Dec 2002 21:30:43 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4235. . Clean. Processed in 0.751105 secs); 04 Dec 2002 21:30:43 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 4 Dec 2002 21:30:42 -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 gB4LUaQ17977; Wed, 4 Dec 2002 13:30:36 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Wed, 4 Dec 2002 13:30:36 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B35@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'George Swallow'" , mpls@UU.NET Subject: RE: Last Call on Fast Reroute Date: Wed, 4 Dec 2002 13:30:35 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi, Although I have no hope of getting any response, but here is a repeat of my ignored comments raised in March, 2002 and some new ones: 1) Time stamp: Why is the time stamp in both seconds and microseconds? The microsecond could count up to 71 minutes. Isn't that enough? Why isn't the same timestamp used in ICMP not used here which says: The Timestamp is a right-justified, 32-bit timestamp in milliseconds since midnight UT. 2) Section 3: Why the echo reply time stamp is not similar to ICMP echo-reply time-stamp in which a received time-stamp and sent-time stamp is set by the receiver? Which gives you the processing time at the receiver too. 3) Section 3.1: If I understand it correctly a Target FEC TLV could consist of a number of FEC stack sub-TLVs. Therefore it seems that the number of these sub-TLVs could be determined by looking at the Target FEC TLV length field and subtracting the sub-TLV lengths from it. But the text says it could be determined by looking at the sub-TLV length field. Needs clarification. 4) Section 3.1: How can you ping multiple FECs simultaneously (i.e., piggy back multiple pings), while each FEC belongs to a different level of the label stack? This requires that all those hierarchical labels (LSPs) be initiated and terminated at the same LSRs. Also how do you intend to generate error response if the result of some of those FEC pings are positive and some are negative? 5) Section 3 under return code. There is no return code for the case that one of the FECs fail while others pass, or when one of the label mappings don't pass, while others pass. 6) Why doesn't the MPLS ping permit pinging multiple FECs that belong to the same LSP level? It seems that if 1000s of FECs are all mapped to the same LSP, then 1000's of MPLS-pings are required. 7) Why is the downstream label field in the downstream mapping TLV 24 bits? Is it for ATM? How is the 20 bit label mapped to this 24 bit? 8) Section 3.2: When X receives a packet with TTL of n>1, shouldn't it compute the downstream LSRs that could receive the packet with TTL=n-1 (rather than TTL=n+1 as indicated)? 9) Section 3.2 last paragraph: Does this apply to trace-route mode only? 10) Section 4.3: Does the downstream mapping TLV of the echo-reply replace the downstream mapping TLV of the echo-request or it is appended to it? 11) Section 4.5: If the egress for an FEC stack being pinged doesn't support MPLS ping, isn't an ICMP TTL expire message generated for the IP TTL=1 received (instead of no reply as mentioned in the draft)? 12) Section 5 2nd paragraph last sentence I think should be changed to: "Note that this may not work if some transit LSR does not support IP options" (not 'MPLS ping' as mentioned in the draft) 13) Section 5: Is RSVP-TE return path used only in "ping" mode or also in trace-route mode? 14) Section 5.3 last paragraph: I think you need to delete ICMP here. It has no meaning here. 15) Section 5.5: I think you need to mention that if intermediate LSRs don't support refresh reduction, then it could take many minutes before the echo-reply is received at the source. 16) Section 3.1.7 and 3.1.8: What is Encapsulation Type and how is it encoded? 17) Section 3.2: Why are there multiple downstream labels in the downstream mapping? do they belong to different LSP levels? Or the figure is simply showing many downstream mapping TLVs? 18) Section 3.3: what is the purpose of Pad TLV? 19) Section 4.3: Should an Echo reply always have a downstream mapping TLV even if no downstream mapping TLV is in the Echo request? 20) Section 4.4: Seems like back to back echo-request can't be sent before receiving the echo-reply of previous echo-request. Why this limitation? 21) Section 5.1: How is the downstream mapping TLV conveyed in the echo-reply sent over RSVP-TE? it seems no downstream mapping TLV is defined for RSVP-TE. Thanks, -Shahram > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Tuesday, December 03, 2002 5:50 PM > To: mpls@UU.NET > Subject: Last Call on Fast Reroute > > > This message begins a workgroup last call on: > > Fast Reroute Extensions to RSVP-TE for LSP Tunnels > > draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt > > The last call ends on Dec 16, 2002 2400H GMT. > > George & Loa > > ====================================================================== > George Swallow Cisco Systems (978) 497-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > > > From owner-mpls@UU.NET Wed Dec 4 16:44: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 QAA05367 for ; Wed, 4 Dec 2002 16:44:29 -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 QQnrvj19512 for ; Wed, 4 Dec 2002 21:47: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 QQnrvi12612; Wed, 4 Dec 2002 21:43:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrvi27111 for mpls-outgoing; Wed, 4 Dec 2002 21:43:04 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 QQnrvi27085 for ; Wed, 4 Dec 2002 21:42:57 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 QQnrvi23588 for ; Wed, 4 Dec 2002 21:42: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 QQnrvi11368 for ; Wed, 4 Dec 2002 21:42:18 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 QQnrvi11353 for ; Wed, 4 Dec 2002 21:42:17 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB4Lgiss025576 for ; Wed, 4 Dec 2002 16:42:45 -0500 (EST) 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 QAA13481 for ; Wed, 4 Dec 2002 16:42:15 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB4LgF621371 for mpls@uu.net; Wed, 4 Dec 2002 16:42:15 -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 QQnrvi26797 for ; Wed, 4 Dec 2002 21:40:45 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 QQnrvi16082 for ; Wed, 4 Dec 2002 21:40:15 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 QQnrvi13954 for ; Wed, 4 Dec 2002 21:40:15 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 QQnrvi13938 for ; Wed, 4 Dec 2002 21:40:14 GMT Received: (qmail 9494 invoked by uid 104); 4 Dec 2002 21:40:13 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4235. . Clean. Processed in 0.691304 secs); 04 Dec 2002 21:40:13 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 4 Dec 2002 21:40:12 -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 gB4LeBQ23714; Wed, 4 Dec 2002 13:40:11 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Wed, 4 Dec 2002 13:40:11 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B38@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'George Swallow'" , mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Wed, 4 Dec 2002 13:40:07 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi, Although I have no hope of getting any response, but here is a repeat of my ignored comments raised in March, 2002 and some new ones: 1) Time stamp: Why is the time stamp in both seconds and microseconds? The microsecond could count up to 71 minutes. Isn't that enough? Why isn't the same timestamp used in ICMP not used here which says: The Timestamp is a right-justified, 32-bit timestamp in milliseconds since midnight UT. 2) Section 3: Why the echo reply time stamp is not similar to ICMP echo-reply time-stamp in which a received time-stamp and sent-time stamp is set by the receiver? Which gives you the processing time at the receiver too. 3) Section 3.1: If I understand it correctly a Target FEC TLV could consist of a number of FEC stack sub-TLVs. Therefore it seems that the number of these sub-TLVs could be determined by looking at the Target FEC TLV length field and subtracting the sub-TLV lengths from it. But the text says it could be determined by looking at the sub-TLV length field. Needs clarification. 4) Section 3.1: How can you ping multiple FECs simultaneously (i.e., piggy back multiple pings), while each FEC belongs to a different level of the label stack? This requires that all those hierarchical labels (LSPs) be initiated and terminated at the same LSRs. Also how do you intend to generate error response if the result of some of those FEC pings are positive and some are negative? 5) Section 3 under return code. There is no return code for the case that one of the FECs fail while others pass, or when one of the label mappings don't pass, while others pass. 6) Why doesn't the MPLS ping permit pinging multiple FECs that belong to the same LSP level? It seems that if 1000s of FECs are all mapped to the same LSP, then 1000's of MPLS-pings are required. 7) Why is the downstream label field in the downstream mapping TLV 24 bits? Is it for ATM? How is the 20 bit label mapped to this 24 bit? 8) Section 3.2: When X receives a packet with TTL of n>1, shouldn't it compute the downstream LSRs that could receive the packet with TTL=n-1 (rather than TTL=n+1 as indicated)? 9) Section 3.2 last paragraph: Does this apply to trace-route mode only? 10) Section 4.3: Does the downstream mapping TLV of the echo-reply replace the downstream mapping TLV of the echo-request or it is appended to it? 11) Section 4.5: If the egress for an FEC stack being pinged doesn't support MPLS ping, isn't an ICMP TTL expire message generated for the IP TTL=1 received (instead of no reply as mentioned in the draft)? 12) Section 5 2nd paragraph last sentence I think should be changed to: "Note that this may not work if some transit LSR does not support IP options" (not 'MPLS ping' as mentioned in the draft) 13) Section 5: Is RSVP-TE return path used only in "ping" mode or also in trace-route mode? 14) Section 5.3 last paragraph: I think you need to delete ICMP here. It has no meaning here. 15) Section 5.5: I think you need to mention that if intermediate LSRs don't support refresh reduction, then it could take many minutes before the echo-reply is received at the source. 16) Section 3.1.7 and 3.1.8: What is Encapsulation Type and how is it encoded? 17) Section 3.2: Why are there multiple downstream labels in the downstream mapping? do they belong to different LSP levels? Or the figure is simply showing many downstream mapping TLVs? 18) Section 3.3: what is the purpose of Pad TLV? 19) Section 4.3: Should an Echo reply always have a downstream mapping TLV even if no downstream mapping TLV is in the Echo request? 20) Section 4.4: Seems like back to back echo-request can't be sent before receiving the echo-reply of previous echo-request. Why this limitation? 21) Section 5.1: How is the downstream mapping TLV conveyed in the echo-reply sent over RSVP-TE? it seems no downstream mapping TLV is defined for RSVP-TE. Thanks, -Shahram > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Tuesday, December 03, 2002 5:52 PM > To: mpls@UU.NET > Subject: Last call on LSP Ping > > > This message begins a workgroup last call on: > > Detecting MPLS Data Plane Liveness > > draft-ietf-mpls-lsp-ping-01.txt > > The last call ends on Dec 16, 2002 2400H GMT. > > George & Loa > > ====================================================================== > George Swallow Cisco Systems (978) 497-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > > > From owner-mpls@UU.NET Wed Dec 4 16:48: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 QAA05601 for ; Wed, 4 Dec 2002 16:48: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 QQnrvj27093 for ; Wed, 4 Dec 2002 21:51: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 QQnrvj21469; Wed, 4 Dec 2002 21:48:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrvj27926 for mpls-outgoing; Wed, 4 Dec 2002 21:47: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 QQnrvj27911 for ; Wed, 4 Dec 2002 21:47:41 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 QQnrvj11807 for ; Wed, 4 Dec 2002 21:47: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 QQnrvj20038 for ; Wed, 4 Dec 2002 21:47:26 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 QQnrvj19802 for ; Wed, 4 Dec 2002 21:47:19 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB4LlkiJ026297 for ; Wed, 4 Dec 2002 16:47:46 -0500 (EST) 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 QAA13925 for ; Wed, 4 Dec 2002 16:47:17 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB4LlHB22444 for mpls@uu.net; Wed, 4 Dec 2002 16:47:17 -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 QQnrvi27235 for ; Wed, 4 Dec 2002 21:44:33 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 QQnrvi00640 for ; Wed, 4 Dec 2002 21:44:09 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 QQnrvi13687 for ; Wed, 4 Dec 2002 21:43:51 GMT Received: from father.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQnrvi13618 for ; Wed, 4 Dec 2002 21:43:49 GMT Received: (qmail 11417 invoked by uid 104); 4 Dec 2002 21:43:48 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4235. . Clean. Processed in 0.525805 secs); 04 Dec 2002 21:43:48 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 4 Dec 2002 21:43:47 -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 gB4LhlQ25896; Wed, 4 Dec 2002 13:43:47 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Wed, 4 Dec 2002 13:43:46 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B39@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'George Swallow'" , mpls@UU.NET Subject: RE: Last Call on Fast Reroute Date: Wed, 4 Dec 2002 13:43:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi, Please ignore my last email with this subject. I intended the comments for MPLS-ping. Thanks, -Shahram > -----Original Message----- > From: Shahram Davari > Sent: Wednesday, December 04, 2002 4:31 PM > To: 'George Swallow'; mpls@UU.NET > Subject: RE: Last Call on Fast Reroute > > > Hi, > > Although I have no hope of getting any response, but here is > a repeat of my ignored comments raised in March, 2002 and > some new ones: > > 1) Time stamp: Why is the time stamp in both seconds and > microseconds? The microsecond could count up to 71 minutes. > Isn't that enough? Why isn't the > same timestamp used in ICMP not used here which says: > > The Timestamp is a right-justified, 32-bit timestamp in > milliseconds since midnight UT. > > 2) Section 3: Why the echo reply time stamp is not similar to > ICMP echo-reply time-stamp in which a received time-stamp and > sent-time stamp is set by the receiver? Which gives you the > processing time at the receiver too. > > 3) Section 3.1: If I understand it correctly a Target FEC TLV > could consist of a number of FEC stack sub-TLVs. Therefore it > seems that the number of these sub-TLVs could be determined > by looking at the Target FEC TLV length field and subtracting > the sub-TLV lengths from it. But the text says it could be > determined by looking at the sub-TLV length field. Needs > clarification. > > 4) Section 3.1: How can you ping multiple FECs simultaneously > (i.e., piggy back multiple pings), while each FEC belongs to > a different level of the label stack? This requires that all > those hierarchical labels (LSPs) be initiated and terminated > at the same LSRs. Also how do you intend to generate error > response if the result of some of those FEC pings are > positive and some are negative? > > 5) Section 3 under return code. There is no return code for > the case that one of the FECs fail while others pass, or when > one of the label mappings don't pass, while others pass. > > 6) Why doesn't the MPLS ping permit pinging multiple FECs > that belong to the same LSP level? It seems that if 1000s of > FECs are all mapped to the same LSP, then 1000's of > MPLS-pings are required. > > 7) Why is the downstream label field in the downstream > mapping TLV 24 bits? Is it for ATM? How is the 20 bit label > mapped to this 24 bit? > > 8) Section 3.2: When X receives a packet with TTL of n>1, > shouldn't it compute the downstream LSRs that could receive > the packet with TTL=n-1 (rather than TTL=n+1 as indicated)? > > 9) Section 3.2 last paragraph: Does this apply to trace-route > mode only? > > 10) Section 4.3: Does the downstream mapping TLV of the > echo-reply replace the downstream mapping TLV of the > echo-request or it is appended to it? > > 11) Section 4.5: If the egress for an FEC stack being pinged > doesn't support MPLS ping, isn't an ICMP TTL expire message > generated for the IP TTL=1 received (instead of no reply as > mentioned in the draft)? > > 12) Section 5 2nd paragraph last sentence I think should be > changed to: "Note that this may not work if some transit LSR > does not support IP options" (not 'MPLS ping' as mentioned in > the draft) > > 13) Section 5: Is RSVP-TE return path used only in "ping" > mode or also in trace-route mode? > > 14) Section 5.3 last paragraph: I think you need to delete > ICMP here. It has no meaning here. > > 15) Section 5.5: I think you need to mention that if > intermediate LSRs don't support refresh reduction, then it > could take many minutes before the echo-reply is received at > the source. > > 16) Section 3.1.7 and 3.1.8: What is Encapsulation Type and > how is it encoded? > > 17) Section 3.2: Why are there multiple downstream labels in > the downstream mapping? do they belong to different LSP > levels? Or the figure is simply showing many downstream mapping TLVs? > > 18) Section 3.3: what is the purpose of Pad TLV? > > 19) Section 4.3: Should an Echo reply always have a > downstream mapping TLV even if no downstream mapping TLV is > in the Echo request? > > 20) Section 4.4: Seems like back to back echo-request can't > be sent before receiving the echo-reply of previous > echo-request. Why this limitation? > > 21) Section 5.1: How is the downstream mapping TLV conveyed > in the echo-reply sent over RSVP-TE? it seems no downstream > mapping TLV is defined for RSVP-TE. > > > Thanks, > -Shahram > > > > > -----Original Message----- > > From: George Swallow [mailto:swallow@cisco.com] > > Sent: Tuesday, December 03, 2002 5:50 PM > > To: mpls@UU.NET > > Subject: Last Call on Fast Reroute > > > > > > This message begins a workgroup last call on: > > > > Fast Reroute Extensions to RSVP-TE for LSP Tunnels > > > > draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt > > > > The last call ends on Dec 16, 2002 2400H GMT. > > > > George & Loa > > > > > ====================================================================== > > George Swallow Cisco Systems > (978) 497-8143 > > 250 Apollo Drive > > Chelmsford, Ma 01824 > > > > > > > From owner-mpls@UU.NET Wed Dec 4 16:53: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 QAA05801 for ; Wed, 4 Dec 2002 16:53: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 QQnrvj05526 for ; Wed, 4 Dec 2002 21:55:52 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 QQnrvj24351; Wed, 4 Dec 2002 21:49:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrvj28034 for mpls-outgoing; Wed, 4 Dec 2002 21:49:10 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 QQnrvj28014 for ; Wed, 4 Dec 2002 21:48: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 QQnrvj13320 for ; Wed, 4 Dec 2002 21:48: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 QQnrvj22072 for ; Wed, 4 Dec 2002 21:48:37 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 QQnrvj22015 for ; Wed, 4 Dec 2002 21:48:36 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB4Ln3wY026502 for ; Wed, 4 Dec 2002 16:49:03 -0500 (EST) 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 QAA14026 for ; Wed, 4 Dec 2002 16:48:34 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB4LmYb22826 for mpls@uu.net; Wed, 4 Dec 2002 16:48:34 -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 QQnrvj27843 for ; Wed, 4 Dec 2002 21:46: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 QQnrvj06234 for ; Wed, 4 Dec 2002 21:46:25 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 QQnrvj18185 for ; Wed, 4 Dec 2002 21:46:21 GMT Received: from ams-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ams-msg-core-1.cisco.com [144.254.74.60]) id QQnrvj17807 for ; Wed, 4 Dec 2002 21:46:10 GMT Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB4LiaQv021099; Wed, 4 Dec 2002 22:44:37 +0100 (MET) Received: from JVASSEUR-W2K.cisco.com (sjc-vpn1-549.cisco.com [10.21.98.37]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id WAA02699; Wed, 4 Dec 2002 22:45:55 +0100 (MET) Message-Id: <4.3.2.7.2.20021204164450.0599a4d0@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 04 Dec 2002 16:45:53 -0500 To: Shahram Davari From: Jean Philippe Vasseur Subject: RE: Last Call on Fast Reroute Cc: "'George Swallow'" , mpls@UU.NET In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03B35@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 Sharam, I guess this email was for LSP Ping. JP. At 13:30 04/12/2002 -0800, Shahram Davari wrote: >Hi, > >Although I have no hope of getting any response, but here is a repeat of >my ignored comments raised in March, 2002 and some new ones: > >1) Time stamp: Why is the time stamp in both seconds and microseconds? The >microsecond could count up to 71 minutes. Isn't that enough? Why isn't the >same timestamp used in ICMP not used here which says: > > The Timestamp is a right-justified, 32-bit timestamp in > milliseconds since midnight UT. > >2) Section 3: Why the echo reply time stamp is not similar to ICMP >echo-reply time-stamp in which a received time-stamp and sent-time stamp >is set by the receiver? Which gives you the processing time at the >receiver too. > >3) Section 3.1: If I understand it correctly a Target FEC TLV could >consist of a number of FEC stack sub-TLVs. Therefore it seems that the >number of these sub-TLVs could be determined by looking at the Target FEC >TLV length field and subtracting the sub-TLV lengths from it. But the text >says it could be determined by looking at the sub-TLV length field. Needs >clarification. > >4) Section 3.1: How can you ping multiple FECs simultaneously (i.e., piggy >back multiple pings), while each FEC belongs to a different level of the >label stack? This requires that all those hierarchical labels (LSPs) be >initiated and terminated at the same LSRs. Also how do you intend to >generate error response if the result of some of those FEC pings are >positive and some are negative? > >5) Section 3 under return code. There is no return code for the case that >one of the FECs fail while others pass, or when one of the label mappings >don't pass, while others pass. > >6) Why doesn't the MPLS ping permit pinging multiple FECs that belong to >the same LSP level? It seems that if 1000s of FECs are all mapped to the >same LSP, then 1000's of MPLS-pings are required. > >7) Why is the downstream label field in the downstream mapping TLV 24 >bits? Is it for ATM? How is the 20 bit label mapped to this 24 bit? > >8) Section 3.2: When X receives a packet with TTL of n>1, shouldn't it >compute the downstream LSRs that could receive the packet with TTL=n-1 >(rather than TTL=n+1 as indicated)? > >9) Section 3.2 last paragraph: Does this apply to trace-route mode only? > >10) Section 4.3: Does the downstream mapping TLV of the echo-reply replace >the downstream mapping TLV of the echo-request or it is appended to it? > >11) Section 4.5: If the egress for an FEC stack being pinged doesn't >support MPLS ping, isn't an ICMP TTL expire message generated for the IP >TTL=1 received (instead of no reply as mentioned in the draft)? > >12) Section 5 2nd paragraph last sentence I think should be changed to: >"Note that this may not work if some transit LSR does not support IP >options" (not 'MPLS ping' as mentioned in the draft) > >13) Section 5: Is RSVP-TE return path used only in "ping" mode or also in >trace-route mode? > >14) Section 5.3 last paragraph: I think you need to delete ICMP here. It >has no meaning here. > >15) Section 5.5: I think you need to mention that if intermediate LSRs >don't support refresh reduction, then it could take many minutes before >the echo-reply is received at the source. > >16) Section 3.1.7 and 3.1.8: What is Encapsulation Type and how is it encoded? > >17) Section 3.2: Why are there multiple downstream labels in the >downstream mapping? do they belong to different LSP levels? Or the figure >is simply showing many downstream mapping TLVs? > >18) Section 3.3: what is the purpose of Pad TLV? > >19) Section 4.3: Should an Echo reply always have a downstream mapping TLV >even if no downstream mapping TLV is in the Echo request? > >20) Section 4.4: Seems like back to back echo-request can't be sent before >receiving the echo-reply of previous echo-request. Why this limitation? > >21) Section 5.1: How is the downstream mapping TLV conveyed in the >echo-reply sent over RSVP-TE? it seems no downstream mapping TLV is >defined for RSVP-TE. > > >Thanks, >-Shahram > > > > > -----Original Message----- > > From: George Swallow [mailto:swallow@cisco.com] > > Sent: Tuesday, December 03, 2002 5:50 PM > > To: mpls@UU.NET > > Subject: Last Call on Fast Reroute > > > > > > This message begins a workgroup last call on: > > > > Fast Reroute Extensions to RSVP-TE for LSP Tunnels > > > > draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt > > > > The last call ends on Dec 16, 2002 2400H GMT. > > > > George & Loa > > > > ====================================================================== > > George Swallow Cisco Systems (978) 497-8143 > > 250 Apollo Drive > > Chelmsford, Ma 01824 > > > > > > From owner-mpls@UU.NET Thu Dec 5 05:18:25 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 FAA06507 for ; Thu, 5 Dec 2002 05:18:24 -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 QQnrxh01200 for ; Thu, 5 Dec 2002 10:21:14 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 QQnrxh28587; Thu, 5 Dec 2002 10:20:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrxh24344 for mpls-outgoing; Thu, 5 Dec 2002 10:19:56 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 QQnrxh24331 for ; Thu, 5 Dec 2002 10:19:48 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 QQnrxh12126 for ; Thu, 5 Dec 2002 10:19:03 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 QQnrxh25614 for ; Thu, 5 Dec 2002 10:19:02 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 QQnrxh25584 for ; Thu, 5 Dec 2002 10:19:01 GMT Received: by cbibipnt08.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Thu, 5 Dec 2002 10:18:07 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A35389014CFC94@i2km07-ukbr.domain1.systemhost.net> To: swallow@cisco.com, mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Thu, 5 Dec 2002 10:17:52 -0000 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 Initial set of commments: The 1st sentence of the Introduction says: "This document describes a simple and efficient mechanism that can be used to detect data-plane failures in MPLS LSPs." Let me examine this single statement: 'Simple' - This is simple? This is quite complex IMO. I have read it several times now, and I have to apologise and say I still don't fully understand all aspects of it (also please refer to the specific protocol observations/questions from Shahram Davari and Dave Allan here). So I am not sure that a claim that is it 'simple' is appropriate.....however, other operators may disagree with me on this, and if so please say so. 'Efficient' - I am missing understanding where the efficiency arises, so can you please explain what you mean by this? It seems as though it's a solution largely aimed at addressing the fault-management complexity created by LDP, eg merging and use of proprietary ECMP. For p2p LSPs the solution described in Y.1711 is signficantly 'simpler and more efficient' (by a very large margin IMO), so I don't think its valid to assume this is the right solution for all types of LSP. Do you disagree with this? Note - Here is a suggestion/thought. Since all instances of mp2p LSP *must* run a p2p LSP instance above them to remove the merging....directly so in Martini et al, and indirectly so in L3/rfc2547 VPNs where resolution to the VPN (inner LSP) then requires assumption of IP to properly demerge......then a more 'efficient' solution might be to use Y.1711 on the top-level essentially p2p LSPs and only invoke ad hoc tools (like LSP-Ping) on the lower mp2p LSPs when the top-level LSP indicates a problem. Seems reasonably simple to do for PWE3 cases of XoverMPLS, but not so sure its that straightfoward for the L3 VPNs. As I say, just a suggestion/thought. 'Detect data-plane failures' - I can't seem to find anywhere that these data-plane failures are specified (eg entry criteria, exit criteria and consequent actions). Can you please point me to the appropriate document where these failures are specified so that I can judge if this claim is true? thanks and regards, Neil From owner-mpls@UU.NET Thu Dec 5 10:16: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 KAA15681 for ; Thu, 5 Dec 2002 10:16:46 -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 QQnryb13749 for ; Thu, 5 Dec 2002 15:19: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 QQnryb09289; Thu, 5 Dec 2002 15:17:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQnryb18865 for mpls-outgoing; Thu, 5 Dec 2002 15:16:57 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 QQnryb18855 for ; Thu, 5 Dec 2002 15:16: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 QQnryb01691 for ; Thu, 5 Dec 2002 15:16:14 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 QQnryb08916 for ; Thu, 5 Dec 2002 15:16:13 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 QQnryb08745 for ; Thu, 5 Dec 2002 15:16:08 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB5FGYg0025456 for ; Thu, 5 Dec 2002 10:16:35 -0500 (EST) 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 KAA06794 for ; Thu, 5 Dec 2002 10:16:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB5FG5r21223 for mpls@uu.net; Thu, 5 Dec 2002 10:16:05 -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 QQnryb18423 for ; Thu, 5 Dec 2002 15:15:00 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 QQnrya13256 for ; Thu, 5 Dec 2002 15:13:59 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 QQnrya04320 for ; Thu, 5 Dec 2002 15:13:59 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 QQnrya04270 for ; Thu, 5 Dec 2002 15:13:57 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 KAA13502; Thu, 5 Dec 2002 10:11:24 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212051511.KAA13502@workhorse.fictitious.org> To: Dimitri.Papadimitriou@alcatel.be cc: Manoj Agiwal , "'Ccamp (E-mail)" , "'mpls@UU.NET'" Reply-To: curtis@fictitious.org Subject: Re: make-before-break in Gmpls In-reply-to: Your message of "Wed, 04 Dec 2002 02:38:38 +0100." <3DED5C9E.A4679846@alcatel.be> Date: Thu, 05 Dec 2002 10:11:23 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3DED5C9E.A4679846@alcatel.be>, Dimitri.Papadimitriou@alcatel.be wri tes: > hi, > > i think this issue concerning "se style" has been discussed > some time ago but let's try here to give a bit more details, > lsp's in gmpls are control plane entities mapping data plane > ones, merging here does get sense if and only if the data > plane would deliver the same capability, since the soft- > provisioning that we can expect in shared meshed restoration > is purely a control plane driven mechanism the corresponding > entity doesn't occur at the data plane level and in particular > for tdm, lsc and fsc lsp's, once committed you find out the > ff style as used today, as such there is no today something > like you seem to assume as setup of an lsp "split" it when > a recovery lsp is needed and then "merge" it back when the > recovery lsp find back the working lsp path, then next even > if the methods that are under definition may be thought as > similar to the frr ones, the following for instance wouldn't > strictly apply (see fast-reroute): > > "When using the sender-template-specific approach, the protected > LSPs and the backup paths SHOULD use the Shared Explicit (SE) > style. This allows bandwidth sharing between multiple backup > paths. The backup paths and the protected LSP MAY be merged by the > Detour Merge Points, when the ERO from the MP to the egress is the > same on each LSP to be merged, as specified in [RSVP-TE]." > > this because for non-packet networks do soft-provisioning > means let the capability to share the bandwidth on a control > plane view of the resource basis otherwise just provision > it (commit it) since having a dedicated soft-provisioning > on a per lsp basis just means be dedicated at the data plane > level (if we assume a consistent usage of the mechanisms), > and on the other side have merging (not multiplexing) of > lsc or tdm at the data plane level is impossible (afaik) > thus the fact that one knows that the requested lsp is for > recovery purposes (link protection tlv s bit set) and its > resources have to allocated within a pool but not committed > (ie reserved) something which is needed in any case, do > the job here. > > hope this clarifies a bit, > - dimitri. This doesn't seem to me to clear it up. In make-before-break, sharing bandwidth means that you will use one or the other LSP, but never both. Same with FRR - the primary or detour is used, but not both at the same time. Such a merge is at least in principle possible for TDM, LSC, and FSC (although LSC required either same wavelength or wavelength shifting or OEO). I said "in principle". Therefore in principle, SE could be used for TDM, LSC, and FSC. In practice, this may not (ever) be true. The ingress would need to know if bandwidth was shareable when doing a reroute. Otherwise, it may pick a path for which the RSVP signaling always fails for no apparent reason. That the RSVP signaling would fail would not be apparent from the TE-LSDB before the signaling. Reroute by trial and error is not a good option. Is there a way for the ingress to know on which "links" bandwidth is shareable? Should it simply be assumed that bandwidth is not shareable on any TDM, LSC, and FSC links? Curtis > Manoj Agiwal wrote: > > > > Hi , > > The gmpls architecture documents says > > "GMPLS does not add anything new. Elegant re-routing is possible with the > > concept of "make-before-break" whereby an old path is still used while a ne > w > > path is set up by avoiding double reservation of resources. Then, the node > > performing the re-routing can swap on the new path and close the old path. > > This feature is supported with RSVP-TE (using shared explicit filters) and > > CR-LDP (using the action indicator flag). > > Will this feature will hold good for optical networks as well , > > where we have TDM , LSC LSPs. This would require use of > > SE style in optical networks . Does signaling has to take care of not > > reserving extra resources ( bandwidth / time slot ) > > across the common path of the two LSPs , what will happen at the nodes > > where the two routes diverge and converge . > > Is it expected that the signal will get multicast to both the routes , > > and at the node where the route converge the signal > > is selected from the better of the two paths till the rerouted LSP is > > torn down . > > Regards, > > Manoj > > -- > Papadimitriou Dimitri > E-mail : dimitri.papadimitriou@alcatel.be > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > E-mail : dpapadimitriou@psg.com > Public : http://psg.com/~dpapadimitriou/ > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > Phone : Work: +32 3 2408491 - Home: +32 2 3434361 > From owner-mpls@UU.NET Thu Dec 5 10:35:31 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 KAA16537 for ; Thu, 5 Dec 2002 10:35:31 -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 QQnryc07667 for ; Thu, 5 Dec 2002 15:38:16 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 QQnryc02564; Thu, 5 Dec 2002 15:36:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQnryc20242 for mpls-outgoing; Thu, 5 Dec 2002 15:35:43 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 QQnryc20229 for ; Thu, 5 Dec 2002 15:35:37 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 QQnryc01562 for ; Thu, 5 Dec 2002 15:34:55 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 QQnryc01252 for ; Thu, 5 Dec 2002 15:34:55 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 QQnryc01241 for ; Thu, 5 Dec 2002 15:34:54 GMT Received: by mbibipnt08.nat.bt.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 15:35:11 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A35389014CFC9E@i2km07-ukbr.domain1.systemhost.net> To: swallow@cisco.com, mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Thu, 5 Dec 2002 15:34:45 -0000 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 2nd set of comments on sections 2 and 3: 1 In section 2, 1st sentence says: "When an LSP fails to deliver user traffic, the failure cannot always be detected by the MPLS control plane. There is a need to provide a tool that would enable users to detect such traffic "black holes" or misrouting within a reasonable period of time; and a mechanism to isolate faults." Agreed with initial sentence. But can you please help me understand: - what is a 'reasonable time'? - if variable then I assume we can't have operator/vendor-wide defect detection/handling standardised, nor (un)availability definitions standardised, nor QoS time-bases (ie when in available state) standardised.....is this a correct interpretation?....or is some default value being considered to allow this? - what consequent actions are taken before detection (I assume none) and after detection, eg: * is traffic suppressed if misrouting detected to protect possible customer traffic integrity/security compromise? * how are higher layer networks (eg ATM in case of ATMoverMPLS), and specifically the trail termination points therein, informed that they should not raise defect alarms? * what happens to the collection of any QoS metrics (at the LSP sink) that may be being collected when defects are detected? 2 Last para in section 2 says: "One way these tools can be used is to periodically ping a FEC to ensure connectivity. If the ping fails, one can then initiate a traceroute to determine where the fault lies. One can also periodically traceroute FECs to verify that forwarding matches the control plane; however, this places a greater burden on transit LSRs and thus should be used with caution." Ping test will detect simple breaks (either direction....this then needs the direction resolving of course). Ping won't detect misrouting/mismerging.....this requires tracing. Agree it places burden on all transit routers so should used with caution, eg ad hoc diagnostic tool. CV (TTSI) caters for this by requiring only LSP sink points to automatically detect/handle the defect (on seeing an incoming unexpected TTSI value), so intermediate nodes are transparent to the CV pkt and so just treat it as normal traffic I point this out to show that there is a major difference in complexity between this approach and that of Y.1711....so for p2p LSPs at least, Y.1711 gives a far simpler solution to this defect detection/handling problem. 3 Section 3 1st sentence says: "An MPLS echo request is a (possibly labelled) UDP packet....". Why is it only 'possibly labelled'? I thought the intent was to force the Ping traffic down the same data-plane as labelled normal traffic....so it seems it must be labelled. 4 I note in the 'Reply Mode' (top p5) that a 'Do not reply' option is given. Reading the subsequent explanation this seems as though it's a 1-way off-line stats (delay mainly?) gathering exercise. This is OK, but it seems a shame that we can't also associate some proper sink-point real-time defect detection/handling....seems like it mimics some aspects of CV but with none of the defect detection/handling ability. - I assume you have to poll the sink point every so often to see how its doing? - what happens if you change the source pinging rate....do you have to tell the sink about this? 5 In the same section.....can you please explain in a little more detail why there are 2 IPv4/UDP (and no v6??) reply modes, one without router alert set and one with router alert set? The text seems to indicate the latter is more reliable than the former. 6 In the same section......why is there an option to reply by the RSVP control-plane? What scenario is this addressing that the above don't? Further, some guidance on when to select which option would be useful. 7 In the same section....I assume if a missed sequence number event is detected, there is no ability to determine if this was the outgoing or return direction? How long does one wait before declaring a lost sequence number anyway? And does this vary with the return mode selected? 8 In the same section.....does the responding node copy the 'sent' time-stamp from the echo-request to the echo-response? 9 In the same section....its seems some of the Return Codes are relevant only to the Ping mode and some only to Trace mode. I think it would be useful to separate them (and also indicate if any are common to both modes). 10 In section 3.1....I'm a little unclear about multiple FEC stacks. I seem to get the message from the text that a *single* response is only elicited from the very bottom of the label stack (ie the highest level/layer LSP sink point). This seems OK under the restriction that for the FEC stack considered, the corresponding multiple LSP trail termination points reside on the same node....and in the VPN example given this is true. Is this restriction on FEC stacking and hierarchical LSP termination points correct? And am I also correct in assuming only a single response is ever expected in a stacked FEC case? (I noted Shahram has raised a very similar issue in his points No. 4 and (although a slightly different issue) No. 6). 11 In section 3.2......Can the Downstream Mapping optional TLV be used with an RSVP 'Reply Mode'? 12 In the same section.....There is the TTL decrement anomaly which both Shahram and Dave have pointed out. However, I think you need to expand on the bit which effectively says 'how to determine downstream nodes is out of scope' since, if I understand what is going on here correctly, this is an attempt to trace misbranching traffic. However, please correct me (and enlighten me) if I am interpreting this section incorrectly. 13 In the same section....what is the PAD TLV function for? Thanks.....more later...regards, Neil From owner-mpls@UU.NET Thu Dec 5 10:53: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 KAA17353 for ; Thu, 5 Dec 2002 10:53:54 -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 QQnryd01171 for ; Thu, 5 Dec 2002 15:56: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 QQnryd29365; Thu, 5 Dec 2002 15:55:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQnryd21907 for mpls-outgoing; Thu, 5 Dec 2002 15:55:43 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 QQnryd21894 for ; Thu, 5 Dec 2002 15:55:28 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 QQnryd28751 for ; Thu, 5 Dec 2002 15:54: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 QQnryd01720 for ; Thu, 5 Dec 2002 15:54:45 GMT Received: from ihemail2.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQnryd01713 for ; Thu, 5 Dec 2002 15:54:44 GMT Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gB5FshH00755; Thu, 5 Dec 2002 10:54:43 -0500 (EST) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.58.32]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA28928; Thu, 5 Dec 2002 10:54:42 -0500 (EST) Message-ID: <3DEF76C1.E6A29D03@lucent.com> Date: Thu, 05 Dec 2002 10:54:41 -0500 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: curtis@fictitious.org CC: "'Ccamp (E-mail)" , "'mpls@UU.NET'" Subject: Re: make-before-break in Gmpls References: <200212051511.KAA13502@workhorse.fictitious.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis, > The ingress would need to know if bandwidth was shareable when doing a > reroute. Otherwise, it may pick a path for which the RSVP signaling > always fails for no apparent reason. That the RSVP signaling would > fail would not be apparent from the TE-LSDB before the signaling. > Reroute by trial and error is not a good option. > > Is there a way for the ingress to know on which "links" bandwidth is > shareable? Should it simply be assumed that bandwidth is not > shareable on any TDM, LSC, and FSC links? > You raised some good points here. For TDM, LSC and FSC, external resources (link/port) can be in two states. If a internal cross connection is performed, the associated external resource is committed and thus not sharable anymore. Otherwise, it is sharable. So we can treat any non-committed resource as sharable. The rest are not sharable. Then the complication is when a non-committed resource gets committed, the rest paths sharing the resource need to be re-arranged in order to guarantee the SLA in case of double failures. How does FRR handle this? Thanks, Yangguang From owner-mpls@UU.NET Thu Dec 5 11:41: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 LAA18865 for ; Thu, 5 Dec 2002 11:41:46 -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 QQnryg00460 for ; Thu, 5 Dec 2002 16:44:29 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 QQnryg26163; Thu, 5 Dec 2002 16:42:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQnryg13975 for mpls-outgoing; Thu, 5 Dec 2002 16:42:03 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 QQnryg13968 for ; Thu, 5 Dec 2002 16:41:58 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 QQnryg14319 for ; Thu, 5 Dec 2002 16:41: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 QQnryg25170 for ; Thu, 5 Dec 2002 16:41:37 GMT Received: from cbibipnt05.hc.bt.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQnryg25149 for ; Thu, 5 Dec 2002 16:41:36 GMT Received: from cbibipnt05.hc.bt.com ([147.149.196.177]) by cbibipnt05.hc.bt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2654.89) id YH9KGQFH; Thu, 5 Dec 2002 16:41:00 -0000 Received: FROM celiborn.ip-engineering.bt.com BY cbibipnt05.hc.bt.com ; Thu Dec 05 16:41:00 2002 0000 Received: from celiborn.galadriel.bt.co.uk ([132.146.100.200] helo=ip-engineering.bt.com) by celiborn.ip-engineering.bt.com with esmtp (Exim 4.04) id 18Jz3Q-00004M-00 for mpls@UU.NET; Thu, 05 Dec 2002 16:40:48 +0000 X-Mailer: exmh version 2.0.3 9/28/98 To: mpls@UU.NET Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Wed, 04 Dec 2002 11:02:36 EST." <9FBD322B7824D511B36900508BF93C9C06565472@zcard031.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Dec 2002 16:40:48 +0000 From: Peter Willis Message-Id: Sender: owner-mpls@UU.NET Precedence: bulk Comments on draft-ietf-mpls-lsp-ping-01.txt "4.1. Sending an MPLS Echo Request An MPLS echo request is a (possibly) labelled UDP packet. The IP header is set as follows: the source IP address is a routable address of the sender; the destination IP address is a (randomly chosen) address from 127/8; the IP TTL is set to 1. " Question 1 - What does "possibly" mean above? Why possibly? Would it work if it was not labelled? Question 2 - The destination address 127/8, we should also have an IPv6 destination loopback address if we want to be future proof. (Would that be ::1 in IPv6 speak?) Question 3 - What is a "routable address" when we have IP VPNs? I'm thinking if the LSP ping originates in a customer-routed domain (or the edge carrier in a carriers-carrier scenario) then in the core (P routers) that address isn't routable! Regards, ------------------------------------------------------------------------------- This post represents the views of the author and does not necessarily accurately represent the views of BT. ------------------------------------------------------------------------------- Peter Willis | E-mail: peter.j.willis@bt.com IP Technology Strategist | BTexact Technologies CTO | ------------------------------------------------------------------------------- From owner-mpls@UU.NET Thu Dec 5 12:30:12 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 MAA20714 for ; Thu, 5 Dec 2002 12:30: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 QQnryk20821 for ; Thu, 5 Dec 2002 17:32:54 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 QQnryj09866; Thu, 5 Dec 2002 17:27:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQnryj06247 for mpls-outgoing; Thu, 5 Dec 2002 17:27:13 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 QQnryj06242 for ; Thu, 5 Dec 2002 17:27: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 QQnryj10239 for ; Thu, 5 Dec 2002 17:25: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 QQnryj11795 for ; Thu, 5 Dec 2002 17:25:07 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 QQnryj11786 for ; Thu, 5 Dec 2002 17:25:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB5HPYMb015027 for ; Thu, 5 Dec 2002 12:25:34 -0500 (EST) 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 MAA17685 for ; Thu, 5 Dec 2002 12:25:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB5HP5600653 for mpls@uu.net; Thu, 5 Dec 2002 12:25: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 QQnryj05893 for ; Thu, 5 Dec 2002 17:24:00 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 QQnryj02175 for ; Thu, 5 Dec 2002 17:22:43 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 QQnryj09232 for ; Thu, 5 Dec 2002 17:22:43 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 QQnryj09207 for ; Thu, 5 Dec 2002 17:22:41 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 MAA14262; Thu, 5 Dec 2002 12:21:38 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212051721.MAA14262@workhorse.fictitious.org> To: Yangguang Xu cc: curtis@fictitious.org, "'Ccamp (E-mail)" , "'mpls@UU.NET'" Reply-To: curtis@fictitious.org Subject: Re: make-before-break in Gmpls In-reply-to: Your message of "Thu, 05 Dec 2002 10:54:41 EST." <3DEF76C1.E6A29D03@lucent.com> Date: Thu, 05 Dec 2002 12:21:38 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3DEF76C1.E6A29D03@lucent.com>, Yangguang Xu writes: > Curtis, > > > The ingress would need to know if bandwidth was shareable when doing a > > reroute. Otherwise, it may pick a path for which the RSVP signaling > > always fails for no apparent reason. That the RSVP signaling would > > fail would not be apparent from the TE-LSDB before the signaling. > > Reroute by trial and error is not a good option. > > > > Is there a way for the ingress to know on which "links" bandwidth is > > shareable? Should it simply be assumed that bandwidth is not > > shareable on any TDM, LSC, and FSC links? > > > > You raised some good points here. For TDM, LSC and FSC, external resources > (link/port) can be in two states. If a internal cross connection is performed > , > the associated external resource is committed and thus not sharable anymore. > Otherwise, it is sharable. So we can treat any non-committed resource as > sharable. The rest are not sharable. > > Then the complication is when a non-committed resource gets committed, the re > st > paths sharing the resource need to be re-arranged in order to guarantee the S > LA > in case of double failures. How does FRR handle this? The answer to your question "How does FRR handle this?" is "not very well at the moment but there is potential to do better". While seemingly flipant its an accurate answer. I'll provide detail below. There are two uses for SE, make-before-break and FRR. I don't mean to dodge your question, but I'd like to discuss make-before-break first, then FRR. Unlike FRR, make-before-break reroute from the ingress is done with full bandwidth reservations (reserved and commited) and results in no excess bandwidth being reserved and then wasted. The new LSP is reserved on a slightly different path but is able to share bandwidth with the LSP it is replacing on any links in common in order to accomplish a smooth transition. It is important for the ingress to know if this type of sharing is possible at all links for which both the old and new LSP have in common and for which not enough bandwidth is available for both the old and new without sharing. Currently FRR cannot accurately account for bandwidth that can be shared among backups that are not expected to fail at the same time (do not protect any common SRLG). This leaves two options for deployment, reserve/commit full bandwidth on the backups or don't reserve/commit full bandwidth on the backups. In the former case far more bandwidth is reserved than will ever be needed. This might be OK on a network that was massively overprovisioned. In the latter case, there is a chance that when the failures occur, the backups paths will be congested (for packet links) or if the reservation must be increased to "commit" the resource, then that operation will fail. Practitioners seem to be opting for zero bandwidth reservations which are increased to a full bandwidth reservations when the PLR puts the backup into use. This is not a good solution for packet networks. It is even less attractive for TDM, LSC and FSC. Various methods to provide bandwidth reservation sharing have been made going back as for as 1999 (afaik, maybe earlier as well). Some involve signaling the link, node, or set of SRLGs that a backup will be using, and puts the intellegence to determine the potential for sharing at each link. One involves simply advertising the amount of shareable bandwidth and sharable bandwidth used and puts the intellegence at each PLR. The issue of how backup bandwidth is shared, and therefore your question of "How does FRR handle this?" is tangential to the issue of whether TDM, LSC and FSC can share resources that are reserved and committed by more than one LSP for which only one of those LSPs will use the resource at one time and will use the entire resource to the exclusion of the others. It is "in principle" possible for TDM, LSC and FSC (with the prior caveat regarding same-color or wavelegth conversion). If the ingress (or PLR for FRR) is to make an accurate decision, then it needs to either know whether the sharing is possible before attempting to setup an LSP, or it must assume that TDM, LSC and FSC cannot support sharing. IMHO traffic layout by trial and error is not an option. Curtis > Thanks, > > Yangguang From owner-mpls@UU.NET Thu Dec 5 14:42:44 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 OAA25297 for ; Thu, 5 Dec 2002 14:42:43 -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 QQnryt08069 for ; Thu, 5 Dec 2002 19:45: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 QQnrys02868; Thu, 5 Dec 2002 19:43:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrys23056 for mpls-outgoing; Thu, 5 Dec 2002 19:42: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 QQnrys23051 for ; Thu, 5 Dec 2002 19:42:34 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 QQnrys03835 for ; Thu, 5 Dec 2002 19:42: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 QQnrys26438 for ; Thu, 5 Dec 2002 19:42:07 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 QQnrys26419 for ; Thu, 5 Dec 2002 19:42:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB5JgYMs005109 for ; Thu, 5 Dec 2002 14:42:35 -0500 (EST) 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 OAA29225 for ; Thu, 5 Dec 2002 14:42:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB5Jg5M08624 for mpls@uu.net; Thu, 5 Dec 2002 14:42:05 -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 QQnrys22843 for ; Thu, 5 Dec 2002 19:40: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 QQnrys04112 for ; Thu, 5 Dec 2002 19:40: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 QQnrys07918 for ; Thu, 5 Dec 2002 19:40: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 QQnrys07901 for ; Thu, 5 Dec 2002 19:40:11 GMT Received: (qmail 24716 invoked by uid 104); 5 Dec 2002 19:40:10 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4236. . Clean. Processed in 0.541482 secs); 05 Dec 2002 19:40:10 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 5 Dec 2002 19:40:10 -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 gB5JdxQ06911; Thu, 5 Dec 2002 11:39:59 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Thu, 5 Dec 2002 11:39:59 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B44@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'George Swallow'" , mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Thu, 5 Dec 2002 11:39:57 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Some more comments: 22) I can't understand section 3.2 at all. Since TTL=n+1 makes no sense, for the sake of argument I'll assume you meant TTL=n-1. Now let's assume the following topology: L1 L2 L3 -------R1-------R2-------R3 \ L4 \-----R4 In which R1, R2, R3, and R4 are LSRs and L1, L2, L3 and L4 are each a set of labels that are received on those LSRs. It seems from the text that the following sequential behavior is expected: (DM means Downstream Mapping TLV) Ingress => Echo Request: DM (R1, L1) R1 => Echo Reply : DM (R2, L2) Ingress => Echo Request: DM (R2, L2) R2 => Echo Reply : DM (R3, L3 and R4, L4) Ingress => Echo Request: DM (R3, L3 and R4, L4) etc. Is this the behavior that is intended? And does it apply only to trace-route? What is the purpose of this function? it seems that DM is being used to extract the whole switching table of each interface, is that correct? If so, then it is neither ping, nor trace-route? 23) section 4.1: In order to exercise all the ECMP paths, you need to scan through all 127/8 addresses (16 million of them), don't you think this is not feasible? 24) Section 4.1: Why should an LSR send multiple echo requests with the same seq#? What function is in mind that can't be achieved by incrementing seq #? -Shahram > -----Original Message----- > From: Shahram Davari > Sent: Wednesday, December 04, 2002 4:40 PM > To: 'George Swallow'; mpls@UU.NET > Subject: RE: Last call on LSP Ping > > > Hi, > > Although I have no hope of getting any response, but here is > a repeat of my ignored comments raised in March, 2002 and > some new ones: > > 1) Time stamp: Why is the time stamp in both seconds and > microseconds? The microsecond could count up to 71 minutes. > Isn't that enough? Why isn't the > same timestamp used in ICMP not used here which says: > > The Timestamp is a right-justified, 32-bit timestamp in > milliseconds since midnight UT. > > 2) Section 3: Why the echo reply time stamp is not similar to > ICMP echo-reply time-stamp in which a received time-stamp and > sent-time stamp is set by the receiver? Which gives you the > processing time at the receiver too. > > 3) Section 3.1: If I understand it correctly a Target FEC TLV > could consist of a number of FEC stack sub-TLVs. Therefore it > seems that the number of these sub-TLVs could be determined > by looking at the Target FEC TLV length field and subtracting > the sub-TLV lengths from it. But the text says it could be > determined by looking at the sub-TLV length field. Needs > clarification. > > 4) Section 3.1: How can you ping multiple FECs simultaneously > (i.e., piggy back multiple pings), while each FEC belongs to > a different level of the label stack? This requires that all > those hierarchical labels (LSPs) be initiated and terminated > at the same LSRs. Also how do you intend to generate error > response if the result of some of those FEC pings are > positive and some are negative? > > 5) Section 3 under return code. There is no return code for > the case that one of the FECs fail while others pass, or when > one of the label mappings don't pass, while others pass. > > 6) Why doesn't the MPLS ping permit pinging multiple FECs > that belong to the same LSP level? It seems that if 1000s of > FECs are all mapped to the same LSP, then 1000's of > MPLS-pings are required. > > 7) Why is the downstream label field in the downstream > mapping TLV 24 bits? Is it for ATM? How is the 20 bit label > mapped to this 24 bit? > > 8) Section 3.2: When X receives a packet with TTL of n>1, > shouldn't it compute the downstream LSRs that could receive > the packet with TTL=n-1 (rather than TTL=n+1 as indicated)? > > 9) Section 3.2 last paragraph: Does this apply to trace-route > mode only? > > 10) Section 4.3: Does the downstream mapping TLV of the > echo-reply replace the downstream mapping TLV of the > echo-request or it is appended to it? > > 11) Section 4.5: If the egress for an FEC stack being pinged > doesn't support MPLS ping, isn't an ICMP TTL expire message > generated for the IP TTL=1 received (instead of no reply as > mentioned in the draft)? > > 12) Section 5 2nd paragraph last sentence I think should be > changed to: "Note that this may not work if some transit LSR > does not support IP options" (not 'MPLS ping' as mentioned in > the draft) > > 13) Section 5: Is RSVP-TE return path used only in "ping" > mode or also in trace-route mode? > > 14) Section 5.3 last paragraph: I think you need to delete > ICMP here. It has no meaning here. > > 15) Section 5.5: I think you need to mention that if > intermediate LSRs don't support refresh reduction, then it > could take many minutes before the echo-reply is received at > the source. > > 16) Section 3.1.7 and 3.1.8: What is Encapsulation Type and > how is it encoded? > > 17) Section 3.2: Why are there multiple downstream labels in > the downstream mapping? do they belong to different LSP > levels? Or the figure is simply showing many downstream mapping TLVs? > > 18) Section 3.3: what is the purpose of Pad TLV? > > 19) Section 4.3: Should an Echo reply always have a > downstream mapping TLV even if no downstream mapping TLV is > in the Echo request? > > 20) Section 4.4: Seems like back to back echo-request can't > be sent before receiving the echo-reply of previous > echo-request. Why this limitation? > > 21) Section 5.1: How is the downstream mapping TLV conveyed > in the echo-reply sent over RSVP-TE? it seems no downstream > mapping TLV is defined for RSVP-TE. > > > Thanks, > -Shahram > > > -----Original Message----- > > From: George Swallow [mailto:swallow@cisco.com] > > Sent: Tuesday, December 03, 2002 5:52 PM > > To: mpls@UU.NET > > Subject: Last call on LSP Ping > > > > > > This message begins a workgroup last call on: > > > > Detecting MPLS Data Plane Liveness > > > > draft-ietf-mpls-lsp-ping-01.txt > > > > The last call ends on Dec 16, 2002 2400H GMT. > > > > George & Loa > > > > > ====================================================================== > > George Swallow Cisco Systems > (978) 497-8143 > > 250 Apollo Drive > > Chelmsford, Ma 01824 > > > > > > > From owner-mpls@UU.NET Thu Dec 5 17:29: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 RAA03037 for ; Thu, 5 Dec 2002 17:29: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 QQnrze12555 for ; Thu, 5 Dec 2002 22:32:44 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 QQnrze07793; Thu, 5 Dec 2002 22:30:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrze01986 for mpls-outgoing; Thu, 5 Dec 2002 22:30: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 QQnrze01981 for ; Thu, 5 Dec 2002 22:30: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 QQnrzd16539 for ; Thu, 5 Dec 2002 22:29:23 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 QQnrzd05757 for ; Thu, 5 Dec 2002 22:29:23 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQnrzd05746 for ; Thu, 5 Dec 2002 22:29:22 GMT Received: from cisco.com (erosen-u10.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB5MTGK0027806; Thu, 5 Dec 2002 14:29:16 -0800 (PST) Message-Id: <200212052229.gB5MTGK0027806@sj-msg-core-1.cisco.com> To: George Swallow cc: mpls@UU.NET Subject: Re: Last call on LSP Ping In-reply-to: Your message of Tue, 03 Dec 2002 17:51:34 -0500. <200212032251.RAA01985@bifocal.cisco.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 05 Dec 2002 17:29:16 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA03037 Re the last call on "LSP Ping", I have a few questions and comments on the ping functionality. From section 4.1: An MPLS echo request is a (possibly) labelled UDP packet. The IP header is set as follows: the source IP address is a routable address of the sender; the destination IP address is a (randomly chosen) address from 127/8; the IP TTL is set to 1. The source UDP port is chosen by the sender; the destination UDP port is set to 3503 (assigned by IANA for MPLS echo requests). If the echo request is labelled, the MPLS TTL on all the labels except the outermost should be set to 1. Although this suggests that the MPLS echo request might be sent as an unlabeled UDP datagram, that doesn't actually seem possible. If you try to send a UDP datagram to 127.0.0.1 it won't go very far. (In fact, RFC 3330 seems to make it illegal to send over the network an IP packet whose address is in the range 127/8. Whether it makes it illegal to send such packets encapsulated is less clear.) So I think it is REQUIRED that the echo request be labeled. Actually, I think the requirements are: - The originator of the echo request decides to test a FEC or a stack of FECs. - The originator determines the next hop for that FEC, or for the topmost FEC in the stack. - The originator labels the echo request with the label stack that is used for sending packets with that FEC via that next hop. - The originator sends the labeled echo request to that next hop. (If reaching the next hop requires going through an LSP tunnel, this might causes more labels to be pushed on the stack.) It would also be nice if the document were more explicit about what sorts of error conditions elicit what sorts of responses. If you get no response, you can conclude that one of the following conditions holds: - The label stack you put on the echo request did not get the UDP datagram delivered a node in your network which supports LSP Ping. - The echo response couldn't be delivered for some reason. (The option for replying via the control plane is intended to eliminate this possibility.) If the UDP datagram does end up, unlabeled, somewhere where LSP Ping is understood, then the 127/8 address will cause it to be processed at that point. Presumably the responder is supposed to look at the stack of FECs, and determine whether it is an LSP egress for each FEC in the stack. If so, it responds with a return code of 3; otherwise with a return code of 4. (I'm ignoring the "downstream router" stuff for now.) So if you get a response with a return code of 3, you know that it is possible to get MPLS packets to the responder, and that the responder is the right place to be sending packets that are in the specified FEC or stack of FECs. If you get a response with a return code of 4, you know that something has gone wrong somewhere, your labeled packets are going someplace other than where they are supposed to go, and you'd better do something right away. The suggestion to randomly choose IP destination addresses from the 127/8 block is, presumably, the way to ensure that the various paths created by equal cost load splitting get exercised. The question is, how many pings do you need to send in order to get good coverage? If the request has a stack of n FECs, and the responder is the egress for the topmost m FECs but not for the bottommost n-m, it might be useful to have a way to indicate that in the response. Some minor observations: - The notion of "time of day" is not well-defined. I have no idea what is supposed to be put in the time of day fields. This doesn't really seem that useful anyway unless there is synchronized time. - I'm not sure that the sequence number really needs to be a separate field from the sender's handle. It just seems like an extension of the handle, whose semantics are private to the sender. From owner-mpls@UU.NET Thu Dec 5 19:06: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 TAA05597 for ; Thu, 5 Dec 2002 19:06:40 -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 QQnrzk16386 for ; Fri, 6 Dec 2002 00:09: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 QQnrzk05429; Fri, 6 Dec 2002 00:03:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrzk10581 for mpls-outgoing; Fri, 6 Dec 2002 00:02: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 QQnrzk10220 for ; Fri, 6 Dec 2002 00:02:46 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 QQnrzk24352 for ; Fri, 6 Dec 2002 00:02: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 QQnrzk04840 for ; Fri, 6 Dec 2002 00:02:43 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 QQnrzk04820 for ; Fri, 6 Dec 2002 00:02:42 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB603AVS006730 for ; Thu, 5 Dec 2002 19:03:10 -0500 (EST) 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 TAA17572 for ; Thu, 5 Dec 2002 19:02:41 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB602fO24185 for mpls@uu.net; Thu, 5 Dec 2002 19:02:41 -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 QQnrzk05496 for ; Fri, 6 Dec 2002 00:01:23 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 QQnrzk00782 for ; Fri, 6 Dec 2002 00:01: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 QQnrzk03332 for ; Fri, 6 Dec 2002 00:01:14 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 QQnrzk03318 for ; Fri, 6 Dec 2002 00:01:14 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB601VN5006591; Thu, 5 Dec 2002 19:01:31 -0500 (EST) 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 TAA17484; Thu, 5 Dec 2002 19:01:02 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id TAA24892; Thu, 5 Dec 2002 19:01:02 -0500 (EST) Message-Id: <200212060001.TAA24892@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: erosen@cisco.com cc: George Swallow , mpls@UU.NET, swallow@cisco.com Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Thu, 05 Dec 2002 17:29:16 EST." <200212052229.gB5MTGK0027806@sj-msg-core-1.cisco.com> Date: Thu, 05 Dec 2002 19:01:02 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > Re the last call on "LSP Ping", I have a few questions and comments on the > ping functionality. > > >From section 4.1: > > > An MPLS echo request is a (possibly) labelled UDP packet. The IP > header is set as follows: the source IP address is a routable address > of the sender; the destination IP address is a (randomly chosen) > address from 127/8; the IP TTL is set to 1. The source UDP port is > chosen by the sender; the destination UDP port is set to 3503 > (assigned by IANA for MPLS echo requests). If the echo request is > labelled, the MPLS TTL on all the labels except the outermost should > be set to 1. > > Although this suggests that the MPLS echo request might be sent as an > unlabeled UDP datagram, that doesn't actually seem possible. If you try to > send a UDP datagram to 127.0.0.1 it won't go very far. (In fact, RFC 3330 > seems to make it illegal to send over the network an IP packet whose address > is in the range 127/8. Whether it makes it illegal to send such packets > encapsulated is less clear.) So I think it is REQUIRED that the echo > request be labeled. Actually, I think the requirements are: > > - The originator of the echo request decides to test a FEC or a stack of > FECs. I think you're really only testing one FEC. The stack gives you a way of noting how you set off the get to that FEC (assuming you had multiple options - like two TE tunnels). > - The originator determines the next hop for that FEC, or for the topmost > FEC in the stack. > > - The originator labels the echo request with the label stack that is used > for sending packets with that FEC via that next hop. > > - The originator sends the labeled echo request to that next hop. (If > reaching the next hop requires going through an LSP tunnel, this might > causes more labels to be pushed on the stack.) Yes. I think we need to rework that section and be more explicit about how it works. As far as I'm concerned the only place you might have an unlabelled Ping is after a PHP. I was also assuming that you only Ping one FEC at a time. I think we should also say that in the text. If others think we need to be able to do more than one at a time then we need a good deal of text to describe that. > It would also be nice if the document were more explicit about what sorts of > error conditions elicit what sorts of responses. If you get no response, > you can conclude that one of the following conditions holds: > > - The label stack you put on the echo request did not get the UDP datagram > delivered a node in your network which supports LSP Ping. > > - The echo response couldn't be delivered for some reason. (The option for > replying via the control plane is intended to eliminate this possibility.) (Well, at least seriously ameliorate the situation.) Also good text to include. > If the UDP datagram does end up, unlabeled, somewhere where LSP Ping is > understood, then the 127/8 address will cause it to be processed at that > point. Presumably the responder is supposed to look at the stack of FECs, > and determine whether it is an LSP egress for each FEC in the stack. If so, > it responds with a return code of 3; otherwise with a return code of 4. (I'm > ignoring the "downstream router" stuff for now.) > > So if you get a response with a return code of 3, you know that it is > possible to get MPLS packets to the responder, and that the responder is the > right place to be sending packets that are in the specified FEC or stack of > FECs. If you get a response with a return code of 4, you know that > something has gone wrong somewhere, your labeled packets are going > someplace other than where they are supposed to go, and you'd better do > something right away. > > The suggestion to randomly choose IP destination addresses from the 127/8 > block is, presumably, the way to ensure that the various paths created by > equal cost load splitting get exercised. The question is, how many pings do > you need to send in order to get good coverage? Obviously this depends on the number of ECMPs that exist. Which is both a function of the topology and the number of hops between the source and destination. If you have better suggestions on how to do this I'm quite eager to hear them. This is the best we've been able to come up with so far. > If the request has a stack of n FECs, and the responder is the egress for > the topmost m FECs but not for the bottommost n-m, it might be useful to > have a way to indicate that in the response. Or presumably you would just ping the outer FECs - which seems to me to be sufficient. > Some minor observations: > > - The notion of "time of day" is not well-defined. I have no idea what is > supposed to be put in the time of day fields. This doesn't really seem > that useful anyway unless there is synchronized time. Kireeti - could you comment here and also on Sharam's question on why you deviated from ICMP Ping? > - I'm not sure that the sequence number really needs to be a separate field > from the sender's handle. It just seems like an extension of the handle, > whose semantics are private to the sender. Some implementors would like to put a PID in the sender handle so the separation seems useful. ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu Dec 5 19:26:36 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 TAA06305 for ; Thu, 5 Dec 2002 19:26:35 -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 QQnrzl12333 for ; Fri, 6 Dec 2002 00:29: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 QQnrzl03364; Fri, 6 Dec 2002 00:25:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrzl17819 for mpls-outgoing; Fri, 6 Dec 2002 00:24: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 QQnrzl17814 for ; Fri, 6 Dec 2002 00:24: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 QQnrzl20922 for ; Fri, 6 Dec 2002 00:23:49 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 QQnrzl01773 for ; Fri, 6 Dec 2002 00:23:48 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 QQnrzl01758 for ; Fri, 6 Dec 2002 00:23:48 GMT Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Fri, 6 Dec 2002 00:23:59 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A35389014CFCA8@i2km07-ukbr.domain1.systemhost.net> To: swallow@cisco.com, mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Fri, 6 Dec 2002 00:23:41 -0000 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 Comments on section 4 and 5: 14 Section 4.1.....I don't understand why there is no explanation given as to why the source of an echo request contains an IP pkt with a 127/8 destination address, chosen apparently at random. I assume it must be for attempting to exercise any ECMP load-balancing paths. If so, why does the draft not make this explicitly clear instead of expecting the reader to guess? I am not an expert on these addresses, but my understanding of them is that are internal loopback addresses that are only supposed to stay within end-systems and not venture out into networks. So is this allowable....it looks potentially not-allowable to me? On assumption we can do this (and I'd like to see this confirmed or otherwise) it hardly gives any deterministic behaviour....esp if the odd pkt gets lost (either direction).....do you then re-send under same conditions or what (indeed can you replicate them)? Would the intention be to sample 1 of 16 million addresses and ping-away hoping for the best? I also guess its really only applicable to the ping-mode and not the trace-mode....or is it? If trace mode allowed here then behaviour seems highly unpredictable and not easily repeatable, ie as TTL does step-increase destination IP address is random at each step. BTW - this seems to be straying now far, far away from any notion of (deterministic) defect detection and well into the realms of 'guessing diagnostics'. In summary...a far better explanation of what is going here is definitely required IMO. 15 In the same section......I note that the same sequence number can be repeated. When taken into consideration with the above comments I am really struggling to get a feel for what kind of (help to) determinacy this is going to produce. 16 In section 4.2....it talks about " ....and the Subcode set to the appropriate value". But back in section 3 it says "The return Subcode is unused at present and should be set to zero" Please clarify. BTW - also talks about filling in the subcode in section 4.3, but no guidance given...despite what it says (that it is in the previous section). 17 In section 4.3...it says "An MPLS echo reply is a UDP pkt". How does this stack with a request wanting an RSVP response? 18 In section 5...it effectively talks about the critical need for a reliable return path. Well yes, as described this is obvious. But the fact of the matter is that the basic defect detection/handling problem is architecturally a uni-directional issue. There are simply things that have to be done here on a unidirectional basis, ie consequent actions require attention at a trail sink point, not its source point. Trying to force this 'bi-directional behaviour' is IMO not very sensible and leads to complexities. Just an observation. Timed out on this draft.....so far. regards, Neil From owner-mpls@UU.NET Fri Dec 6 10:04:03 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 KAA09122 for ; Fri, 6 Dec 2002 10:04:02 -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 QQnsbs06240 for ; Fri, 6 Dec 2002 15:06: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 QQnsbs04426; Fri, 6 Dec 2002 15:05:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsbs27867 for mpls-outgoing; Fri, 6 Dec 2002 15:05: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 QQnsbs27852 for ; Fri, 6 Dec 2002 15:05: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 QQnsbs07210 for ; Fri, 6 Dec 2002 15:04: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 QQnsbs03353 for ; Fri, 6 Dec 2002 15:04:16 GMT Received: from ihemail2.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQnsbs03340 for ; Fri, 6 Dec 2002 15:04:15 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 gB6F4Ec23642 for ; Fri, 6 Dec 2002 10:04:14 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Dec 2002 16:04:13 +0100 Message-ID: From: "Wijnen, Bert (Bert)" To: "Mpls (E-mail)" Subject: review of draft-ietf-mpls-lsr-mib-09.txt Date: Fri, 6 Dec 2002 16:04:12 +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 Oh well... Several of my earlier comments have not been addressed at all. Several others have been addressed (thanks). I had quickly skimmed through the new rev before the Atlanta MIB meeting, assuming all my concerns were addressed. These earlier comments (1H2002) were sent to authors only... Here we go. Mix of nits and serious stuff - I am missing IPR section - abstract says: community. In particular, it describes managed objects for modeling a Multiprotocol Label Switching (MPLS) Label Switching Router (LSR). Not sure it is so much "objects for modeling" as it is "objects to configure and/or monitor" - sect 9 talks about MIB II. I think you better just talk about RFC2863 (IF-MIB). - sect 10 says: RowPointer is a textual convention used to identify a conceptual row in an SNMP Table by pointing to one of its objects. In this REPEAT for the umptieth time: it is not just pointing to "one of its objects", but to "the first accessible object in a row". Again see RFC2579 for that - sect 10 last sentence has an empty [] at the end? - I wonder why mplsInterfaceConfTable and ...ConfEntry and ...ConfIndex have the "Conf" in there. NONE of the accessible objects in the table havae that prefxi "Conf" in them. Besides, the "Conf" to me suggests that you can use the table to configure something, but it is a read-only table, so it only lists details about existing mplsInterfaces. mplsInterfaceTable and mplsInterfaceEntry seem better names to me You may also want to say something about the table being read-only in the atble DESCRIPTION clause - mplsInterfaceConfEntry s/iff/if/ It talks about what a index of zero means. That is OK... bit really that info should be in the DESCRIPTION clause of the index object itself. If nothing else, then repeat the meaning of zero in the index object. - mplsInterfaceConfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is a unique index for an entry in the MplsInterfaceConfTable. A non-zero index for an entry indicates the ifIndex for the corresponding interface entry in of the MPLS-layer in the ifTable. ==> is the above a proper English sentence? - probably want to add a UNITS clause to mplsInterfaceTotalBandwith and ...AvailableBandwidth - mplsInterfaceLabelParticipationType OBJECT-TYPE SYNTAX BITS { perPlatform (0), perInterface (1) } MAX-ACCESS read-only STATUS current DESCRIPTION "Either the perPlatform(0) or perInterface(1) bit MUST be set. Note however that an interface could participate in both label spaces in which case both bits would be set. If the value of the mplsInterfaceConfIndex for this entry is zero, then only the perPlatform(0) bit MUST be set and the perInterface(1) bit is meaningless. If the perInterface(1) bit is set then the value of mplsInterfaceLabelMinIn, mplsInterfaceLabelMaxIn, mplsInterfaceLabelMinOut, and mplsInterfaceLabelMaxOut for this entry reflect the label ranges for this interface. If only the perPlatform(0) bit is set, then the value of mplsInterfaceLabelMinIn, mplsInterfaceLabelMaxIn, mplsInterfaceLabelMinOut, and mplsInterfaceLabelMaxOut for this entry must be identical to the instance of these objects with index 0." I think you mean well... but the 1st and 2nd sentence seem to contradict each other. Also the last "must" probably is better a "MUST". The text is also not easy to read... what do you think about" DESCRIPTION "Specifies if the interface uses labels from the interface label-space and/or the per-platform label-space. If the value of the mplsInterfaceConfIndex for this entry is zero, then only the perPlatform(0) bit MUST be set and the perInterface(1) bit is meaningless. If the perInterface(1) bit is set then the value of mplsInterfaceLabelMinIn, mplsInterfaceLabelMaxIn, mplsInterfaceLabelMinOut, and mplsInterfaceLabelMaxOut for this entry reflect the label ranges for this interface. If only the perPlatform(0) bit is set, then the value of mplsInterfaceLabelMinIn, mplsInterfaceLabelMaxIn, mplsInterfaceLabelMinOut, and mplsInterfaceLabelMaxOut for this entry MUST be identical to the instance of these objects with index 0." What is still not clear from the above: - assume per-platform has label range MinIn/MaxIn 50-100 - assume interface itself has label range MinIn/MaxIn 60-90 - assume both bits are set to 1. What happens? does it have to allocate/use labels in range 60-90 first and only when that range is exhausted in ranges 50-59 and 91-100 ?? - mplsInterfaceInLabelsUsed Gauge32, mplsInterfaceLabelLookupFailures Counter32, mplsInterfaceOutLabelsUsed Gauge32, mplsInterfaceOutFragments Counter32 I (still) believe that ....LabelsUsed is an incorrect name. It should be ...LabelsInUse (at this point in time, as the DESCRIPTION clause explains). I also still think that ..OutFragments is probably better called ....OutFragmentedPackets (as per description clause) Why do you not let all these names start with mplsInterfacePerfXxxx so that it is VERY CLEAR that these objects are located in this specific table? - mplsInSegmentEntry OBJECT-TYPE INDEX { mplsInSegmentIfIndex, mplsInSegmentLabel } Question: does there have to be one or more entries for every entry in the mplsInterfaceConfTable? If so, the first index probably should be mplsInterfaceConfIndex In any event, in my previous comment I had mentioned that ...IfIndex in the name of the index object is confusing, cause IfIndex is an object in the ifTable. I had suggested to use ...Interface or ...LabelSpace or such - mplsInSegmentAddrFamily OBJECT-TYPE SYNTAX AddressFamilyNumbers In my previosu comments I had asked what this is used for? I either have missed the answer or forgot. - As per earlier comment: mplsTrafficParamEntry "resource sharing" ???? see also my earlier comment on this: d. In sect 4, you state that the MIB allows resource sharing between multiple LSPs. Not sure, but I think you mean that various Tables can have entries that are shared by multiple entries in Other tables. So it is sharing "memory resources" when implementing the MIB I think. Such is not clear. It could be interpreted to mean that LSPs share other physical resources (which migth be possible too, but I am not sure that the MIB has anything to do with that or if so, pls explain). There is more of this "resource sharing" talk throughout the MIB. You may want to check that and make sure it is clear what you mean. - mplsInSegmentRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This variable is used to create, modify, and/or delete a row in this table." As per RFC2579, you must specify which columns can be changed if row is active. Seems the simple sentence to add is: "When this row is in active(a) state, no objects in this row can be changed." This is true for all your RowStatus objects in this MIB module - mplsInSegmentStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This variable indicates the storage type for this object. This object cannot be modified if mplsInSegmentRowStatus is active(1). If this variable is set to readOnly(5), and the corresponding LFIB entry is removed, then the agent must remove this row shortly thereafter [RFC2579]." As explained earlier, you MUST add text as to what objects (if any) MUST be writable for a 'permanent' row. See RFC2579. This is true for all you StorageType objetcs in this MIB module. Also... it might be good/wise to add a DEFAULT. In many MIB modules we have used volatile as the DEFATULT value. - MplsInSegmentPerfEntry ::= SEQUENCE { mplsInSegmentOctets Counter32, mplsInSegmentPackets Counter32, mplsInSegmentErrors Counter32, mplsInSegmentDiscards Counter32, -- high capacity counter mplsInSegmentHCOctets Counter64, mplsInSegmentPerfDiscontinuityTime TimeStamp Why do you not add "Perf" in the name of all these objects so that the names start with mplsInSegmentPerfXxxx and so that it is VERY clear in which table they are located? Since it is a short/small table, I guess it is easy to see from the DiscontinuityTime object that that is the discontinuity timer. RFC2578 says that each Counterxx object must include the text that explains whihc timer is to be used for discontinuity. So consider this a details-nit - mplsXxxxIndexNext We have talked about this a number of times. It still bothers me that you state that on every retrieval operation the agent MUST change the value. This sort of ENSURES that index values are non-contiguous. I guess that what you describe works.. but far from ideal. I really believe that you guys should look at the IndexInteger and IndexIntegerNextFree TCs in RFC3289, page 38. I think doing it that way is MUCH MUCH (yeas really MUCH) better. In fact, you could just use those TCs... although it makes you dependent on that MIB module. It is already at PS, so... - mplsOutSegmentIndex OBJECT-TYPE SYNTAX Unsigned32(0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This value contains a unique index for this row. While a value of 0 is not valid as an index for this row it can be supplied as a valid value to index mplsXCTable to access entries for which no out- segment has been configured." ::= { mplsOutSegmentEntry 1 } I think that this states that this object SHOULD have a range of (1..2147483647) and so EXCLUDE value zero. And you should NOT be using this object as index in the XCtable. The XCtable does NOT augnment or extend this table! In fact, your current XCtable has defined new objects for indexing, so you can safely start the range at 1. I think we discussed this several times before. - mplsOutSegmentNextHopIpAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates that the next hop address type is IPv4 when set to ipv4 (1) or IPv6 when set to ipv6 (2). A value of unknown (0) is allowed only when the outgoing interface is of type point-to-point. If any other values are attempted in a set operation the agent MUST return an inconsistentValue error. This object cannot be modified if mplsOutSegmentRowStatus is active(1)." I think a MUCH better way to do this is: DESCRIPTION "Indicates that the next hop Internet address type. Only values unknown (0), ipv4 (1) and ipv6 (2) have to be supported. A value of unknown (0) is allowed only when the outgoing interface is of type point-to-point. If any other values are attempted in a set operation the agent MUST return an inconsistentValue error. This object cannot be modified if mplsOutSegmentRowStatus is active(1)." - mplsOutSegmentNextHopIpAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The IPv4 or IPv6 address of the next hop. Its value is significant only when mplsOutSegmentNextHopIpAddrType is ipv4 (1) or ipv6 (2). Otherwise a management entity SHOULD set this to 0 and an agent MUST ignore it. Likewise an agent MUST return a value of 0 for a retrieval operation. This object cannot be modified if mplsOutSegmentRowStatus is active(1)." You cannot tell an agent what to return for retrieval... It MUST always return whatever the value happens to be!! I think a MUCH better way to do this is (and in sync with RFC3291): DESCRIPTION "The Internet address of the next hop. The type of this address is determined by the value of the mplsOutSegmentNextHopIpAddrType object. This object cannot be modified if mplsOutSegmentRowStatus is active(1)." - mplsOutSegmentXCIndex s/is MUST/MUST/ - mplsOutSegmentRowStatus and ... Storagetype. See my comments about RowStatus and Storagetype above - mplsXCEntry talks about mplsXCOutSegmentIndex being able to have avlue of zero but mplsXCOutSegmentIndex object itself has a range that excludes zero So which one of the two is incorrect? - as discussed before: mplsXCIsPersistent and mplsXCStorageType seem to be conflicting and/or overlapping objects. What is the story here? - mplsXCRowStatus and STorageType see my earlier comments on these two object types above - mplsXCAdminStatus does it not make sense to add a DEFAVL ?? - mplsLabelStackRowStatus and StorageType see my earlier comments on these two object types above - mplsTrafficParamRowStatus and StorageType see my earlier comments on these two object types above - mplsNotificationsEnable. Add at least a ptr to RFC2573 that explains that notifications are under control of the MIB modules in that document In other words, if you enable in the MPLS MIB module, these notifications may still not be emitted based on settings in the MIB modules in RFC2573. - mplsXCdown s/be the identical/be identical/ - mplsXCUp and mplsXCDown So will the OperStatus be the value 'up' and 'down' respectively? Or will it be the value that it had before going into the Up or Down state. The latter might pass more info. But in any event, it is best to be explicit as to what an agent is supposed to send and what a manager can expect to receive. - The "too quickly" in you xxxHCxxx DESCRIPTION clauses are not very specific. I would rather be explicit what that means. Aka as is done in IF-MIB. - But in general, one might wonder why you do not just do 64bit counters and require them on all devices. these LSR boxes will certainly have the power to do so. - I wonder if it is not better to have a mplsLsrReadOnlyCompliance and a mplsLsrFullCompliance as is also done in RFC3289 (as one of the better examples). Specifically, something like: OBJECT mplsOutSegmentRowStatus SYNTAX INTEGER { active(1), notInService(2), createAndGo(4), destroy(6) } MIN-ACCESS read-only DESCRIPTION "The notReady(3) and createAndWait(5) states need not be supported." is confusing. You do NOT use INTEGER by the way, but RowStatus. (SMICng will complain, but that is OK). If you split in two COMPLIANCEs. then for read-only you would have OBJECT mplsOutSegmentRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "write access need not be supported." for Full compliance you would have OBJECT mplsOutSegmentRowStatus SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." - I do not understand why you need two groups: mplsXcIsPersistentGroup and mplsXCIsNotPersistentGroup that both have only one and the same object in it? - on page 43 I see: -- mplsInSegmentTable OBJECT mplsInSegmentXCIndex DESCRIPTION "Write access is not required." Well, I would then expect: OBJECT mplsInSegmentXCIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." But the object already is MAX-ACCESS read-only. So no need to list this object here - I find OBJECT mplsInSegmentStorageType SYNTAX INTEGER { other(1) } DESCRIPTION "Only other(1) needs to be supported." REALLY REALLY strange. Other is defined as none of the values that have a well defined meaning. So you have no idea what this means. Why is this? - OBJECT mplsOutSegmentNextHopIpAddrType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } MIN-ACCESS read-only DESCRIPTION "An implementation is only required to support ipv4(1) and ipv6(2)." The DESCRIPTION conflicts with the SYNTAX clause, does it not? Same for OBJECT mplsOutSegmentNextHopIpAddr - mplsHCInSegmentPerfGroup OBJECT-GROUP OBJECTS { mplsInSegmentHCOctets } STATUS current DESCRIPTION "Object(s) providing performance information specific to out-segments for which the object mplsInterfaceInOctets wraps around too quickly." I guess: s/out-segments/in-segments/ - Why is the mplsSegemntDiscontinuityGroup a separate group? If you have any counters that use this as a discontinutiy timer, the they MUST also support this group, so I would say that these object should be part of the mplsPerfGroup. I guess this was caused by the splitting of HC counters. Another argument to just do away with the 32-bit counter for octets and just use 64 bit counters. This is 2002 (close to 2003), and not 1989 anymore. - References need to be split in normative and informative For you current SNMP references, the split is: > > > > Normative Informative > > ---------- ------------ > > 1905 1155 > > 1906 1157 > > 1212 > > 1215 > > 2571 1901 > > 2572 2570 > > 2573 > > 2574 > > 2575 > > 2578 > > 2579 > > 2580 > > Oh well... a lot of these things should not show up this late in the process... or so I feel. Bert From owner-mpls@UU.NET Fri Dec 6 10:32: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 KAA10353 for ; Fri, 6 Dec 2002 10:32:21 -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 QQnsbu13533 for ; Fri, 6 Dec 2002 15:35: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 QQnsbu11095; Fri, 6 Dec 2002 15:33:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsbu01013 for mpls-outgoing; Fri, 6 Dec 2002 15:33: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 QQnsbu01003 for ; Fri, 6 Dec 2002 15:33:16 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 QQnsbu01068 for ; Fri, 6 Dec 2002 15:33: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 QQnsbu24934 for ; Fri, 6 Dec 2002 15:33: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 QQnsbu24922 for ; Fri, 6 Dec 2002 15:33:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6FXY2g016209 for ; Fri, 6 Dec 2002 10:33:35 -0500 (EST) 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 KAA01149 for ; Fri, 6 Dec 2002 10:33:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB6FX5909618 for mpls@uu.net; Fri, 6 Dec 2002 10:33:05 -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 QQnsbu00922 for ; Fri, 6 Dec 2002 15:31:55 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 QQnsbu24380 for ; Fri, 6 Dec 2002 15:31:48 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 QQnsbu10056 for ; Fri, 6 Dec 2002 15:31:47 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 QQnsbu10044 for ; Fri, 6 Dec 2002 15:31:47 GMT Received: (qmail 10906 invoked by uid 104); 6 Dec 2002 15:31:41 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4236. . Clean. Processed in 1.004192 secs); 06 Dec 2002 15:31:41 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 6 Dec 2002 15:31:40 -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 gB6FVdQ00504; Fri, 6 Dec 2002 07:31:39 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Fri, 6 Dec 2002 07:31:39 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B4D@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'George Swallow'" , erosen@cisco.com Cc: mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Fri, 6 Dec 2002 07:31:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > > - The originator of the echo request decides to test a > FEC or a stack of > > FECs. > > I think you're really only testing one FEC. The stack gives you a way > of noting how you set off the get to that FEC (assuming you had > multiple options - like two TE tunnels). How you set off to get to that FEC is by pushing correct labels not by testing multiple FECs belonging to multiple LSP levels using the same packet. My suggestion is to remove the notion of FEC stack and make it a single FEC. > > > - The originator determines the next hop for that FEC, or > for the topmost > > FEC in the stack. > > > > - The originator labels the echo request with the label > stack that is used > > for sending packets with that FEC via that next hop. > > > > - The originator sends the labeled echo request to > that next hop. (If > > reaching the next hop requires going through an LSP > tunnel, this might > > causes more labels to be pushed on the stack.) > > Yes. I think we need to rework that section and be more explicit > about how it works. As far as I'm concerned the only place you might > have an unlabelled Ping is after a PHP. I was also assuming that you > only Ping one FEC at a time. I think we should also say that in the > text. If others think we need to be able to do more than one at a > time then we need a good deal of text to describe that. I think you need to be able to test more than one FEC belonging to the same LSP (not different LSPs at different levels). > > > > The suggestion to randomly choose IP destination > addresses from the 127/8 > > block is, presumably, the way to ensure that the various > paths created by > > equal cost load splitting get exercised. The question is, > how many pings do > > you need to send in order to get good coverage? > > Obviously this depends on the number of ECMPs that exist. Which is > both a function of the topology and the number of hops between the > source and destination. If you have better suggestions on how to do > this I'm quite eager to hear them. This is the best we've been able > to come up with so far. This has nothing to do with the number of ECMPs. In order to exercise all the ECMP paths (even off a single LSR), you need to produce IP addresses that hash to all those paths. But since the ECMP hash is proprietary, I have no idea how you could select the 127/8 addresses to cover all those ECMP paths. > > > If the request has a stack of n FECs, and the responder > is the egress for > > the topmost m FECs but not for the bottommost n-m, it > might be useful to > > have a way to indicate that in the response. > > Or presumably you would just ping the outer FECs - which seems to me > to be sufficient. My suggestion is to change the FEC stack to single FEC. > > > Some minor observations: > > > > - The notion of "time of day" is not well-defined. I have > no idea what is > > supposed to be put in the time of day fields. This > doesn't really seem > > that useful anyway unless there is synchronized time. > > Kireeti - could you comment here and also on Sharam's question on why > you deviated from ICMP Ping? > > > - I'm not sure that the sequence number really needs to be > a separate field > > from the sender's handle. It just seems like an > extension of the handle, > > whose semantics are private to the sender. > > Some implementors would like to put a PID in the sender handle so the > separation seems useful. PID for what? Are you thinking of encapsulating other packets/protocols in the LSP-ping packet? or is it going to verify what type of traffic the LSP is carrying? If the latter, then where is the error code for it? -Shahram From owner-mpls@UU.NET Fri Dec 6 10:39: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 KAA10903 for ; Fri, 6 Dec 2002 10:39:29 -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 QQnsbu07944 for ; Fri, 6 Dec 2002 15:42: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 QQnsbu04380; Fri, 6 Dec 2002 15:40:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsbu01959 for mpls-outgoing; Fri, 6 Dec 2002 15:40:16 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 QQnsbu01945 for ; Fri, 6 Dec 2002 15:40: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 QQnsbu13521 for ; Fri, 6 Dec 2002 15:39:34 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 QQnsbu02728 for ; Fri, 6 Dec 2002 15:39:33 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQnsbu02711 for ; Fri, 6 Dec 2002 15:39:33 GMT Received: from cisco.com (erosen-u10.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6FdUK0014951; Fri, 6 Dec 2002 07:39:30 -0800 (PST) Message-Id: <200212061539.gB6FdUK0014951@sj-msg-core-1.cisco.com> To: George Swallow cc: mpls@UU.NET Subject: Re: Last call on LSP Ping In-reply-to: Your message of Thu, 05 Dec 2002 19:01:02 -0500. <200212060001.TAA24892@bifocal.cisco.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Fri, 06 Dec 2002 10:39:30 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk George> I think you're really only testing one FEC. I don't think so. The Echo Request might end up getting processed at a node which is an egress for the top FEC, but not for one of the succeeding FECs. This would indicate that you don't have proper connectivity for the latter, even if you do have proper connectivity for the former. From owner-mpls@UU.NET Fri Dec 6 10:53: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 KAA11392 for ; Fri, 6 Dec 2002 10:53: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 QQnsbv08547 for ; Fri, 6 Dec 2002 15:56: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 QQnsbv04235; Fri, 6 Dec 2002 15:54:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsbv03332 for mpls-outgoing; Fri, 6 Dec 2002 15:53: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 QQnsbv03327 for ; Fri, 6 Dec 2002 15:53:36 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 QQnsbv27361 for ; Fri, 6 Dec 2002 15:53: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 QQnsbv18377 for ; Fri, 6 Dec 2002 15:53:10 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQnsbv18367 for ; Fri, 6 Dec 2002 15:53:09 GMT Received: from cisco.com (erosen-u10.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6Fr5K0020063; Fri, 6 Dec 2002 07:53:05 -0800 (PST) Message-Id: <200212061553.gB6Fr5K0020063@sj-msg-core-1.cisco.com> To: neil.2.harrison@bt.com cc: swallow@cisco.com, mpls@UU.NET Subject: Re: Last call on LSP Ping In-reply-to: Your message of Thu, 05 Dec 2002 15:34:45 +0000. <0536FC9B908BEC4597EE721BE6A35389014CFC9E@i2km07-ukbr.domain1.systemhost.net> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Fri, 06 Dec 2002 10:53:04 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Neil> Ping test will detect simple breaks (either direction....this then Neil> needs the direction resolving of course). Ping won't detect Neil> misrouting/mismerging. This statement does not appear to me to be correct. In the event of misrouting, the Echo Request packet will be processed by an LSP egress which isn't the proper egress for the indicated FEC. This results in an error code 4 response indicating that misrouting has occurred. It doesn't tell you where the fault lies, but it does tell you that a fault exists. From owner-mpls@UU.NET Fri Dec 6 11:22:49 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 LAA12506 for ; Fri, 6 Dec 2002 11:22:49 -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 QQnsbx14140 for ; Fri, 6 Dec 2002 16:25: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 QQnsbx09976; Fri, 6 Dec 2002 16:22:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsbx24200 for mpls-outgoing; Fri, 6 Dec 2002 16:22: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 QQnsbx24193 for ; Fri, 6 Dec 2002 16:22:28 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 QQnsbx14926 for ; Fri, 6 Dec 2002 16:21: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 QQnsbx00510 for ; Fri, 6 Dec 2002 16:21:06 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 QQnsbx00506 for ; Fri, 6 Dec 2002 16:21:05 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6GLX3i023466 for ; Fri, 6 Dec 2002 11:21:33 -0500 (EST) 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 LAA05203 for ; Fri, 6 Dec 2002 11:21:04 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB6GL4M15546 for mpls@uu.net; Fri, 6 Dec 2002 11:21:04 -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 QQnsbx23697 for ; Fri, 6 Dec 2002 16:19:30 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 QQnsbx20252 for ; Fri, 6 Dec 2002 16:18: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 QQnsbx28933 for ; Fri, 6 Dec 2002 16:18:28 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 QQnsbx28912 for ; Fri, 6 Dec 2002 16:18:27 GMT Received: (qmail 17251 invoked by uid 104); 6 Dec 2002 16:18:27 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4236. . Clean. Processed in 0.479787 secs); 06 Dec 2002 16:18:27 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 6 Dec 2002 16:18:26 -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 gB6GIMQ27523; Fri, 6 Dec 2002 08:18:22 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Fri, 6 Dec 2002 08:18:22 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B4E@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'erosen@cisco.com'" , neil.2.harrison@bt.com Cc: swallow@cisco.com, mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Fri, 6 Dec 2002 08:18:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > Neil> Ping test will detect simple breaks (either > direction....this then > Neil> needs the direction resolving of course). Ping > won't detect > Neil> misrouting/mismerging. > > This statement does not appear to me to be correct. In > the event of > misrouting, the Echo Request packet will be processed by an > LSP egress which > isn't the proper egress for the indicated FEC. This > results in an error > code 4 response indicating that misrouting has occurred. > It doesn't tell > you where the fault lies, but it does tell you that a fault exists. What if the Echo Request packet is misrouted to an egress that happens to have that FEC in its routing table, but is not the intended egress? -Shahram From owner-mpls@UU.NET Fri Dec 6 11:34: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 LAA12933 for ; Fri, 6 Dec 2002 11:34:36 -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 QQnsby28929 for ; Fri, 6 Dec 2002 16:37: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 QQnsby25332; Fri, 6 Dec 2002 16:35:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsby25303 for mpls-outgoing; Fri, 6 Dec 2002 16:34:56 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 QQnsby25285 for ; Fri, 6 Dec 2002 16:34:46 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 QQnsby05040 for ; Fri, 6 Dec 2002 16:32:10 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 QQnsby15055 for ; Fri, 6 Dec 2002 16:32:10 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 QQnsby15039 for ; Fri, 6 Dec 2002 16:32:09 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6GWXHY025586 for ; Fri, 6 Dec 2002 11:32:33 -0500 (EST) 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 LAA06250 for ; Fri, 6 Dec 2002 11:32:03 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB6GW3j18177 for mpls@uu.net; Fri, 6 Dec 2002 11:32: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 QQnsbx24864 for ; Fri, 6 Dec 2002 16:29:24 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 QQnsbx15942 for ; Fri, 6 Dec 2002 16:27: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 QQnsbx09449 for ; Fri, 6 Dec 2002 16:27:31 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 QQnsbx09425 for ; Fri, 6 Dec 2002 16:27:30 GMT Received: (qmail 2238 invoked by uid 104); 6 Dec 2002 16:27:30 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4236. . Clean. Processed in 0.476838 secs); 06 Dec 2002 16:27:30 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 6 Dec 2002 16:27:29 -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 gB6GRTQ02789; Fri, 6 Dec 2002 08:27:29 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Fri, 6 Dec 2002 08:27:28 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B4F@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: Shahram Davari , "'erosen@cisco.com'" , neil.2.harrison@bt.com Cc: swallow@cisco.com, mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Fri, 6 Dec 2002 08:27:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Never mind, I figured it out. > What if the Echo Request packet is misrouted to an egress > that happens to have that FEC in its routing table, but is > not the intended egress? > > -Shahram > From owner-mpls@UU.NET Fri Dec 6 11:44:42 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 LAA13364 for ; Fri, 6 Dec 2002 11:44:41 -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 QQnsbz00899 for ; Fri, 6 Dec 2002 16:47: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 QQnsby26053; Fri, 6 Dec 2002 16:44:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsby26489 for mpls-outgoing; Fri, 6 Dec 2002 16:44: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 QQnsby26456 for ; Fri, 6 Dec 2002 16:44:00 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 QQnsby24591 for ; Fri, 6 Dec 2002 16:41:33 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 QQnsby05556 for ; Fri, 6 Dec 2002 16:41:33 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 QQnsby05546 for ; Fri, 6 Dec 2002 16:41:32 GMT Received: from BLIULAPTOP ([172.16.24.104]) by atlntex01.movaz.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 6 Dec 2002 11:41:32 -0500 Message-ID: <01bf01c29d46$55618080$681810ac@movaz.com> From: "Adrian Farrel" To: "Wijnen, Bert \(Bert\)" , "Mpls \(E-mail\)" References: Subject: Re: review of draft-ietf-mpls-lsr-mib-09.txt Date: Fri, 6 Dec 2002 11:40:17 -0500 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: 06 Dec 2002 16:41:32.0672 (UTC) FILETIME=[5573D000:01C29D46] Sender: owner-mpls@UU.NET Precedence: bulk Bert, I haven't been party to the discussions with the MPLS MIB authors on this point, but I will jump in because the GMPLS MIBs do/might use this construct. > - mplsXxxxIndexNext > We have talked about this a number of times. It still bothers me that > you state that on every retrieval operation the agent MUST change the > value. This sort of ENSURES that index values are non-contiguous. > I guess that what you describe works.. but far from ideal. It is certainly not intentional that the index values are non-contiguous. In fact, it is intended that they ARE contiguous and also that they are uniquely reserved for users which is important when there are multiple users trying to create rows. > I really believe that you guys should look at the IndexInteger and > IndexIntegerNextFree TCs in RFC3289, page 38. I think doing it that way > is MUCH MUCH (yeas really MUCH) better. > In fact, you could just use those TCs... although it makes you dependent > on that MIB module. It is already at PS, so... This construct appears to be the same except that the one in the LSR MIB attempts to close the window where two applications are attempting to create rows at once. In RFC3289, both may read the object of type IndexIntegerNextFree and get the same value: the second create is doomed to fail. In the LSR MIB when the first application reads the xxxxIndexNext the value is incremented so that the next read (by the second application) will return a different value. It is true that the LSR MIB approach may lead to lacunas if an application decides not to create a row after all, but that is not necessarily a problem. I assume that this issue has been addressed in multiple MIB modules in the past and guess there isn't a standard way of solving it. FWIW the LSM MIB approach is used in the AToM MIBs. For example, atmVpCrossConnectIndexNext in RFC2515. A common approach across all MIB modules would certainly be welcome. Is there a MIB Doctor in the house? Adrian From owner-mpls@UU.NET Fri Dec 6 12:18: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 MAA14523 for ; Fri, 6 Dec 2002 12:18:57 -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 QQnscb08038 for ; Fri, 6 Dec 2002 17:21: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 QQnscb04038; Fri, 6 Dec 2002 17:19:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQnscb18186 for mpls-outgoing; Fri, 6 Dec 2002 17:19: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 QQnscb18181 for ; Fri, 6 Dec 2002 17:18:58 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 QQnscb19991 for ; Fri, 6 Dec 2002 17:17: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 QQnscb25184 for ; Fri, 6 Dec 2002 17:17:07 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 QQnscb25176 for ; Fri, 6 Dec 2002 17:17:06 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6HHYas002659 for ; Fri, 6 Dec 2002 12:17:34 -0500 (EST) 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 MAA10212 for ; Fri, 6 Dec 2002 12:17:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB6HH5S24664 for mpls@uu.net; Fri, 6 Dec 2002 12:17:05 -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 QQnscb17928 for ; Fri, 6 Dec 2002 17:16: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 QQnscb16085 for ; Fri, 6 Dec 2002 17:15: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 QQnscb00674 for ; Fri, 6 Dec 2002 17:15:20 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 QQnscb00655 for ; Fri, 6 Dec 2002 17:15:19 GMT Received: (qmail 23284 invoked by uid 104); 6 Dec 2002 17:15:18 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4236. . Clean. Processed in 0.494644 secs); 06 Dec 2002 17:15:18 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 6 Dec 2002 17:15:17 -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 gB6HFHQ01125; Fri, 6 Dec 2002 09:15:17 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Fri, 6 Dec 2002 09:15:17 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B53@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: swallow@cisco.com Cc: mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Fri, 6 Dec 2002 09:15:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk RFC 3330 says: 127.0.0.0/8 - This block is assigned for use as the Internet host loopback address. A datagram sent by a higher level protocol to an address anywhere within this block should loop back inside the host. This is ordinarily implemented using only 127.0.0.1/32 for loopback, but no addresses within this block should ever appear on any network anywhere [RFC1700, page 5]. And RFC1700 says: g) {127, } Internal host loopback address. Should never appear outside a host. Doesn't this draft violate these RFCs? -Shahram From owner-mpls@UU.NET Fri Dec 6 12:20: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 MAA14632 for ; Fri, 6 Dec 2002 12:20: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 QQnscb02419 for ; Fri, 6 Dec 2002 17: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 QQnscb27567; Fri, 6 Dec 2002 17:20:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQnscb18264 for mpls-outgoing; Fri, 6 Dec 2002 17:20: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 QQnscb18228 for ; Fri, 6 Dec 2002 17:20: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 QQnscb28673 for ; Fri, 6 Dec 2002 17:19:07 GMT From: neil.2.harrison@bt.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 QQnscb27762 for ; Fri, 6 Dec 2002 17:19:06 GMT Received: from cbibipnt08.hc.bt.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQnscb27740 for ; Fri, 6 Dec 2002 17:19:06 GMT Received: by cbibipnt08.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Fri, 6 Dec 2002 17:19:14 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A35389014CFCAE@i2km07-ukbr.domain1.systemhost.net> To: erosen@cisco.com Cc: mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Fri, 6 Dec 2002 17:18:58 -0000 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 Thanks Eric, please see below. regards, Neil > Neil> Ping test will detect simple breaks (either > direction....this then > Neil> needs the direction resolving of course). Ping > won't detect > Neil> misrouting/mismerging. > >Eric R=> This statement does not appear to me to be correct. In > the event of > misrouting, the Echo Request packet will be processed by an > LSP egress which > isn't the proper egress for the indicated FEC. This > results in an error > code 4 response indicating that misrouting has occurred. > It doesn't tell > you where the fault lies, but it does tell you that a fault exists. NH=> If IP only return forwarding is allowed *and* the node where this ends up is able to respond this seems true. However in case of core MPLS only network, then any return with 'router alert' set will have no choice but to use LSP return....so an IP return, which is being asked for, can't be done. Similarly in case of respond via RSVP, there will almost certainly be no return RSVP-LSP to return over (from where the pkt ends up). At least, that's how I read/understand it.....and perhaps someone could please clarify if I have got this wrong? From owner-mpls@UU.NET Fri Dec 6 12:52:33 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 MAA16203 for ; Fri, 6 Dec 2002 12:52:33 -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 QQnscd16163 for ; Fri, 6 Dec 2002 17:55:25 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 QQnscd06315; Fri, 6 Dec 2002 17:50:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQnscd20914 for mpls-outgoing; Fri, 6 Dec 2002 17:50: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 QQnscd20906 for ; Fri, 6 Dec 2002 17:50:20 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 QQnscd11470 for ; Fri, 6 Dec 2002 17:49:51 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 QQnscd05021 for ; Fri, 6 Dec 2002 17:49:51 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 QQnscd05017 for ; Fri, 6 Dec 2002 17:49:50 GMT Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Fri, 6 Dec 2002 17:50:03 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A35389014CFCB1@i2km07-ukbr.domain1.systemhost.net> To: swallow@cisco.com, Shahram_Davari@pmc-sierra.com Cc: mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Fri, 6 Dec 2002 17:49:37 -0000 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 George....I think the point Shahram was making it is not even allowed outside the host/source box according to the text quoted from the RFcs below. Wrapping it in some other package (any, not just MPLS) is still violating this requirement...and note that it *must* be placed in some package to get across any tranmission medium....IP pkts don't go raw on wires. regards, Neil > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: 06 December 2002 17:23 > To: Shahram Davari > Cc: swallow@cisco.com; mpls@UU.NET; swallow@cisco.com > Subject: Re: Last call on LSP Ping > > > > RFC 3330 says: > > > > > > 127.0.0.0/8 - This block is assigned for use as the Internet host > > loopback address. A datagram sent by a higher level > protocol to an > > address anywhere within this block should loop back > inside the host. > > This is ordinarily implemented using only 127.0.0.1/32 > for loopback, > > but no addresses within this block should ever appear on > any network > > anywhere [RFC1700, page 5]. > > > > And RFC1700 says: > > > > g) {127, } > > > > Internal host loopback address. Should never > appear outside > > a host. > > > > > > Doesn't this draft violate these RFCs? > > This it falls within the intent. If the label stack gets completely > poped off you don't want it to go any further. That's the whole point > of using that address range. I really don't see a need to find a new > range. > > (Note that I'm counting the implicit null as still being a label stack > - so the packet gets as far as the stack will take it and no further.) > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 497-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > From owner-mpls@UU.NET Fri Dec 6 13:03:08 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 NAA16834 for ; Fri, 6 Dec 2002 13:03:08 -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 QQnsce03454 for ; Fri, 6 Dec 2002 18:05: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 QQnsce00191; Fri, 6 Dec 2002 18:04:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsce08853 for mpls-outgoing; Fri, 6 Dec 2002 18:03: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 QQnsce08834 for ; Fri, 6 Dec 2002 18:03: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 QQnsce18098 for ; Fri, 6 Dec 2002 18:02: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 QQnsce28848 for ; Fri, 6 Dec 2002 18:02:12 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 QQnsce28768 for ; Fri, 6 Dec 2002 18:02:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6I2YlT008202 for ; Fri, 6 Dec 2002 13:02:35 -0500 (EST) 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 NAA13976 for ; Fri, 6 Dec 2002 13:02:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB6I25i00941 for mpls@uu.net; Fri, 6 Dec 2002 13:02:05 -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 QQnsce00875 for ; Fri, 6 Dec 2002 18:01:30 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 QQnsce12671 for ; Fri, 6 Dec 2002 18:00: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 QQnsce21285 for ; Fri, 6 Dec 2002 18:00:48 GMT Received: from father.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQnsce21271 for ; Fri, 6 Dec 2002 18:00:47 GMT Received: (qmail 4382 invoked by uid 104); 6 Dec 2002 18:00:46 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4236. . Clean. Processed in 0.557335 secs); 06 Dec 2002 18:00:46 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 6 Dec 2002 18:00:46 -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 gB6I0jQ29917; Fri, 6 Dec 2002 10:00:45 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Fri, 6 Dec 2002 10:00:45 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B55@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'George Swallow'" Cc: mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Fri, 6 Dec 2002 10:00:44 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk I understand the intent, but these RFCs explicitly prohibit sending 127/8 addresses out of any box. It is for a node's internal use only. -Shahram > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Friday, December 06, 2002 12:23 PM > To: Shahram Davari > Cc: swallow@cisco.com; mpls@UU.NET; swallow@cisco.com > Subject: Re: Last call on LSP Ping > > > > RFC 3330 says: > > > > > > 127.0.0.0/8 - This block is assigned for use as the Internet host > > loopback address. A datagram sent by a higher level > protocol to an > > address anywhere within this block should loop back > inside the host. > > This is ordinarily implemented using only 127.0.0.1/32 > for loopback, > > but no addresses within this block should ever appear on > any network > > anywhere [RFC1700, page 5]. > > > > And RFC1700 says: > > > > g) {127, } > > > > Internal host loopback address. Should never > appear outside > > a host. > > > > > > Doesn't this draft violate these RFCs? > > This it falls within the intent. If the label stack gets completely > poped off you don't want it to go any further. That's the whole point > of using that address range. I really don't see a need to find a new > range. > > (Note that I'm counting the implicit null as still being a label stack > - so the packet gets as far as the stack will take it and no further.) > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 497-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > From owner-mpls@UU.NET Fri Dec 6 13:27: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 NAA18026 for ; Fri, 6 Dec 2002 13:27:10 -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 QQnscg09040 for ; Fri, 6 Dec 2002 18:30: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 QQnscf28496; Fri, 6 Dec 2002 18:23:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQnscf12249 for mpls-outgoing; Fri, 6 Dec 2002 18:23:27 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 QQnscf12220 for ; Fri, 6 Dec 2002 18:23:21 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 QQnscf06480 for ; Fri, 6 Dec 2002 18:23: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 QQnscf28061 for ; Fri, 6 Dec 2002 18:23:06 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 QQnscf28049 for ; Fri, 6 Dec 2002 18:23:06 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6INYZp010857 for ; Fri, 6 Dec 2002 13:23:34 -0500 (EST) 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 NAA15846 for ; Fri, 6 Dec 2002 13:23:04 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB6IN4r04420 for mpls@uu.net; Fri, 6 Dec 2002 13:23: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 QQnscf12153 for ; Fri, 6 Dec 2002 18:21:46 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 QQnscf26969 for ; Fri, 6 Dec 2002 18:21:14 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 QQnscf12775 for ; Fri, 6 Dec 2002 18:21:13 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 QQnscf12768 for ; Fri, 6 Dec 2002 18:21:12 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 NAA21205; Fri, 6 Dec 2002 13:19:57 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212061819.NAA21205@workhorse.fictitious.org> To: Shahram Davari cc: swallow@cisco.com, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Fri, 06 Dec 2002 09:15:15 PST." <4B6D09F3B826D411A67300D0B706EFDEB03B53@nt-exch-yow.pmc-sierra.bc.ca> Date: Fri, 06 Dec 2002 13:19:57 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4B6D09F3B826D411A67300D0B706EFDEB03B53@nt-exch-yow.pmc-sierra.bc.ca >, Shahram Davari writes: > RFC 3330 says: > > > 127.0.0.0/8 - This block is assigned for use as the Internet host > loopback address. A datagram sent by a higher level protocol to an > address anywhere within this block should loop back inside the host. > This is ordinarily implemented using only 127.0.0.1/32 for loopback, > but no addresses within this block should ever appear on any network > anywhere [RFC1700, page 5]. > > And RFC1700 says: > > g) {127, } > > Internal host loopback address. Should never appear outside > a host. > > > Doesn't this draft violate these RFCs? > > -Shahram No. It is exactly what RFC1700 specifies. 127.0.0.1/32 is not routable, just avaiable locally. Curtis From owner-mpls@UU.NET Fri Dec 6 13:36: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 NAA18510 for ; Fri, 6 Dec 2002 13:36:12 -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 QQnscg20270 for ; Fri, 6 Dec 2002 18:38: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 QQnscg11850; Fri, 6 Dec 2002 18:33:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQnscg13297 for mpls-outgoing; Fri, 6 Dec 2002 18:33:25 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 QQnscg13290 for ; Fri, 6 Dec 2002 18:33:07 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 QQnscg22719 for ; Fri, 6 Dec 2002 18:31: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 QQnscg10294 for ; Fri, 6 Dec 2002 18:31:07 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 QQnscg10286 for ; Fri, 6 Dec 2002 18:31:06 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6IVY2R012009 for ; Fri, 6 Dec 2002 13:31:34 -0500 (EST) 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 NAA16443 for ; Fri, 6 Dec 2002 13:31:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB6IV5B06106 for mpls@uu.net; Fri, 6 Dec 2002 13:31:05 -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 QQnscf12882 for ; Fri, 6 Dec 2002 18:29: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 QQnscf28614 for ; Fri, 6 Dec 2002 18:28:51 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 QQnscf06966 for ; Fri, 6 Dec 2002 18:28:50 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 QQnscf06937 for ; Fri, 6 Dec 2002 18:28:48 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 NAA21232; Fri, 6 Dec 2002 13:27:32 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212061827.NAA21232@workhorse.fictitious.org> To: Shahram Davari cc: "'George Swallow'" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Fri, 06 Dec 2002 10:00:44 PST." <4B6D09F3B826D411A67300D0B706EFDEB03B55@nt-exch-yow.pmc-sierra.bc.ca> Date: Fri, 06 Dec 2002 13:27:32 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4B6D09F3B826D411A67300D0B706EFDEB03B55@nt-exch-yow.pmc-sierra.bc.ca >, Shahram Davari writes: > I understand the intent, but these RFCs explicitly prohibit sending > 127/8 addresses out of any box. It is for a node's internal use only. > > -Shahram This does not make it routeable. It is no more a violation than using a an IP source route with a 127.0.0.1 destination when you know that the destination used the standard numbering of the loopback. If any part of 127/8 became routable then it would be a violation of the intent. The LSP-ping objectors seem to be grasping at straws with this one. Curtis > > -----Original Message----- > > From: George Swallow [mailto:swallow@cisco.com] > > Sent: Friday, December 06, 2002 12:23 PM > > To: Shahram Davari > > Cc: swallow@cisco.com; mpls@UU.NET; swallow@cisco.com > > Subject: Re: Last call on LSP Ping > > > > > > > RFC 3330 says: > > > > > > > > > 127.0.0.0/8 - This block is assigned for use as the Internet host > > > loopback address. A datagram sent by a higher level > > protocol to an > > > address anywhere within this block should loop back > > inside the host. > > > This is ordinarily implemented using only 127.0.0.1/32 > > for loopback, > > > but no addresses within this block should ever appear on > > any network > > > anywhere [RFC1700, page 5]. > > > > > > And RFC1700 says: > > > > > > g) {127, } > > > > > > Internal host loopback address. Should never > > appear outside > > > a host. > > > > > > > > > Doesn't this draft violate these RFCs? > > > > This it falls within the intent. If the label stack gets completely > > poped off you don't want it to go any further. That's the whole point > > of using that address range. I really don't see a need to find a new > > range. > > > > (Note that I'm counting the implicit null as still being a label stack > > - so the packet gets as far as the stack will take it and no further.) > > > > ...George > > > > ================================================================== > > George Swallow Cisco Systems (978) 497-8143 > > 250 Apollo Drive > > Chelmsford, Ma 01824 > > > > From owner-mpls@UU.NET Fri Dec 6 13:42:43 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 NAA18815 for ; Fri, 6 Dec 2002 13:42:43 -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 QQnsch09445 for ; Fri, 6 Dec 2002 18:45:12 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 QQnscg29023; Fri, 6 Dec 2002 18:39:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQnscg13817 for mpls-outgoing; Fri, 6 Dec 2002 18:39:07 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 QQnscg13811 for ; Fri, 6 Dec 2002 18:38:53 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 QQnscg15565 for ; Fri, 6 Dec 2002 18:38: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 QQnscg18886 for ; Fri, 6 Dec 2002 18:37:59 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 QQnscg18867 for ; Fri, 6 Dec 2002 18:37:58 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6IcQJ4013029 for ; Fri, 6 Dec 2002 13:38:26 -0500 (EST) 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 NAA17108 for ; Fri, 6 Dec 2002 13:37:56 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB6IbuN07123 for mpls@uu.net; Fri, 6 Dec 2002 13:37:56 -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 QQnscg13333 for ; Fri, 6 Dec 2002 18:35:21 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 QQnscg02077 for ; Fri, 6 Dec 2002 18:34: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 QQnscg12159 for ; Fri, 6 Dec 2002 18:34:06 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 QQnscg12145 for ; Fri, 6 Dec 2002 18:34:05 GMT Received: (qmail 5047 invoked by uid 104); 6 Dec 2002 18:34:03 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4236. . Clean. Processed in 0.655987 secs); 06 Dec 2002 18:34:03 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 6 Dec 2002 18:34:03 -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 gB6IY2Q20450; Fri, 6 Dec 2002 10:34:02 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Fri, 6 Dec 2002 10:34:02 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B56@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'curtis@fictitious.org'" Cc: swallow@cisco.com, mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Fri, 6 Dec 2002 10:33:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > > > > 127.0.0.0/8 - This block is assigned for use as the Internet host > > loopback address. A datagram sent by a higher level > protocol to an > > address anywhere within this block should loop back > inside the host. > > This is ordinarily implemented using only 127.0.0.1/32 > for loopback, > > but no addresses within this block should ever appear on > any network > > anywhere [RFC1700, page 5]. > > > > And RFC1700 says: > > > > g) {127, } > > > > Internal host loopback address. Should never > appear outside > > a host. > > > > > > Doesn't this draft violate these RFCs? > > > > -Shahram > > > No. It is exactly what RFC1700 specifies. 127.0.0.1/32 is not > routable, just avaiable locally. > > Curtis Locally available to who? the ingress? I think it is clear that such an IP packet should never leave any box including the ingress. Here is what RFC 1122 says: A host MUST silently discard an incoming datagram that is not destined for the host. An incoming datagram is destined for the host if the datagram's destination address field is: (1) (one of) the host's IP address(es); or (2) an IP broadcast address valid for the connected network; or (3) the address for a multicast group of which the host is a member on the incoming physical interface. Therefore such a packet will get discarded at that node before even reaching the UDP/ping layer. -Shahram From owner-mpls@UU.NET Fri Dec 6 13:44: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 NAA18954 for ; Fri, 6 Dec 2002 13:44:54 -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 QQnsch05961 for ; Fri, 6 Dec 2002 18:47: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 QQnscg22446; Fri, 6 Dec 2002 18:40:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQnscg13853 for mpls-outgoing; Fri, 6 Dec 2002 18:39:27 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 QQnscg13836 for ; Fri, 6 Dec 2002 18:39: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 QQnscg19063 for ; Fri, 6 Dec 2002 18:39: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 QQnscg20960 for ; Fri, 6 Dec 2002 18:39:10 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 QQnscg20935 for ; Fri, 6 Dec 2002 18:39:09 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6Idbsu013208 for ; Fri, 6 Dec 2002 13:39:37 -0500 (EST) 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 NAA17190 for ; Fri, 6 Dec 2002 13:39:07 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB6Id7f07430 for mpls@uu.net; Fri, 6 Dec 2002 13:39:07 -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 QQnscg13635 for ; Fri, 6 Dec 2002 18:37:23 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 QQnscg16270 for ; Fri, 6 Dec 2002 18:35: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 QQnscg14599 for ; Fri, 6 Dec 2002 18:35:31 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 QQnscg14563 for ; Fri, 6 Dec 2002 18:35:30 GMT Received: (qmail 6030 invoked by uid 104); 6 Dec 2002 18:35:28 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4236. . Clean. Processed in 1.111498 secs); 06 Dec 2002 18:35:28 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 6 Dec 2002 18:35:27 -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 gB6IZQQ21145; Fri, 6 Dec 2002 10:35:26 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Fri, 6 Dec 2002 10:35:26 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B57@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'curtis@fictitious.org'" Cc: "'George Swallow'" , mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Fri, 6 Dec 2002 10:35:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > >, Shahram Davari writes: > > I understand the intent, but these RFCs explicitly prohibit sending > > 127/8 addresses out of any box. It is for a node's internal > use only. > > > > -Shahram > > > This does not make it routeable. It is no more a violation than using > a an IP source route with a 127.0.0.1 destination when you > know that the > destination used the standard numbering of the loopback. > > If any part of 127/8 became routable then it would be a violation of > the intent. > > The LSP-ping objectors seem to be grasping at straws with this one. > > Curtis Yes, but it makes it droppable even by correct egress. -Shahram From owner-mpls@UU.NET Fri Dec 6 13:53: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 NAA19337 for ; Fri, 6 Dec 2002 13:53:38 -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 QQnsch20194 for ; Fri, 6 Dec 2002 18:56: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 QQnsch17028; Fri, 6 Dec 2002 18:54:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsch16223 for mpls-outgoing; Fri, 6 Dec 2002 18:54:02 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 QQnsch16210 for ; Fri, 6 Dec 2002 18:53: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 QQnsch05834 for ; Fri, 6 Dec 2002 18:53: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 QQnsch10057 for ; Fri, 6 Dec 2002 18:52:59 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 QQnsch10048 for ; Fri, 6 Dec 2002 18:52:59 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6IrR39015056 for ; Fri, 6 Dec 2002 13:53:27 -0500 (EST) 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 NAA18308 for ; Fri, 6 Dec 2002 13:52:58 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB6IqwO15174 for mpls@uu.net; Fri, 6 Dec 2002 13:52:58 -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 QQnsch15544 for ; Fri, 6 Dec 2002 18:46: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 QQnsch22479 for ; Fri, 6 Dec 2002 18:46: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 QQnsch11547 for ; Fri, 6 Dec 2002 18:46:20 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 QQnsch11233 for ; Fri, 6 Dec 2002 18:46:13 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 NAA21509; Fri, 6 Dec 2002 13:44:52 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212061844.NAA21509@workhorse.fictitious.org> To: Shahram Davari cc: "'curtis@fictitious.org'" , swallow@cisco.com, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Fri, 06 Dec 2002 10:33:59 PST." <4B6D09F3B826D411A67300D0B706EFDEB03B56@nt-exch-yow.pmc-sierra.bc.ca> Date: Fri, 06 Dec 2002 13:44:52 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4B6D09F3B826D411A67300D0B706EFDEB03B56@nt-exch-yow.pmc-sierra.bc.ca >, Shahram Davari writes: > > > > > > > 127.0.0.0/8 - This block is assigned for use as the Internet host > > > loopback address. A datagram sent by a higher level > > protocol to an > > > address anywhere within this block should loop back > > inside the host. > > > This is ordinarily implemented using only 127.0.0.1/32 > > for loopback, > > > but no addresses within this block should ever appear on > > any network > > > anywhere [RFC1700, page 5]. > > > > > > And RFC1700 says: > > > > > > g) {127, } > > > > > > Internal host loopback address. Should never > > appear outside > > > a host. > > > > > > > > > Doesn't this draft violate these RFCs? > > > > > > -Shahram > > > > > > No. It is exactly what RFC1700 specifies. 127.0.0.1/32 is not > > routable, just avaiable locally. > > > > Curtis > > > Locally available to who? the ingress? I think it is clear that such an IP pa > cket should never leave any box including the ingress. Here is what RFC 1122 > says: > > A host MUST silently discard an incoming datagram that is > not destined for the host. An incoming datagram is destined > for the host if the datagram's destination address field is: > > (1) (one of) the host's IP address(es); or It is one of the hosts non-routable IP addresses configured on the loopback device. > (2) an IP broadcast address valid for the connected > network; or > > (3) the address for a multicast group of which the host is > a member on the incoming physical interface. > > > Therefore such a packet will get discarded at that node before even reaching > the UDP/ping layer. > > > -Shahram Try "ping -g 127.0.0.1" fron any host or router that supports source route ping to any host or router that doesn't have source routing disable. You'll get a response. Curtis From owner-mpls@UU.NET Fri Dec 6 14:00:26 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 OAA19655 for ; Fri, 6 Dec 2002 14:00:25 -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 QQnsci02428 for ; Fri, 6 Dec 2002 19:03: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 QQnsch25298; Fri, 6 Dec 2002 18:59:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsch16757 for mpls-outgoing; Fri, 6 Dec 2002 18:58: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 QQnsch16736 for ; Fri, 6 Dec 2002 18:58:24 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 QQnsch18194 for ; Fri, 6 Dec 2002 18:57: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 QQnsch13370 for ; Fri, 6 Dec 2002 18:57:48 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 QQnsch13364 for ; Fri, 6 Dec 2002 18:57:48 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6IwGZb015739 for ; Fri, 6 Dec 2002 13:58:16 -0500 (EST) 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 NAA18749 for ; Fri, 6 Dec 2002 13:57:46 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB6Ivj118998 for mpls@uu.net; Fri, 6 Dec 2002 13:57:45 -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 QQnsch16024 for ; Fri, 6 Dec 2002 18:50:49 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 QQnsch28577 for ; Fri, 6 Dec 2002 18:50:14 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 QQnsch16810 for ; Fri, 6 Dec 2002 18:50:14 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 QQnsch16794 for ; Fri, 6 Dec 2002 18:50:13 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 NAA21548; Fri, 6 Dec 2002 13:48:58 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212061848.NAA21548@workhorse.fictitious.org> To: Shahram Davari cc: "'curtis@fictitious.org'" , "'George Swallow'" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Fri, 06 Dec 2002 10:35:22 PST." <4B6D09F3B826D411A67300D0B706EFDEB03B57@nt-exch-yow.pmc-sierra.bc.ca> Date: Fri, 06 Dec 2002 13:48:58 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4B6D09F3B826D411A67300D0B706EFDEB03B57@nt-exch-yow.pmc-sierra.bc.ca >, Shahram Davari writes: > > >, Shahram Davari writes: > > > I understand the intent, but these RFCs explicitly prohibit sending > > > 127/8 addresses out of any box. It is for a node's internal > > use only. > > > > > > -Shahram > > > > > > This does not make it routeable. It is no more a violation than using > > a an IP source route with a 127.0.0.1 destination when you > > know that the > > destination used the standard numbering of the loopback. > > > > If any part of 127/8 became routable then it would be a violation of > > the intent. > > > > The LSP-ping objectors seem to be grasping at straws with this one. > > > > Curtis > > Yes, but it makes it droppable even by correct egress. > > -Shahram We'll process it as specified in lsp-ping. So will Cisco and Juniper. And we won't a bit guilty about it because it does not violate rfc1700 in any way. Curtis From owner-mpls@UU.NET Fri Dec 6 14:11:20 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 OAA20100 for ; Fri, 6 Dec 2002 14:11:20 -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 QQnsci00751 for ; Fri, 6 Dec 2002 19:14: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 QQnsci25083; Fri, 6 Dec 2002 19:10:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsci05865 for mpls-outgoing; Fri, 6 Dec 2002 19:10: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 QQnsci05854 for ; Fri, 6 Dec 2002 19:10: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 QQnsci19761 for ; Fri, 6 Dec 2002 19:09: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 QQnsci23576 for ; Fri, 6 Dec 2002 19:09:09 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 QQnsci23570 for ; Fri, 6 Dec 2002 19:09:08 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6J9a2G017243 for ; Fri, 6 Dec 2002 14:09:36 -0500 (EST) 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 OAA19792 for ; Fri, 6 Dec 2002 14:09:07 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB6J97c23304 for mpls@uu.net; Fri, 6 Dec 2002 14:09:07 -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 QQnsci05264 for ; Fri, 6 Dec 2002 19:07:08 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 QQnsci24756 for ; Fri, 6 Dec 2002 19:05:05 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 QQnsci02106 for ; Fri, 6 Dec 2002 19:05:05 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 QQnsci02072 for ; Fri, 6 Dec 2002 19:05:04 GMT Received: (qmail 12154 invoked by uid 104); 6 Dec 2002 19:05:03 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4236. . Clean. Processed in 0.478086 secs); 06 Dec 2002 19:05:03 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 6 Dec 2002 19:05:02 -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 gB6J51Q09728; Fri, 6 Dec 2002 11:05:02 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Fri, 6 Dec 2002 11:05:01 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B58@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'curtis@fictitious.org'" Cc: swallow@cisco.com, mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Fri, 6 Dec 2002 11:04:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > > Therefore such a packet will get discarded at that node > before even reaching > > the UDP/ping layer. > > > > > > -Shahram > > > Try "ping -g 127.0.0.1" fron any host or router > that supports source route ping to any host or router that doesn't > have source routing disable. You'll get a response. > > Curtis > Try "ping 127.0.0.1" while your Ethernet wire is disconnected from your host. You will get a response. -Shahram From owner-mpls@UU.NET Fri Dec 6 14:36: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 OAA21363 for ; Fri, 6 Dec 2002 14:36:55 -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 QQnsck29700 for ; Fri, 6 Dec 2002 19:39: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 QQnsck24987; Fri, 6 Dec 2002 19:36:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsck09551 for mpls-outgoing; Fri, 6 Dec 2002 19:36:14 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 QQnsck09394 for ; Fri, 6 Dec 2002 19:36:02 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 QQnsck17865 for ; Fri, 6 Dec 2002 19:34:45 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 QQnsck23596 for ; Fri, 6 Dec 2002 19:34:45 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 QQnsck23590 for ; Fri, 6 Dec 2002 19:34:44 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6JZC3V020978 for ; Fri, 6 Dec 2002 14:35:12 -0500 (EST) 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 OAA22396 for ; Fri, 6 Dec 2002 14:34:43 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB6JYhP29757 for mpls@uu.net; Fri, 6 Dec 2002 14:34:43 -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 QQnsck08628 for ; Fri, 6 Dec 2002 19:33:30 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 QQnsck01905 for ; Fri, 6 Dec 2002 19:32:14 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 QQnsck22536 for ; Fri, 6 Dec 2002 19:32:14 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 QQnsck22532 for ; Fri, 6 Dec 2002 19:32:13 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6JWclL020645; Fri, 6 Dec 2002 14:32:38 -0500 (EST) 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 OAA22181; Fri, 6 Dec 2002 14:32:08 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA03472; Fri, 6 Dec 2002 14:32:08 -0500 (EST) Message-Id: <200212061932.OAA03472@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: neil.2.harrison@bt.com cc: swallow@cisco.com, Shahram_Davari@pmc-sierra.com, mpls@UU.NET, swallow@cisco.com Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Fri, 06 Dec 2002 17:49:37 GMT." <0536FC9B908BEC4597EE721BE6A35389014CFCB1@i2km07-ukbr.domain1.systemhost.net> Date: Fri, 06 Dec 2002 14:32:08 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > George....I think the point Shahram was making it is not even allowed > outside the host/source box according to the text quoted from the RFcs > below. Wrapping it in some other package (any, not just MPLS) is still > violating this requirement...and note that it *must* be placed in some > package to get across any tranmission medium....IP pkts don't go raw on > wires. As far as I'm concerned it is within the spirit of the RFCs. If you want to insist on the letter of the law, perhaps you should look into a career as a solicitor. ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Fri Dec 6 14:40: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 OAA21472 for ; Fri, 6 Dec 2002 14:40:35 -0500 (EST) 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 QQnscb06682; Fri, 6 Dec 2002 17:25:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQnscb18672 for mpls-outgoing; Fri, 6 Dec 2002 17:24:43 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 QQnscb18656 for ; Fri, 6 Dec 2002 17:24:38 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 QQnscb03418 for ; Fri, 6 Dec 2002 17:24:07 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 QQnscb01966 for ; Fri, 6 Dec 2002 17:24:07 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 QQnscb01956 for ; Fri, 6 Dec 2002 17:24:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6HOYrY003552 for ; Fri, 6 Dec 2002 12:24:35 -0500 (EST) 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 MAA10875 for ; Fri, 6 Dec 2002 12:24:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB6HO5w25463 for mpls@uu.net; Fri, 6 Dec 2002 12:24:05 -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 QQnscb18445 for ; Fri, 6 Dec 2002 17:22: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 QQnscb04233 for ; Fri, 6 Dec 2002 17:22: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 QQnscb00855 for ; Fri, 6 Dec 2002 17:22:48 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 QQnscb00847 for ; Fri, 6 Dec 2002 17:22:48 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6HNENv003400; Fri, 6 Dec 2002 12:23:14 -0500 (EST) 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 MAA10749; Fri, 6 Dec 2002 12:22:44 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id MAA02534; Fri, 6 Dec 2002 12:22:44 -0500 (EST) Message-Id: <200212061722.MAA02534@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Shahram Davari cc: swallow@cisco.com, mpls@UU.NET, swallow@cisco.com Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Fri, 06 Dec 2002 09:15:15 PST." <4B6D09F3B826D411A67300D0B706EFDEB03B53@nt-exch-yow.pmc-sierra.bc.ca> Date: Fri, 06 Dec 2002 12:22:44 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > RFC 3330 says: > > > 127.0.0.0/8 - This block is assigned for use as the Internet host > loopback address. A datagram sent by a higher level protocol to an > address anywhere within this block should loop back inside the host. > This is ordinarily implemented using only 127.0.0.1/32 for loopback, > but no addresses within this block should ever appear on any network > anywhere [RFC1700, page 5]. > > And RFC1700 says: > > g) {127, } > > Internal host loopback address. Should never appear outside > a host. > > > Doesn't this draft violate these RFCs? This it falls within the intent. If the label stack gets completely poped off you don't want it to go any further. That's the whole point of using that address range. I really don't see a need to find a new range. (Note that I'm counting the implicit null as still being a label stack - so the packet gets as far as the stack will take it and no further.) ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Fri Dec 6 14:41: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 OAA21511 for ; Fri, 6 Dec 2002 14:41:03 -0500 (EST) 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 QQnscb05366; Fri, 6 Dec 2002 17:24:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQnscb18603 for mpls-outgoing; Fri, 6 Dec 2002 17:24: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 QQnscb18557 for ; Fri, 6 Dec 2002 17:23: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 QQnscb00894 for ; Fri, 6 Dec 2002 17:23: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 QQnscb10763 for ; Fri, 6 Dec 2002 17:23:15 GMT Received: from hoemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQnscb10749 for ; Fri, 6 Dec 2002 17:23:14 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 gB6HNCA08063 for ; Fri, 6 Dec 2002 12:23:12 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Dec 2002 18:23:11 +0100 Message-ID: From: "Wijnen, Bert (Bert)" To: Adrian Farrel , "Mpls (E-mail)" Subject: RE: review of draft-ietf-mpls-lsr-mib-09.txt Date: Fri, 6 Dec 2002 18:23:10 +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 > Bert, > I haven't been party to the discussions with the MPLS MIB > authors on this point, > but I will jump in because the GMPLS MIBs do/might use this construct. > > > - mplsXxxxIndexNext > > We have talked about this a number of times. It still bothers me that > > you state that on every retrieval operation the agent MUST change the > > value. This sort of ENSURES that index values are non-contiguous. > > I guess that what you describe works.. but far from ideal. > > It is certainly not intentional that the index values are non-contiguous. In > fact, it is intended that they ARE contiguous and also that they are uniquely > reserved for users which is important when there are multiple users trying to > create rows. > > > I really believe that you guys should look at the IndexInteger and > > IndexIntegerNextFree TCs in RFC3289, page 38. I think doing it that way > > is MUCH MUCH (yeas really MUCH) better. > > In fact, you could just use those TCs... although it makes you dependent > > on that MIB module. It is already at PS, so... > > This construct appears to be the same except that the one in the LSR MIB > attempts to close the window where two applications are attempting to create > rows at once. In RFC3289, both may read the object of type IndexIntegerNextFree > and get the same value: the second create is doomed to fail. > In the LSR MIB when the first application reads the xxxxIndexNext the value is > incremented so that the next read (by the second application) will return a > different value. > And do you realize that there are LOTS and LOTS of tools/mib-browsers out there that just do MIB walks and so everytime they pass your xxxIndexNext object, they will cause it to bump and for sure they will NOT create a new row. > It is true that the LSR MIB approach may lead to lacunas if an application > decides not to create a row after all, but that is not necessarily a problem. > But because of the many many WALK operations (GETNEXT, GETBULK) it may happen far more often than you expect., > I assume that this issue has been addressed in multiple MIB modules in the past > and guess there isn't a standard way of solving it. > FWIW the LSM MIB approach is used in the AToM MIBs. For xample, > atmVpCrossConnectIndexNext in RFC2515. > > A common approach across all MIB modules would certainly be welcome. > Is there a MIB Doctor in the house? > I think that an approach as per RFC3289 is reasonable and better than what you have. I think an even better approach might be to use a TestAndIncr object (TC from RFC2579). You would have to - retrieve the value - issue a SET with as first varbind the TestAndIncr object and the following varBinds the varbinds to create a row. - If another manager has done the same, then you fail on the first varBind. so it is a nice way to sync managers. - If you succeed, then the value gets incremented at the same time you indeed create a row (assuming that that does succeed.). - A negative is that once you have wrapped around, incrementing by one does not guarantee a free entry. So if you expect a lifetime where a unsigned 32 indeed wraps around, then this is not a good approach. Bert From owner-mpls@UU.NET Fri Dec 6 14:46: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 OAA21723 for ; Fri, 6 Dec 2002 14:46:11 -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 QQnscl10757 for ; Fri, 6 Dec 2002 19:48:56 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 QQnscl07036; Fri, 6 Dec 2002 19:46:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQnscl14424 for mpls-outgoing; Fri, 6 Dec 2002 19:46:15 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 QQnscl14270 for ; Fri, 6 Dec 2002 19:46: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 QQnscl07609 for ; Fri, 6 Dec 2002 19:45: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 QQnscl06224 for ; Fri, 6 Dec 2002 19:45:48 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 QQnscl06213 for ; Fri, 6 Dec 2002 19:45:47 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6JkFbB022454 for ; Fri, 6 Dec 2002 14:46:15 -0500 (EST) 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 OAA23499 for ; Fri, 6 Dec 2002 14:45:46 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB6Jjkr03165 for mpls@uu.net; Fri, 6 Dec 2002 14:45:46 -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 QQnsck13276 for ; Fri, 6 Dec 2002 19:44: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 QQnsck24310 for ; Fri, 6 Dec 2002 19:43: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 QQnsck04896 for ; Fri, 6 Dec 2002 19:43:11 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 QQnsck04890 for ; Fri, 6 Dec 2002 19:43: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 gB6JhbXj022099; Fri, 6 Dec 2002 14:43:38 -0500 (EST) Received: from tnadeau-w2k.cisco.com (che-vpn-cluster-2-87.cisco.com [10.86.242.87]) by bucket.cisco.com (Mirapoint) with ESMTP id ACF66414; Fri, 6 Dec 2002 14:43:07 -0500 (EST) Message-Id: <5.2.0.9.2.20021206141847.03a596f0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 06 Dec 2002 14:43:05 -0500 To: Shahram Davari From: "Thomas D. Nadeau" Subject: RE: Last call on LSP Ping Cc: mpls@UU.NET In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03B55@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 >I understand the intent, but these RFCs explicitly prohibit sending >127/8 addresses out of any box. It is for a node's internal use only. The addresses are not sent to be included in a routeable packet on the wire. The processing behavior is well defined for how to process the LSP Ping payload, and I agree with Curtis that the address range use is perfectly valid. --Tom >-Shahram > > > -----Original Message----- > > From: George Swallow [mailto:swallow@cisco.com] > > Sent: Friday, December 06, 2002 12:23 PM > > To: Shahram Davari > > Cc: swallow@cisco.com; mpls@UU.NET; swallow@cisco.com > > Subject: Re: Last call on LSP Ping > > > > > > > RFC 3330 says: > > > > > > > > > 127.0.0.0/8 - This block is assigned for use as the Internet host > > > loopback address. A datagram sent by a higher level > > protocol to an > > > address anywhere within this block should loop back > > inside the host. > > > This is ordinarily implemented using only 127.0.0.1/32 > > for loopback, > > > but no addresses within this block should ever appear on > > any network > > > anywhere [RFC1700, page 5]. > > > > > > And RFC1700 says: > > > > > > g) {127, } > > > > > > Internal host loopback address. Should never > > appear outside > > > a host. > > > > > > > > > Doesn't this draft violate these RFCs? > > > > This it falls within the intent. If the label stack gets completely > > poped off you don't want it to go any further. That's the whole point > > of using that address range. I really don't see a need to find a new > > range. > > > > (Note that I'm counting the implicit null as still being a label stack > > - so the packet gets as far as the stack will take it and no further.) > > > > ...George > > > > ================================================================== > > George Swallow Cisco Systems (978) 497-8143 > > 250 Apollo Drive > > Chelmsford, Ma 01824 > > From owner-mpls@UU.NET Fri Dec 6 14:55:16 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 OAA22028 for ; Fri, 6 Dec 2002 14:55: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 QQnscl08038 for ; Fri, 6 Dec 2002 19:57: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 QQnscl01361; Fri, 6 Dec 2002 19:54:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQnscl17675 for mpls-outgoing; Fri, 6 Dec 2002 19:53: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 QQnscl17606 for ; Fri, 6 Dec 2002 19:53: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 QQnscl19133 for ; Fri, 6 Dec 2002 19:53: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 QQnscl17005 for ; Fri, 6 Dec 2002 19:53:13 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 QQnscl16998 for ; Fri, 6 Dec 2002 19:53:12 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6Jrdb6023457 for ; Fri, 6 Dec 2002 14:53:40 -0500 (EST) 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 OAA24148 for ; Fri, 6 Dec 2002 14:53:10 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB6JrAk04376 for mpls@uu.net; Fri, 6 Dec 2002 14:53:10 -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 QQnscl16677 for ; Fri, 6 Dec 2002 19:51:44 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 QQnscl19003 for ; Fri, 6 Dec 2002 19:50:17 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 QQnscl21005 for ; Fri, 6 Dec 2002 19:50:16 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 QQnscl20993 for ; Fri, 6 Dec 2002 19:50:15 GMT Received: (qmail 15015 invoked by uid 104); 6 Dec 2002 19:50:15 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4236. . Clean. Processed in 0.945565 secs); 06 Dec 2002 19:50:15 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 6 Dec 2002 19:50:13 -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 gB6JoDQ07365; Fri, 6 Dec 2002 11:50:13 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Fri, 6 Dec 2002 11:50:13 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B59@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Thomas D. Nadeau'" Cc: mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Fri, 6 Dec 2002 11:50:11 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk More proof: RFC 1812 (Requirements for IP Version 4 Routers): A router SHOULD NOT forward any packet that has an invalid IP destination address or a destination address on network 0. A router SHOULD NOT forward, except over a loopback interface, any packet that has a destination address on network 127. A router MAY have a switch that allows the network manager to disable these checks. If such a switch is provided, it MUST default to performing the checks... A router SHOULD provide a mechanism to filter out obviously invalid routes (such as those for net 127). -Shahram > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Friday, December 06, 2002 2:43 PM > To: Shahram Davari > Cc: mpls@UU.NET > Subject: RE: Last call on LSP Ping > > > > >I understand the intent, but these RFCs explicitly prohibit sending > >127/8 addresses out of any box. It is for a node's internal use only. > > The addresses are not sent to be included in a routeable > packet on the wire. The processing behavior is well defined for > how to process the LSP Ping payload, and I agree with Curtis > that the address range use is perfectly valid. > > --Tom > > > > >-Shahram > > > > > -----Original Message----- > > > From: George Swallow [mailto:swallow@cisco.com] > > > Sent: Friday, December 06, 2002 12:23 PM > > > To: Shahram Davari > > > Cc: swallow@cisco.com; mpls@UU.NET; swallow@cisco.com > > > Subject: Re: Last call on LSP Ping > > > > > > > > > > RFC 3330 says: > > > > > > > > > > > > 127.0.0.0/8 - This block is assigned for use as the > Internet host > > > > loopback address. A datagram sent by a higher level > > > protocol to an > > > > address anywhere within this block should loop back > > > inside the host. > > > > This is ordinarily implemented using only 127.0.0.1/32 > > > for loopback, > > > > but no addresses within this block should ever appear on > > > any network > > > > anywhere [RFC1700, page 5]. > > > > > > > > And RFC1700 says: > > > > > > > > g) {127, } > > > > > > > > Internal host loopback address. Should never > > > appear outside > > > > a host. > > > > > > > > > > > > Doesn't this draft violate these RFCs? > > > > > > This it falls within the intent. If the label stack gets > completely > > > poped off you don't want it to go any further. That's > the whole point > > > of using that address range. I really don't see a need > to find a new > > > range. > > > > > > (Note that I'm counting the implicit null as still being > a label stack > > > - so the packet gets as far as the stack will take it and > no further.) > > > > > > ...George > > > > > > ================================================================== > > > George Swallow Cisco Systems (978) 497-8143 > > > 250 Apollo Drive > > > Chelmsford, Ma 01824 > > > > > From owner-mpls@UU.NET Fri Dec 6 15:12: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 PAA22679 for ; Fri, 6 Dec 2002 15:12:56 -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 QQnscn02023 for ; Fri, 6 Dec 2002 20:15:43 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 QQnscm20895; Fri, 6 Dec 2002 20:09:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQnscm11995 for mpls-outgoing; Fri, 6 Dec 2002 20:09:05 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 QQnscm11921 for ; Fri, 6 Dec 2002 20:08:53 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 QQnscm28102 for ; Fri, 6 Dec 2002 20:05:28 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 QQnscm28809 for ; Fri, 6 Dec 2002 20:05:27 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 QQnscm28798 for ; Fri, 6 Dec 2002 20:05:27 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6K5tIQ025183 for ; Fri, 6 Dec 2002 15:05:55 -0500 (EST) 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 PAA25269 for ; Fri, 6 Dec 2002 15:05:26 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB6K5Qi09663 for mpls@uu.net; Fri, 6 Dec 2002 15:05:26 -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 QQnscm03297 for ; Fri, 6 Dec 2002 20:03:56 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 QQnscm07430 for ; Fri, 6 Dec 2002 20:02: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 QQnscm25979 for ; Fri, 6 Dec 2002 20:02:27 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 QQnscm25961 for ; Fri, 6 Dec 2002 20:02:26 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6K2c1A024807; Fri, 6 Dec 2002 15:02:39 -0500 (EST) 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 PAA24984; Fri, 6 Dec 2002 15:02:09 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id PAA04163; Fri, 6 Dec 2002 15:02:09 -0500 (EST) Message-Id: <200212062002.PAA04163@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Shahram Davari cc: "'Thomas D. Nadeau'" , mpls@UU.NET, swallow@cisco.com Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Fri, 06 Dec 2002 11:50:11 PST." <4B6D09F3B826D411A67300D0B706EFDEB03B59@nt-exch-yow.pmc-sierra.bc.ca> Date: Fri, 06 Dec 2002 15:02:09 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > More proof: > > RFC 1812 (Requirements for IP Version 4 Routers): > > > A router SHOULD NOT forward any packet that has an invalid IP > destination address or a destination address on network 0. A router > SHOULD NOT forward, except over a loopback interface, any packet that > has a destination address on network 127. A router MAY have a switch > that allows the network manager to disable these checks. If such a > switch is provided, it MUST default to performing the checks... > > A router SHOULD provide a mechanism to filter out obviously invalid > routes (such as those for net 127). Which is exactly what we want the router that get this to do. ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Fri Dec 6 15:13: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 PAA22708 for ; Fri, 6 Dec 2002 15:13: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 QQnscn11207 for ; Fri, 6 Dec 2002 20:16: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 QQnscm07619; Fri, 6 Dec 2002 20:14:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQnscm14671 for mpls-outgoing; Fri, 6 Dec 2002 20:14:06 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 QQnscm14562 for ; Fri, 6 Dec 2002 20:13: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 QQnscm14443 for ; Fri, 6 Dec 2002 20:12:21 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 QQnscm05589 for ; Fri, 6 Dec 2002 20:12:21 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 QQnscm05576 for ; Fri, 6 Dec 2002 20:12:21 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6KCnVa026248 for ; Fri, 6 Dec 2002 15:12:49 -0500 (EST) 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 PAA26059 for ; Fri, 6 Dec 2002 15:12:19 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB6KCJ110356 for mpls@uu.net; Fri, 6 Dec 2002 15:12:19 -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 QQnscm13228 for ; Fri, 6 Dec 2002 20:11: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 QQnscm04112 for ; Fri, 6 Dec 2002 20:08:30 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 QQnscm01700 for ; Fri, 6 Dec 2002 20:08:29 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 QQnscm01696 for ; Fri, 6 Dec 2002 20:08:29 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 gB6K8tbo025706; Fri, 6 Dec 2002 15:08:56 -0500 (EST) Received: from tnadeau-w2k.cisco.com (che-vpn-cluster-2-87.cisco.com [10.86.242.87]) by bucket.cisco.com (Mirapoint) with ESMTP id ACF66974; Fri, 6 Dec 2002 15:08:26 -0500 (EST) Message-Id: <5.2.0.9.2.20021206150637.045bb3e8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 06 Dec 2002 15:08:19 -0500 To: Shahram Davari From: "Thomas D. Nadeau" Subject: RE: Last call on LSP Ping Cc: mpls@UU.NET In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03B59@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 >More proof: Of what? >RFC 1812 (Requirements for IP Version 4 Routers): > > > A router SHOULD NOT forward any packet that has an invalid IP > destination address or a destination address on network 0. A router > SHOULD NOT forward, except over a loopback interface, any packet that > has a destination address on network 127. A router MAY have a switch > that allows the network manager to disable these checks. If such a > switch is provided, it MUST default to performing the checks... > > A router SHOULD provide a mechanism to filter out obviously invalid > routes (such as those for net 127). Isn't this why the 127 addresses were used (i.e.: to prevent mis- routing if the MPLS header was removed)? --Tom >-Shahram > > > > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: Friday, December 06, 2002 2:43 PM > > To: Shahram Davari > > Cc: mpls@UU.NET > > Subject: RE: Last call on LSP Ping > > > > > > > > >I understand the intent, but these RFCs explicitly prohibit sending > > >127/8 addresses out of any box. It is for a node's internal use only. > > > > The addresses are not sent to be included in a routeable > > packet on the wire. The processing behavior is well defined for > > how to process the LSP Ping payload, and I agree with Curtis > > that the address range use is perfectly valid. > > > > --Tom > > > > > > > > >-Shahram > > > > > > > -----Original Message----- > > > > From: George Swallow [mailto:swallow@cisco.com] > > > > Sent: Friday, December 06, 2002 12:23 PM > > > > To: Shahram Davari > > > > Cc: swallow@cisco.com; mpls@UU.NET; swallow@cisco.com > > > > Subject: Re: Last call on LSP Ping > > > > > > > > > > > > > RFC 3330 says: > > > > > > > > > > > > > > > 127.0.0.0/8 - This block is assigned for use as the > > Internet host > > > > > loopback address. A datagram sent by a higher level > > > > protocol to an > > > > > address anywhere within this block should loop back > > > > inside the host. > > > > > This is ordinarily implemented using only 127.0.0.1/32 > > > > for loopback, > > > > > but no addresses within this block should ever appear on > > > > any network > > > > > anywhere [RFC1700, page 5]. > > > > > > > > > > And RFC1700 says: > > > > > > > > > > g) {127, } > > > > > > > > > > Internal host loopback address. Should never > > > > appear outside > > > > > a host. > > > > > > > > > > > > > > > Doesn't this draft violate these RFCs? > > > > > > > > This it falls within the intent. If the label stack gets > > completely > > > > poped off you don't want it to go any further. That's > > the whole point > > > > of using that address range. I really don't see a need > > to find a new > > > > range. > > > > > > > > (Note that I'm counting the implicit null as still being > > a label stack > > > > - so the packet gets as far as the stack will take it and > > no further.) > > > > > > > > ...George > > > > > > > > ================================================================== > > > > George Swallow Cisco Systems (978) 497-8143 > > > > 250 Apollo Drive > > > > Chelmsford, Ma 01824 > > > > > > > > From owner-mpls@UU.NET Fri Dec 6 15:24: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 PAA23054 for ; Fri, 6 Dec 2002 15:24:41 -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 QQnscn17331 for ; Fri, 6 Dec 2002 20:27:23 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 QQnscn10220; Fri, 6 Dec 2002 20:22:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQnscn18667 for mpls-outgoing; Fri, 6 Dec 2002 20:22:31 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 QQnscn18590 for ; Fri, 6 Dec 2002 20:22:22 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 QQnscn12675 for ; Fri, 6 Dec 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 QQnscn18212 for ; Fri, 6 Dec 2002 20:22:02 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 QQnscn18205 for ; Fri, 6 Dec 2002 20:22:02 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6KMUYP027454 for ; Fri, 6 Dec 2002 15:22:30 -0500 (EST) 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 PAA26821 for ; Fri, 6 Dec 2002 15:22:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB6KM0k14085 for mpls@uu.net; Fri, 6 Dec 2002 15:22:00 -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 QQnscn17708 for ; Fri, 6 Dec 2002 20:19:41 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 QQnscn02390 for ; Fri, 6 Dec 2002 20:18: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 QQnscn06481 for ; Fri, 6 Dec 2002 20:18:40 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 QQnscn06446 for ; Fri, 6 Dec 2002 20:18:40 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 gB6KJ6ob027053; Fri, 6 Dec 2002 15:19:06 -0500 (EST) Received: from tnadeau-w2k.cisco.com (che-vpn-cluster-2-87.cisco.com [10.86.242.87]) by bucket.cisco.com (Mirapoint) with ESMTP id ACF67196; Fri, 6 Dec 2002 15:18:36 -0500 (EST) Message-Id: <5.2.0.9.2.20021206101151.038bc7f8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 06 Dec 2002 15:18:33 -0500 To: "Wijnen, Bert (Bert)" From: "Thomas D. Nadeau" Subject: Re: review of draft-ietf-mpls-lsr-mib-09.txt Cc: "Mpls (E-mail)" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >Oh well... > >Several of my earlier comments have not been addressed at all. >Several others have been addressed (thanks). >I had quickly skimmed through the new rev before the Atlanta >MIB meeting, assuming all my concerns were addressed. >These earlier comments (1H2002) were sent to authors only... > >Here we go. Mix of nits and serious stuff > >- I am missing IPR section > >- abstract says: > community. In particular, it describes managed objects for > modeling a Multiprotocol Label Switching (MPLS) Label Switching > Router (LSR). > Not sure it is so much "objects for modeling" as it is "objects to > configure and/or monitor" > >- sect 9 talks about MIB II. I think you better just talk about > RFC2863 (IF-MIB). > >- sect 10 says: > RowPointer is a textual convention used to identify a conceptual > row in an SNMP Table by pointing to one of its objects. In this > REPEAT for the umptieth time: > it is not just pointing to "one of its objects", but to "the > first accessible object in a row". Again see RFC2579 for that > >- sect 10 last sentence has an empty [] at the end? > >- I wonder why mplsInterfaceConfTable and ...ConfEntry and ...ConfIndex > have the "Conf" in there. > NONE of the accessible objects in the table havae that prefxi "Conf" > in them. Besides, the "Conf" to me suggests that you can use the > table to configure something, but it is a read-only table, so > it only lists details about existing mplsInterfaces. > mplsInterfaceTable and mplsInterfaceEntry seem better names to me > You may also want to say something about the table being read-only > in the atble DESCRIPTION clause Conf stands for "Configured" (i.e.: the configured MPLS interfaces). >- mplsInterfaceConfEntry > s/iff/if/ > It talks about what a index of zero means. That is OK... bit really > that info should be in the DESCRIPTION clause of the index object > itself. If nothing else, then repeat the meaning of zero in the > index object. The last comments asked to put them into the table description. We can put them here too. >- mplsInterfaceConfIndex OBJECT-TYPE > SYNTAX InterfaceIndexOrZero > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This is a unique index for an entry in the > MplsInterfaceConfTable. A non-zero index for an > entry indicates the ifIndex for the corresponding > interface entry in of the MPLS-layer in the ifTable. >==> is the above a proper English sentence? > >- probably want to add a UNITS clause to mplsInterfaceTotalBandwith > and ...AvailableBandwidth > >- mplsInterfaceLabelParticipationType OBJECT-TYPE > SYNTAX BITS { > perPlatform (0), > perInterface (1) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Either the perPlatform(0) or perInterface(1) bit > MUST be set. Note however that an interface could > participate in both label spaces in which case both > bits would be set. If the value of the > mplsInterfaceConfIndex for this entry is zero, then > only the perPlatform(0) bit MUST be set and the > perInterface(1) bit is meaningless. If the > perInterface(1) bit is set then the value of > mplsInterfaceLabelMinIn, mplsInterfaceLabelMaxIn, > mplsInterfaceLabelMinOut, and > mplsInterfaceLabelMaxOut for this entry reflect the > label ranges for this interface. If only the > perPlatform(0) bit is set, then the value of > mplsInterfaceLabelMinIn, mplsInterfaceLabelMaxIn, > mplsInterfaceLabelMinOut, and > mplsInterfaceLabelMaxOut for this entry must be > identical to the instance of these objects with > index 0." > > I think you mean well... but the 1st and 2nd sentence seem > to contradict each other. Replace: Either the perPlatform(0) or perInterface(1) bit MUST be set. Note however that an interface could participate in both label spaces in which case both bits would be set. With: Either the perPlatform(0) or perInterface(1) bit MUST be set, but both MAY be set to denote an interface participating in both label spaces. > Also the last "must" probably is better a "MUST". > The text is also not easy to read... what do you think about" > > DESCRIPTION > "Specifies if the interface uses labels from the interface > label-space and/or the per-platform label-space. > > If the value of the mplsInterfaceConfIndex for this entry is > zero, then only the perPlatform(0) bit MUST be set and the > perInterface(1) bit is meaningless. > > If the perInterface(1) bit is set then the value of > mplsInterfaceLabelMinIn, mplsInterfaceLabelMaxIn, > mplsInterfaceLabelMinOut, and mplsInterfaceLabelMaxOut for > this entry reflect the label ranges for this interface. > > If only the perPlatform(0) bit is set, then the value of > mplsInterfaceLabelMinIn, mplsInterfaceLabelMaxIn, > mplsInterfaceLabelMinOut, and mplsInterfaceLabelMaxOut for > this entry MUST be identical to the instance of these > objects with index 0." Okay. > What is still not clear from the above: > - assume per-platform has label range MinIn/MaxIn 50-100 > - assume interface itself has label range MinIn/MaxIn 60-90 > - assume both bits are set to 1. > > What happens? does it have to allocate/use labels in range 60-90 > first and only when that range is exhausted in ranges 50-59 and > 91-100 ?? I think that most LSRs out there just allocate from the set of labels they are assigned; the order is not specified anywhere. >- mplsInterfaceInLabelsUsed Gauge32, > mplsInterfaceLabelLookupFailures Counter32, > mplsInterfaceOutLabelsUsed Gauge32, > mplsInterfaceOutFragments Counter32 > > I (still) believe that ....LabelsUsed is an incorrect name. > It should be ...LabelsInUse (at this point in time, as the > DESCRIPTION clause explains). Okay. > I also still think that ..OutFragments is probably better called > ....OutFragmentedPackets (as per description clause) OutFragmentedPkts. > Why do you not let all these names start with mplsInterfacePerfXxxx > so that it is VERY CLEAR that these objects are located in this > specific table? > >- mplsInSegmentEntry OBJECT-TYPE > INDEX { mplsInSegmentIfIndex, mplsInSegmentLabel } > > Question: does there have to be one or more entries for every entry > in the mplsInterfaceConfTable? > If so, the first index probably should be mplsInterfaceConfIndex If a label exists, a corresponding ifIndex needs to go with it. > In any event, in my previous comment I had mentioned that ...IfIndex > in the name of the index object is confusing, cause IfIndex is an > object in the ifTable. I had suggested to use ...Interface > or ...LabelSpace or such mpslInSegmentIf ? >- mplsInSegmentAddrFamily OBJECT-TYPE > SYNTAX AddressFamilyNumbers > In my previosu comments I had asked what this is used for? > I either have missed the answer or forgot. > >- As per earlier comment: > mplsTrafficParamEntry > "resource sharing" ???? see also my earlier comment on this: > d. In sect 4, you state that the MIB allows resource sharing > between multiple LSPs. Not sure, but I think you mean that > various Tables can have entries that are shared by multiple > entries in Other tables. So it is sharing "memory resources" > when implementing the MIB I think. Such is not clear. > It could be interpreted to mean that LSPs share other > physical resources (which migth be possible too, but I > am not sure that the MIB has anything to do with that > or if so, pls explain). > There is more of this "resource sharing" talk throughout > the MIB. You may want to check that and make sure it is > clear what you mean. I thought we agreed to remove this entire table during the last review? >- mplsInSegmentRowStatus OBJECT-TYPE > SYNTAX RowStatus > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "This variable is used to create, modify, and/or > delete a row in this table." > > As per RFC2579, you must specify which columns can be changed > if row is active. Seems the simple sentence to add is: > > "When this row is in active(a) state, no objects in this row can > be changed." > > This is true for all your RowStatus objects in this MIB module Will make clear for all tables. >- mplsInSegmentStorageType OBJECT-TYPE > SYNTAX StorageType > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "This variable indicates the storage type for this > object. This object cannot be modified if > mplsInSegmentRowStatus is active(1). If this > variable is set to readOnly(5), and the > corresponding LFIB entry is removed, then the agent > must remove this row shortly thereafter [RFC2579]." > > As explained earlier, you MUST add text as to what objects (if any) > MUST be writable for a 'permanent' row. See RFC2579. This is true > for all you StorageType objetcs in this MIB module. > > Also... it might be good/wise to add a DEFAULT. In many MIB modules > we have used volatile as the DEFATULT value. Okay. Must have missed this one. Will check everywhere anyway. >- MplsInSegmentPerfEntry ::= SEQUENCE { > mplsInSegmentOctets Counter32, > mplsInSegmentPackets Counter32, > mplsInSegmentErrors Counter32, > mplsInSegmentDiscards Counter32, > > -- high capacity counter > mplsInSegmentHCOctets Counter64, > > mplsInSegmentPerfDiscontinuityTime TimeStamp > > Why do you not add "Perf" in the name of all these objects > so that the names start with mplsInSegmentPerfXxxx and so that > it is VERY clear in which table they are located? Okay. This is part of the directive the make object names consistent that I planned on doing through the MIBs. > Since it is a short/small table, I guess it is easy to see from the > DiscontinuityTime object that that is the discontinuity timer. > RFC2578 says that each Counterxx object must include the text that > explains whihc timer is to be used for discontinuity. > So consider this a details-nit > >- mplsXxxxIndexNext > We have talked about this a number of times. It still bothers me that > you state that on every retrieval operation the agent MUST change the > value. This sort of ENSURES that index values are non-contiguous. > I guess that what you describe works.. but far from ideal. There is another one of these in the FTN MIBthat was fixed correctly as per your and Mike's requests. This was missed I think because it was not flagged directly; will fix as appears in the FTN MIB currently (which is based on the DiffServ MIB's use). > I really believe that you guys should look at the IndexInteger and > IndexIntegerNextFree TCs in RFC3289, page 38. I think doing it that way > is MUCH MUCH (yeas really MUCH) better. > In fact, you could just use those TCs... although it makes you dependent > on that MIB module. It is already at PS, so... > >- mplsOutSegmentIndex OBJECT-TYPE > SYNTAX Unsigned32(0..2147483647) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This value contains a unique index for this row. > While a value of 0 is not valid as an index for this > row it can be supplied as a valid value to index > mplsXCTable to access entries for which no out- > segment has been configured." > ::= { mplsOutSegmentEntry 1 } > > I think that this states that this object SHOULD have a range of > (1..2147483647) and so EXCLUDE value zero. And you should NOT > be using this object as index in the XCtable. The XCtable does > NOT augnment or extend this table! In fact, your current XCtable > has defined new objects for indexing, so you can safely start > the range at 1. I think we discussed this several times before. Yes, will fix. >- mplsOutSegmentNextHopIpAddrType OBJECT-TYPE > SYNTAX InetAddressType > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Indicates that the next hop address type is IPv4 > when set to ipv4 (1) or IPv6 when set to ipv6 (2). > A value of unknown (0) is allowed only when the > outgoing interface is of type point-to-point. If any > other values are attempted in a set operation the > agent MUST return an inconsistentValue error. This > object cannot be modified if mplsOutSegmentRowStatus > is active(1)." > > I think a MUCH better way to do this is: > DESCRIPTION > "Indicates that the next hop Internet address type. Only > values unknown (0), ipv4 (1) and ipv6 (2) have to be > supported. > > A value of unknown (0) is allowed only when the > outgoing interface is of type point-to-point. If any > other values are attempted in a set operation the > agent MUST return an inconsistentValue error. > > This object cannot be modified if mplsOutSegmentRowStatus > is active(1)." Cool. >- mplsOutSegmentNextHopIpAddr OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The IPv4 or IPv6 address of the next hop. Its value > is significant only when > mplsOutSegmentNextHopIpAddrType is ipv4 (1) or ipv6 > (2). Otherwise a management entity SHOULD set this > to 0 and an agent MUST ignore it. Likewise an agent > MUST return a value of 0 for a retrieval operation. > This object cannot be modified if > mplsOutSegmentRowStatus is active(1)." > > You cannot tell an agent what to return for retrieval... > It MUST always return whatever the value happens to be!! > I think a MUCH better way to do this is (and in sync with RFC3291): > DESCRIPTION > "The Internet address of the next hop. The type of > this address is determined by the value of the > mplsOutSegmentNextHopIpAddrType object. > > This object cannot be modified if mplsOutSegmentRowStatus > is active(1)." Cool. >- mplsOutSegmentXCIndex > s/is MUST/MUST/ > >- mplsOutSegmentRowStatus and ... Storagetype. > See my comments about RowStatus and Storagetype above > >- mplsXCEntry > talks about mplsXCOutSegmentIndex being able to have avlue of zero > but mplsXCOutSegmentIndex object itself has a range that excludes zero > So which one of the two is incorrect? > >- as discussed before: > mplsXCIsPersistent and mplsXCStorageType seem to be conflicting and/or > overlapping objects. What is the story here? > >- mplsXCRowStatus and STorageType > see my earlier comments on these two object types above > >- mplsXCAdminStatus > does it not make sense to add a DEFAVL ?? > >- mplsLabelStackRowStatus and StorageType > see my earlier comments on these two object types above > >- mplsTrafficParamRowStatus and StorageType > see my earlier comments on these two object types above > >- mplsNotificationsEnable. > Add at least a ptr to RFC2573 that explains that notifications > are under control of the MIB modules in that document > In other words, if you enable in the MPLS MIB module, these > notifications may still not be emitted based on settings in the > MIB modules in RFC2573. > >- mplsXCdown > s/be the identical/be identical/ > >- mplsXCUp and mplsXCDown > So will the OperStatus be the value 'up' and 'down' respectively? > Or will it be the value that it had before going into the Up or Down > state. The latter might pass more info. But in any event, it is > best to be explicit as to what an agent is supposed to send and > what a manager can expect to receive. XCup is issued on a transition from anything to up, and XCdown is issued on a transition from anything to down. will clarify. >- The "too quickly" in you xxxHCxxx DESCRIPTION clauses are not very > specific. I would rather be explicit what that means. Aka as is done > in IF-MIB. Okay. >- But in general, one might wonder why you do not just do 64bit counters > and require them on all devices. these LSR boxes will certainly have > the power to do so. I think we have done this elsewhere (TE MIB), so I can do this here as well. >- I wonder if it is not better to have a mplsLsrReadOnlyCompliance and > a mplsLsrFullCompliance as is also done in RFC3289 (as one of > the better examples). Specifically, something like: Sure. We did this for FTN and TE correctly, just need to do it here too. > OBJECT mplsOutSegmentRowStatus > SYNTAX INTEGER { > active(1), > notInService(2), > createAndGo(4), > destroy(6) > } > MIN-ACCESS read-only > DESCRIPTION > "The notReady(3) and createAndWait(5) states need > not be supported." > > is confusing. You do NOT use INTEGER by the way, but RowStatus. > (SMICng will complain, but that is OK). Will change to RowStatus. > If you split in two COMPLIANCEs. then for read-only you would have > > OBJECT mplsOutSegmentRowStatus > SYNTAX RowStatus { active(1) } > MIN-ACCESS read-only > DESCRIPTION "write access need not be supported." > > for Full compliance you would have > > OBJECT mplsOutSegmentRowStatus > SYNTAX RowStatus { active(1) } > WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } > DESCRIPTION > "Support for createAndWait and notInService is not required." > >- I do not understand why you need two groups: > mplsXcIsPersistentGroup and mplsXCIsNotPersistentGroup that both have > only one and the same object in it? I think we used to have some stuff in here RE: persistence, so this is an artifact. Can clean up as suggested. >- on page 43 I see: > > -- mplsInSegmentTable > > OBJECT mplsInSegmentXCIndex > DESCRIPTION > "Write access is not required." > > Well, I would then expect: > > OBJECT mplsInSegmentXCIndex > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > But the object already is MAX-ACCESS read-only. > So no need to list this object here > >- I find > OBJECT mplsInSegmentStorageType > SYNTAX INTEGER { other(1) } > DESCRIPTION > "Only other(1) needs to be supported." > REALLY REALLY strange. > Other is defined as none of the values that have a well defined > meaning. So you have no idea what this means. > Why is this? > >- OBJECT mplsOutSegmentNextHopIpAddrType > SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } > MIN-ACCESS read-only > DESCRIPTION > "An implementation is only required to support > ipv4(1) and ipv6(2)." > > The DESCRIPTION conflicts with the SYNTAX clause, does it not? > Same for > > OBJECT mplsOutSegmentNextHopIpAddr > >- mplsHCInSegmentPerfGroup OBJECT-GROUP > OBJECTS { mplsInSegmentHCOctets } > STATUS current > DESCRIPTION > "Object(s) providing performance information > specific to out-segments for which the object > mplsInterfaceInOctets wraps around too quickly." > > I guess: s/out-segments/in-segments/ > >- Why is the mplsSegemntDiscontinuityGroup a separate group? > If you have any counters that use this as a discontinutiy timer, > the they MUST also support this group, so I would say that > these object should be part of the mplsPerfGroup. > I guess this was caused by the splitting of HC counters. Yes. > Another argument to just do away with the 32-bit counter for > octets and just use 64 bit counters. This is 2002 (close to 2003), > and not 1989 anymore. Will be fixed with just 64 bit counters. >- References need to be split in normative and informative > For you current SNMP references, the split is: > > > > > > Normative Informative > > > ---------- ------------ > > > 1905 1155 > > > 1906 1157 > > > 1212 > > > 1215 > > > 2571 1901 > > > 2572 2570 > > > 2573 > > > 2574 > > > 2575 > > > 2578 > > > 2579 > > > 2580 > > > > >Oh well... a lot of these things should not show up this late in the >process... or so I feel. Certainly, but how often does one have 5 drafts to edit at the same time that are all inter-related? Anyway, I will fix. You should see some updated drafts on your door step next week. --Tom From owner-mpls@UU.NET Fri Dec 6 15:28: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 PAA23173 for ; Fri, 6 Dec 2002 15:28:51 -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 QQnsco10460 for ; Fri, 6 Dec 2002 20:31:32 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 QQnscn03549; Fri, 6 Dec 2002 20:27:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQnscn20922 for mpls-outgoing; Fri, 6 Dec 2002 20:27:11 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 QQnscn20859 for ; Fri, 6 Dec 2002 20:27:06 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 QQnscn02275 for ; Fri, 6 Dec 2002 20:26:19 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 QQnscn21376 for ; Fri, 6 Dec 2002 20:26:17 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 QQnscn21347 for ; Fri, 6 Dec 2002 20:26:16 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6KQieW028036 for ; Fri, 6 Dec 2002 15:26:45 -0500 (EST) 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 PAA27179 for ; Fri, 6 Dec 2002 15:26:15 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB6KQFd15653 for mpls@uu.net; Fri, 6 Dec 2002 15:26:15 -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 QQnscn19419 for ; Fri, 6 Dec 2002 20:24:22 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 QQnscn15103 for ; Fri, 6 Dec 2002 20:23: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 QQnscn19244 for ; Fri, 6 Dec 2002 20:23:39 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 QQnscn19231 for ; Fri, 6 Dec 2002 20:23:38 GMT Received: (qmail 21247 invoked by uid 104); 6 Dec 2002 20:23:38 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4236. . Clean. Processed in 0.725926 secs); 06 Dec 2002 20:23:38 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 6 Dec 2002 20:23:36 -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 gB6KNaQ27006; Fri, 6 Dec 2002 12:23:36 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Fri, 6 Dec 2002 12:23:36 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B5A@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Thomas D. Nadeau'" Cc: mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Fri, 6 Dec 2002 12:23:35 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > > A router SHOULD provide a mechanism to filter out > obviously invalid > > routes (such as those for net 127). > > Isn't this why the 127 addresses were used (i.e.: to > prevent mis- > routing if the MPLS header was removed)? > > --Tom RFC1812 was wrotten in 1995. I don't believe there was any MPLS at that time! -Shahram > From owner-mpls@UU.NET Fri Dec 6 15:34:47 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 PAA23369 for ; Fri, 6 Dec 2002 15:34:46 -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 QQnsco04280 for ; Fri, 6 Dec 2002 20:37: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 QQnsco01413; Fri, 6 Dec 2002 20:36:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsco24713 for mpls-outgoing; Fri, 6 Dec 2002 20:35: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 QQnsco24681 for ; Fri, 6 Dec 2002 20:35:48 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 QQnsco15824 for ; Fri, 6 Dec 2002 20:34:34 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 QQnsco00034 for ; Fri, 6 Dec 2002 20:34:33 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQnsco00030 for ; Fri, 6 Dec 2002 20:34:33 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Dec 2002 15:34:33 -0500 Message-ID: <1117F7D44159934FB116E36F4ABF221B0267ED4F@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'Thomas D. Nadeau'" Cc: mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Fri, 6 Dec 2002 15:34:32 -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 Tom, I would assume proof of the writer's position - which I think is obvious. :-) Also, you must realize that the requirement that a "router SHOULD provide a mechanism to filter out obviously invalid routes (such as those for net 127)" may technically be satisfied by a simple destination address filter. That does not mean that every router would by default be configured with such a filter, given that such a filter must consume some resources and such packets SHOULD never appear in the network in the first place. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Friday, December 06, 2002 3:08 PM > To: Shahram Davari > Cc: mpls@UU.NET > Subject: RE: Last call on LSP Ping > > > >More proof: > > Of what? > > >RFC 1812 (Requirements for IP Version 4 Routers): > > > > > > A router SHOULD NOT forward any packet that has an invalid IP > > destination address or a destination address on network 0. A router > > SHOULD NOT forward, except over a loopback interface, any packet that > > has a destination address on network 127. A router MAY have a switch > > that allows the network manager to disable these checks. If such a > > switch is provided, it MUST default to performing the checks... > > > > A router SHOULD provide a mechanism to filter out obviously invalid > > routes (such as those for net 127). > > Isn't this why the 127 addresses were used (i.e.: to prevent mis- > routing if the MPLS header was removed)? > > --Tom > > > >-Shahram > > > > > > > > > > > -----Original Message----- > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > Sent: Friday, December 06, 2002 2:43 PM > > > To: Shahram Davari > > > Cc: mpls@UU.NET > > > Subject: RE: Last call on LSP Ping > > > > > > > > > > > > >I understand the intent, but these RFCs explicitly prohibit sending > > > >127/8 addresses out of any box. It is for a node's internal use only. > > > > > > The addresses are not sent to be included in a routeable > > > packet on the wire. The processing behavior is well defined for > > > how to process the LSP Ping payload, and I agree with Curtis > > > that the address range use is perfectly valid. > > > > > > --Tom > > > > > > > > > > > > >-Shahram > > > > > > > > > -----Original Message----- > > > > > From: George Swallow [mailto:swallow@cisco.com] > > > > > Sent: Friday, December 06, 2002 12:23 PM > > > > > To: Shahram Davari > > > > > Cc: swallow@cisco.com; mpls@UU.NET; swallow@cisco.com > > > > > Subject: Re: Last call on LSP Ping > > > > > > > > > > > > > > > > RFC 3330 says: > > > > > > > > > > > > > > > > > > 127.0.0.0/8 - This block is assigned for use as the > > > Internet host > > > > > > loopback address. A datagram sent by a higher level > > > > > protocol to an > > > > > > address anywhere within this block should loop back > > > > > inside the host. > > > > > > This is ordinarily implemented using only 127.0.0.1/32 > > > > > for loopback, > > > > > > but no addresses within this block should ever appear on > > > > > any network > > > > > > anywhere [RFC1700, page 5]. > > > > > > > > > > > > And RFC1700 says: > > > > > > > > > > > > g) {127, } > > > > > > > > > > > > Internal host loopback address. Should never > > > > > appear outside > > > > > > a host. > > > > > > > > > > > > > > > > > > Doesn't this draft violate these RFCs? > > > > > > > > > > This it falls within the intent. If the label stack gets > > > completely > > > > > poped off you don't want it to go any further. That's > > > the whole point > > > > > of using that address range. I really don't see a need > > > to find a new > > > > > range. > > > > > > > > > > (Note that I'm counting the implicit null as still being > > > a label stack > > > > > - so the packet gets as far as the stack will take it and > > > no further.) > > > > > > > > > > ...George > > > > > > > > > > ================================================================== > > > > > George Swallow Cisco Systems (978) 497-8143 > > > > > 250 Apollo Drive > > > > > Chelmsford, Ma 01824 > > > > > > > > > > > From owner-mpls@UU.NET Fri Dec 6 15:42:38 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 PAA23618 for ; Fri, 6 Dec 2002 15:42:38 -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 QQnscp21307 for ; Fri, 6 Dec 2002 20:45: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 QQnsco17036; Fri, 6 Dec 2002 20:43:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsco27242 for mpls-outgoing; Fri, 6 Dec 2002 20:43: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 QQnsco27216 for ; Fri, 6 Dec 2002 20:42:53 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 QQnsco27022 for ; Fri, 6 Dec 2002 20:41:26 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 QQnsco11211 for ; Fri, 6 Dec 2002 20:40:47 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQnsco10821 for ; Fri, 6 Dec 2002 20:40:37 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Dec 2002 15:40:28 -0500 Message-ID: <1117F7D44159934FB116E36F4ABF221B0267ED50@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'George Swallow'" Cc: mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Fri, 6 Dec 2002 15:40:28 -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 George, Some routers may be hard coded to discard these packets (which raises another issue, see below). Most will route them (by default) to the bit bucket. Some (probably a very few) may have to consume filtering resources (as implied by the spirit of the RFC) in order to accomplish this. All of which is fine, unless and until you get such a packet being stripped and sent on a network containing hosts. What would a host do with the packet - crash? Which brings us to the second problem: what happens if a box is hard coded to push "localhost" packets right back at ya? Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Friday, December 06, 2002 3:02 PM > To: Shahram Davari > Cc: 'Thomas D. Nadeau'; mpls@UU.NET; swallow@cisco.com > Subject: Re: Last call on LSP Ping > > > More proof: > > > > RFC 1812 (Requirements for IP Version 4 Routers): > > > > > > A router SHOULD NOT forward any packet that has an invalid IP > > destination address or a destination address on network 0. A router > > SHOULD NOT forward, except over a loopback interface, any packet that > > has a destination address on network 127. A router MAY have a switch > > that allows the network manager to disable these checks. If such a > > switch is provided, it MUST default to performing the checks... > > > > A router SHOULD provide a mechanism to filter out obviously invalid > > routes (such as those for net 127). > > Which is exactly what we want the router that get this to do. > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 497-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 From owner-mpls@UU.NET Fri Dec 6 15:44: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 PAA23711 for ; Fri, 6 Dec 2002 15:44:51 -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 QQnscp07156 for ; Fri, 6 Dec 2002 20:47: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 QQnscp03975; Fri, 6 Dec 2002 20:46:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQnscp27617 for mpls-outgoing; Fri, 6 Dec 2002 20:45: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 QQnscp27522 for ; Fri, 6 Dec 2002 20:45:06 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 QQnsco04140 for ; Fri, 6 Dec 2002 20:44:01 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 QQnsco02318 for ; Fri, 6 Dec 2002 20:44:00 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQnsco02309 for ; Fri, 6 Dec 2002 20:44:00 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Dec 2002 15:44:00 -0500 Message-ID: <1117F7D44159934FB116E36F4ABF221B0267ED51@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'erosen@cisco.com'" , Shahram Davari Cc: "'Thomas D. Nadeau'" , mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Fri, 6 Dec 2002 15:44:00 -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 Eric (Rosen), Use of SHOULD NOT just means it is _not_ expressly forbidden. It does not in any way imply that one can do whatever one SHOULD NOT do whenever one feels the urge. :-) Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Friday, December 06, 2002 3:37 PM > To: Shahram Davari > Cc: 'Thomas D. Nadeau'; mpls@UU.NET > Subject: Re: Last call on LSP Ping > > > > RFC 1812 (Requirements for IP Version 4 Routers): > > > > A router SHOULD NOT forward any packet that has an invalid IP > > destination address or a destination address on network 0. A router > > SHOULD NOT forward, except over a loopback interface, any packet that > > has a destination address on network 127. A router MAY have a switch > > that allows the network manager to disable these checks. If such a > > switch is provided, it MUST default to performing the checks... > > > > A router SHOULD provide a mechanism to filter out obviously invalid > > routes (such as those for net 127). > > Thanks for finding this passage. I was worried that the IESG might balk > at > the proposed use of 127/8, but the above quote, by its use of "SHOULD > NOT" > rather than "MUST NOT", shows pretty clearly that the proposed use is > not > prohibited. > > From owner-mpls@UU.NET Fri Dec 6 15:48:33 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 PAA23846 for ; Fri, 6 Dec 2002 15:48:33 -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 QQnscp06280 for ; Fri, 6 Dec 2002 20:51:21 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 QQnscp24661; Fri, 6 Dec 2002 20:45:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsco27368 for mpls-outgoing; Fri, 6 Dec 2002 20:44:59 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 QQnsco27361 for ; Fri, 6 Dec 2002 20:44:52 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 QQnsco14854 for ; Fri, 6 Dec 2002 20:44:25 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 QQnsco02645 for ; Fri, 6 Dec 2002 20:44:25 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 QQnsco02641 for ; Fri, 6 Dec 2002 20:44:24 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6Kiqlw000515 for ; Fri, 6 Dec 2002 15:44:52 -0500 (EST) 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 PAA28757 for ; Fri, 6 Dec 2002 15:44:23 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB6KiNR22792 for mpls@uu.net; Fri, 6 Dec 2002 15:44:23 -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 QQnsco27207 for ; Fri, 6 Dec 2002 20:42:50 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 QQnsco28753 for ; Fri, 6 Dec 2002 20:42: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 QQnsco13836 for ; Fri, 6 Dec 2002 20:42:01 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 QQnsco13373 for ; Fri, 6 Dec 2002 20:41:47 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 PAA22370; Fri, 6 Dec 2002 15:40:29 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212062040.PAA22370@workhorse.fictitious.org> To: Shahram Davari cc: "'curtis@fictitious.org'" , swallow@cisco.com, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Fri, 06 Dec 2002 11:04:58 PST." <4B6D09F3B826D411A67300D0B706EFDEB03B58@nt-exch-yow.pmc-sierra.bc.ca> Date: Fri, 06 Dec 2002 15:40:28 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4B6D09F3B826D411A67300D0B706EFDEB03B58@nt-exch-yow.pmc-sierra.bc.ca >, Shahram Davari writes: > > > > > Therefore such a packet will get discarded at that node > > before even reaching > > > the UDP/ping layer. > > > > > > > > > -Shahram > > > > > > Try "ping -g 127.0.0.1" fron any host or router > > that supports source route ping to any host or router that doesn't > > have source routing disable. You'll get a response. > > > > Curtis > > > > Try "ping 127.0.0.1" while your Ethernet wire is disconnected from your > host. You will get a response. > > -Shahram This should clarify it for you. The sending router and responding router are not the same router. Try "ping -g 127.0.0.1" from any host or router "A" that supports source route ping to any host or router "B" that doesn't have source routing disable and has a routeable address represented as "" in the aformentioned ping command and has its loopback numbered 127.0.0.1. You'll get a response at "A" that comes from "B". In your example "A" and "B" are the same host or router. I don't see that you have any point to make but you keep responding anyway. Curtis From owner-mpls@UU.NET Fri Dec 6 15:59: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 PAA24132 for ; Fri, 6 Dec 2002 15:59:18 -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 QQnscq18735 for ; Fri, 6 Dec 2002 21:01:39 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 QQnscp14419; Fri, 6 Dec 2002 20:59:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQnscp29293 for mpls-outgoing; Fri, 6 Dec 2002 20:59:09 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 QQnscp29283 for ; Fri, 6 Dec 2002 20:59:01 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 QQnscp21044 for ; Fri, 6 Dec 2002 20:58: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 QQnscp13483 for ; Fri, 6 Dec 2002 20:58:47 GMT Received: from hoemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQnscp13475 for ; Fri, 6 Dec 2002 20:58:46 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 gB6KwjS16358 for ; Fri, 6 Dec 2002 15:58:45 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Dec 2002 21:58:44 +0100 Message-ID: From: "Wijnen, Bert (Bert)" To: "Thomas D. Nadeau" , "Wijnen, Bert (Bert)" Cc: "Mpls (E-mail)" Subject: RE: review of draft-ietf-mpls-lsr-mib-09.txt Date: Fri, 6 Dec 2002 21:58:43 +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 > >- mplsXxxxIndexNext > > We have talked about this a number of times. It still bothers me that > > you state that on every retrieval operation the agent MUST change the > > value. This sort of ENSURES that index values are non-contiguous. > > I guess that what you describe works.. but far from ideal. > > There is another one of these in the FTN MIBthat was > fixed correctly as per your and Mike's requests. This was missed I think > because it was not flagged directly; will fix as appears in the > FTN MIB currently (which is based on the DiffServ MIB's use). > Aha... so if you want to use a MPLS wide method, why not add the things you did for FTN in the MPLS TC MIB and then make them MplsIndex, MplsIndexOrZero, MplsIndexNextFree And then do as the rfc3289 does. Pls do check my comments I had on the TCs in FTN, they were close to OK but had some weird stuff in them. You can then use thse throughout all the MPLS mib modules Bert From owner-mpls@UU.NET Fri Dec 6 16:06: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 QAA24388 for ; Fri, 6 Dec 2002 16:06: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 QQnscq03944 for ; Fri, 6 Dec 2002 21:09: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 QQnscq19480; Fri, 6 Dec 2002 21:01:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQnscq03009 for mpls-outgoing; Fri, 6 Dec 2002 21:00:53 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 QQnscq02495 for ; Fri, 6 Dec 2002 21:00: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 QQnscq26330 for ; Fri, 6 Dec 2002 21:00:10 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 QQnscq18527 for ; Fri, 6 Dec 2002 21:00:09 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 QQnscq18498 for ; Fri, 6 Dec 2002 21:00:08 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6L0a7Z002452 for ; Fri, 6 Dec 2002 16:00:36 -0500 (EST) 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 QAA29985 for ; Fri, 6 Dec 2002 16:00:07 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB6L07E26371 for mpls@uu.net; Fri, 6 Dec 2002 16:00:07 -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 QQnscp29274 for ; Fri, 6 Dec 2002 20:58: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 QQnscp24768 for ; Fri, 6 Dec 2002 20:58: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 QQnscp13188 for ; Fri, 6 Dec 2002 20:58:30 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 QQnscp13174 for ; Fri, 6 Dec 2002 20:58:29 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 PAA22585; Fri, 6 Dec 2002 15:57:08 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212062057.PAA22585@workhorse.fictitious.org> To: Shahram Davari cc: "'Thomas D. Nadeau'" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Fri, 06 Dec 2002 11:50:11 PST." <4B6D09F3B826D411A67300D0B706EFDEB03B59@nt-exch-yow.pmc-sierra.bc.ca> Date: Fri, 06 Dec 2002 15:57:08 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4B6D09F3B826D411A67300D0B706EFDEB03B59@nt-exch-yow.pmc-sierra.bc.ca >, Shahram Davari writes: > More proof: > > RFC 1812 (Requirements for IP Version 4 Routers): > > > A router SHOULD NOT forward any packet that has an invalid IP > destination address or a destination address on network 0. A router > SHOULD NOT forward, except over a loopback interface, any packet that > has a destination address on network 127. A router MAY have a switch > that allows the network manager to disable these checks. If such a > switch is provided, it MUST default to performing the checks... > > A router SHOULD provide a mechanism to filter out obviously invalid > routes (such as those for net 127). > > -Shahram We are not propogating a route. If a router advertises reachability to 127/8 or any more specific route under 127/8 THE ROUTE should be rejected. A router SHOULD NOT forward, except over a loopback interface, any packet that has a destination address on network 127. This packet is tunneled to a router and then it being sent to the local loopback interface. This is exactly the case that this entry says is OK. It doesn't matter if the packet arrives in a source routed packet or arrives in an MPLS-ping packet. Further, even if you interpret this as an invalid usage, the next sentence says: A router MAY have a switch that allows the network manager to disable these checks. We clearly conform to the spirit of the RFCs describing what to do with 127/8. Any way you look at it, we also conform to the letter of this particular entry. You have no valid point to make so I'm dropping off this thread. Curtis From owner-mpls@UU.NET Fri Dec 6 16:09:08 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 QAA24433 for ; Fri, 6 Dec 2002 16:09:07 -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 QQnscq07976 for ; Fri, 6 Dec 2002 21:11: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 QQnscq21755; Fri, 6 Dec 2002 21:02:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQnscq04702 for mpls-outgoing; Fri, 6 Dec 2002 21:02: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 QQnscq04118 for ; Fri, 6 Dec 2002 21:01: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 QQnscq19551 for ; Fri, 6 Dec 2002 21:01: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 QQnscq19458 for ; Fri, 6 Dec 2002 21:01:20 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 QQnscq19432 for ; Fri, 6 Dec 2002 21:01:19 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6L1kDW002634 for ; Fri, 6 Dec 2002 16:01:47 -0500 (EST) 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 QAA00122 for ; Fri, 6 Dec 2002 16:01:17 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB6L1HH26473 for mpls@uu.net; Fri, 6 Dec 2002 16:01:17 -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 QQnscq29616 for ; Fri, 6 Dec 2002 21:00:03 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 QQnscp26186 for ; Fri, 6 Dec 2002 20:59: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 QQnscp17682 for ; Fri, 6 Dec 2002 20:59:03 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 QQnscp17670 for ; Fri, 6 Dec 2002 20:59: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 gB6KxTuI002319; Fri, 6 Dec 2002 15:59:30 -0500 (EST) Received: from tnadeau-w2k.cisco.com (che-vpn-cluster-2-87.cisco.com [10.86.242.87]) by bucket.cisco.com (Mirapoint) with ESMTP id ACF68101; Fri, 6 Dec 2002 15:58:59 -0500 (EST) Message-Id: <5.2.0.9.2.20021206155413.04636758@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 06 Dec 2002 15:58:56 -0500 To: "Gray, Eric" From: "Thomas D. Nadeau" Subject: RE: Last call on LSP Ping Cc: mpls@UU.NET In-Reply-To: <1117F7D44159934FB116E36F4ABF221B0267ED4F@celox-ma1-ems1.ce loxnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >Tom, > > I would assume proof of the writer's position - which I >think is obvious. :-) > > Also, you must realize that the requirement that a "router >SHOULD provide a mechanism to filter out obviously invalid routes >(such as those for net 127)" may technically be satisfied by a >simple destination address filter. That does not mean that every >router would by default be configured with such a filter, given >that such a filter must consume some resources and such packets >SHOULD never appear in the network in the first place. Are there really any routers out there today that anyone would spend money on that would behave in this (incorrect) way? Are we really splitting semantic hairs now? --Tom >Eric W. Gray >Systems Architect >Celox Networks, Inc. >egray@celoxnetworks.com >508 305 7214 > > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: Friday, December 06, 2002 3:08 PM > > To: Shahram Davari > > Cc: mpls@UU.NET > > Subject: RE: Last call on LSP Ping > > > > > > >More proof: > > > > Of what? > > > > >RFC 1812 (Requirements for IP Version 4 Routers): > > > > > > > > > A router SHOULD NOT forward any packet that has an invalid IP > > > destination address or a destination address on network 0. A router > > > SHOULD NOT forward, except over a loopback interface, any packet that > > > has a destination address on network 127. A router MAY have a switch > > > that allows the network manager to disable these checks. If such a > > > switch is provided, it MUST default to performing the checks... > > > > > > A router SHOULD provide a mechanism to filter out obviously invalid > > > routes (such as those for net 127). > > > > Isn't this why the 127 addresses were used (i.e.: to prevent mis- > > routing if the MPLS header was removed)? > > > > --Tom > > > > > > >-Shahram > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > > Sent: Friday, December 06, 2002 2:43 PM > > > > To: Shahram Davari > > > > Cc: mpls@UU.NET > > > > Subject: RE: Last call on LSP Ping > > > > > > > > > > > > > > > > >I understand the intent, but these RFCs explicitly prohibit sending > > > > >127/8 addresses out of any box. It is for a node's internal use only. > > > > > > > > The addresses are not sent to be included in a routeable > > > > packet on the wire. The processing behavior is well defined for > > > > how to process the LSP Ping payload, and I agree with Curtis > > > > that the address range use is perfectly valid. > > > > > > > > --Tom > > > > > > > > > > > > > > > > >-Shahram > > > > > > > > > > > -----Original Message----- > > > > > > From: George Swallow [mailto:swallow@cisco.com] > > > > > > Sent: Friday, December 06, 2002 12:23 PM > > > > > > To: Shahram Davari > > > > > > Cc: swallow@cisco.com; mpls@UU.NET; swallow@cisco.com > > > > > > Subject: Re: Last call on LSP Ping > > > > > > > > > > > > > > > > > > > RFC 3330 says: > > > > > > > > > > > > > > > > > > > > > 127.0.0.0/8 - This block is assigned for use as the > > > > Internet host > > > > > > > loopback address. A datagram sent by a higher level > > > > > > protocol to an > > > > > > > address anywhere within this block should loop back > > > > > > inside the host. > > > > > > > This is ordinarily implemented using only 127.0.0.1/32 > > > > > > for loopback, > > > > > > > but no addresses within this block should ever appear on > > > > > > any network > > > > > > > anywhere [RFC1700, page 5]. > > > > > > > > > > > > > > And RFC1700 says: > > > > > > > > > > > > > > g) {127, } > > > > > > > > > > > > > > Internal host loopback address. Should never > > > > > > appear outside > > > > > > > a host. > > > > > > > > > > > > > > > > > > > > > Doesn't this draft violate these RFCs? > > > > > > > > > > > > This it falls within the intent. If the label stack gets > > > > completely > > > > > > poped off you don't want it to go any further. That's > > > > the whole point > > > > > > of using that address range. I really don't see a need > > > > to find a new > > > > > > range. > > > > > > > > > > > > (Note that I'm counting the implicit null as still being > > > > a label stack > > > > > > - so the packet gets as far as the stack will take it and > > > > no further.) > > > > > > > > > > > > ...George > > > > > > > > > > > > ================================================================== > > > > > > George Swallow Cisco Systems (978) 497-8143 > > > > > > 250 Apollo Drive > > > > > > Chelmsford, Ma 01824 > > > > > > > > > > > > > > From owner-mpls@UU.NET Fri Dec 6 16:10:03 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 QAA24465 for ; Fri, 6 Dec 2002 16:10:03 -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 QQnscq18503 for ; Fri, 6 Dec 2002 21:12:48 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 QQnscq14087; Fri, 6 Dec 2002 21:10:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQnscq18019 for mpls-outgoing; Fri, 6 Dec 2002 21:09: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 QQnscq17987 for ; Fri, 6 Dec 2002 21:09:20 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 QQnscq10875 for ; Fri, 6 Dec 2002 21:09:15 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 QQnscq03088 for ; Fri, 6 Dec 2002 21:09:11 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 QQnscq02960 for ; Fri, 6 Dec 2002 21:09:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6L9Zmg003562 for ; Fri, 6 Dec 2002 16:09:35 -0500 (EST) 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 QAA00722 for ; Fri, 6 Dec 2002 16:09:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB6L95W28376 for mpls@uu.net; Fri, 6 Dec 2002 16:09:05 -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 QQnscq15499 for ; Fri, 6 Dec 2002 21:04: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 QQnscq27435 for ; Fri, 6 Dec 2002 21:04: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 QQnscq24257 for ; Fri, 6 Dec 2002 21:04:02 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 QQnscq23707 for ; Fri, 6 Dec 2002 21:03:43 GMT Received: (qmail 21028 invoked by uid 104); 6 Dec 2002 21:03:41 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4236. . Clean. Processed in 1.227838 secs); 06 Dec 2002 21:03:41 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 6 Dec 2002 21:03: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 gB6L3dQ20702; Fri, 6 Dec 2002 13:03:39 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Fri, 6 Dec 2002 13:03:39 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B5B@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'curtis@fictitious.org'" Cc: "'Thomas D. Nadeau'" , mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Fri, 6 Dec 2002 13:03:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Curtis, Could we add a text to the draft that says, all LSRs must be configured to not drop 127/8 addresses. Yours, -Shahram > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: Friday, December 06, 2002 3:57 PM > To: Shahram Davari > Cc: 'Thomas D. Nadeau'; mpls@UU.NET > Subject: Re: Last call on LSP Ping > > > > In message > <4B6D09F3B826D411A67300D0B706EFDEB03B59@nt-exch-yow.pmc-sierra.bc.ca > >, Shahram Davari writes: > > More proof: > > > > RFC 1812 (Requirements for IP Version 4 Routers): > > > > > > A router SHOULD NOT forward any packet that has an invalid IP > > destination address or a destination address on network > 0. A router > > SHOULD NOT forward, except over a loopback interface, > any packet that > > has a destination address on network 127. A router MAY > have a switch > > that allows the network manager to disable these checks. > If such a > > switch is provided, it MUST default to performing the checks... > > > > A router SHOULD provide a mechanism to filter out > obviously invalid > > routes (such as those for net 127). > > > > -Shahram > > > We are not propogating a route. If a router advertises reachability > to 127/8 or any more specific route under 127/8 THE ROUTE should be > rejected. > > A router SHOULD NOT forward, except over a loopback interface, any > packet that has a destination address on network 127. > > This packet is tunneled to a router and then it being sent to the > local loopback interface. This is exactly the case that this entry > says is OK. > > It doesn't matter if the packet arrives in a source routed packet or > arrives in an MPLS-ping packet. > > Further, even if you interpret this as an invalid usage, the next > sentence says: > > A router MAY have a switch that allows the network manager to > disable these checks. > > We clearly conform to the spirit of the RFCs describing what to do > with 127/8. > > Any way you look at it, we also conform to the letter of this > particular entry. > > You have no valid point to make so I'm dropping off this thread. > > Curtis > From owner-mpls@UU.NET Fri Dec 6 16:10:14 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 QAA24481 for ; Fri, 6 Dec 2002 16:10:14 -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 QQnscq04971 for ; Fri, 6 Dec 2002 21:13:00 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 QQnscq27908; Fri, 6 Dec 2002 21:08:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQnscq17823 for mpls-outgoing; Fri, 6 Dec 2002 21:08: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 QQnscq17804 for ; Fri, 6 Dec 2002 21:08:12 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 QQnscq05898 for ; Fri, 6 Dec 2002 21:07: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 QQnscq29665 for ; Fri, 6 Dec 2002 21:07:15 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 QQnscq29531 for ; Fri, 6 Dec 2002 21:07:10 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6L7biD003364 for ; Fri, 6 Dec 2002 16:07:38 -0500 (EST) 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 QAA00577 for ; Fri, 6 Dec 2002 16:07:08 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB6L78k27839 for mpls@uu.net; Fri, 6 Dec 2002 16:07:08 -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 QQnscq05905 for ; Fri, 6 Dec 2002 21:02:21 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 QQnscq02660 for ; Fri, 6 Dec 2002 21:02: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 QQnscq20468 for ; Fri, 6 Dec 2002 21:01:51 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 QQnscq20450 for ; Fri, 6 Dec 2002 21:01:51 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 gB6L2G4R002692; Fri, 6 Dec 2002 16:02:16 -0500 (EST) Received: from tnadeau-w2k.cisco.com (che-vpn-cluster-2-87.cisco.com [10.86.242.87]) by bucket.cisco.com (Mirapoint) with ESMTP id ACF68163; Fri, 6 Dec 2002 16:01:46 -0500 (EST) Message-Id: <5.2.0.9.2.20021206160130.04643578@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 06 Dec 2002 16:01:41 -0500 To: "Wijnen, Bert (Bert)" From: "Thomas D. Nadeau" Subject: RE: review of draft-ietf-mpls-lsr-mib-09.txt Cc: "Wijnen, Bert (Bert)" , "Mpls (E-mail)" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 09:58 PM 12/6/2002 +0100, Wijnen, Bert (Bert) wrote: > > >- mplsXxxxIndexNext > > > We have talked about this a number of times. It still bothers me that > > > you state that on every retrieval operation the agent MUST change the > > > value. This sort of ENSURES that index values are non-contiguous. > > > I guess that what you describe works.. but far from ideal. > > > > There is another one of these in the FTN MIBthat was > > fixed correctly as per your and Mike's requests. This was missed I think > > because it was not flagged directly; will fix as appears in the > > FTN MIB currently (which is based on the DiffServ MIB's use). > > >Aha... so if you want to use a MPLS wide method, why not add the things >you did for FTN in the MPLS TC MIB and then make them > >MplsIndex, MplsIndexOrZero, MplsIndexNextFree >And then do as the rfc3289 does. Pls do check my comments I had on the >TCs in FTN, they were close to OK but had some weird stuff in them. > >You can then use thse throughout all the MPLS mib modules Okay. Will work with Joan on this. --Tom From owner-mpls@UU.NET Fri Dec 6 16:19: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 QAA24950 for ; Fri, 6 Dec 2002 16:19:24 -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 QQnscr20632 for ; Fri, 6 Dec 2002 21:22: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 QQnscr11031; Fri, 6 Dec 2002 21:16:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQnscr20312 for mpls-outgoing; Fri, 6 Dec 2002 21:16: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 QQnscr20304 for ; Fri, 6 Dec 2002 21:16: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 QQnscr18368 for ; Fri, 6 Dec 2002 21:15:20 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 QQnscr12963 for ; Fri, 6 Dec 2002 21:15:19 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 QQnscr12945 for ; Fri, 6 Dec 2002 21:15:19 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6LFlJK004336 for ; Fri, 6 Dec 2002 16:15:47 -0500 (EST) 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 QAA01313 for ; Fri, 6 Dec 2002 16:15:17 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB6LFHw01321 for mpls@uu.net; Fri, 6 Dec 2002 16:15:17 -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 QQnscq19299 for ; Fri, 6 Dec 2002 21:13:00 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 QQnscq05602 for ; Fri, 6 Dec 2002 21:12:56 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 QQnscq04775 for ; Fri, 6 Dec 2002 21:12:54 GMT Received: from ams-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ams-msg-core-1.cisco.com [144.254.74.60]) id QQnscq04734 for ; Fri, 6 Dec 2002 21:12:52 GMT Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6LAXrD022642; Fri, 6 Dec 2002 22:10:33 +0100 (MET) Received: from MMORROW-W2K2.cisco.com (mmorrow-isdn-home.cisco.com [10.49.32.106]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id WAA15753; Fri, 6 Dec 2002 22:11:36 +0100 (MET) Message-Id: <4.3.2.7.2.20021206220507.03854bb8@amsterdam.cisco.com> X-Sender: mmorrow@amsterdam.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Dec 2002 22:11:27 +0100 To: erosen@cisco.com From: Monique Morrow Subject: Re: Last call on LSP Ping Cc: Shahram Davari , "'Thomas D. Nadeau'" , mpls@UU.NET In-Reply-To: <200212062036.gB6KahK0024250@sj-msg-core-1.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Precisely- and also agree that proposed use of 127/8 in this draft is not prohibited . /monique > > RFC 1812 (Requirements for IP Version 4 Routers): > > > > A router SHOULD NOT forward any packet that has an invalid IP > > destination address or a destination address on network 0. A router > > SHOULD NOT forward, except over a loopback interface, any packet that > > has a destination address on network 127. A router MAY have a switch > > that allows the network manager to disable these checks. If such a > > switch is provided, it MUST default to performing the checks... > > > > A router SHOULD provide a mechanism to filter out obviously invalid > > routes (such as those for net 127). > >Thanks for finding this passage. I was worried that the IESG might balk at >the proposed use of 127/8, but the above quote, by its use of "SHOULD NOT" >rather than "MUST NOT", shows pretty clearly that the proposed use is not >prohibited. From owner-mpls@UU.NET Fri Dec 6 16:31:20 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 QAA25648 for ; Fri, 6 Dec 2002 16:31:20 -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 QQnscs07114 for ; Fri, 6 Dec 2002 21:34: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 QQnscs29420; Fri, 6 Dec 2002 21:30:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQnscr21292 for mpls-outgoing; Fri, 6 Dec 2002 21:29: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 QQnscr21287 for ; Fri, 6 Dec 2002 21:29:41 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 QQnscr21029 for ; Fri, 6 Dec 2002 21:29: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 QQnscr23663 for ; Fri, 6 Dec 2002 21:29:19 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 QQnscr23654 for ; Fri, 6 Dec 2002 21:29:18 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6LThDi009743 for ; Fri, 6 Dec 2002 16:29:44 -0500 (EST) 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 QAA02401 for ; Fri, 6 Dec 2002 16:29:13 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB6LTDf11254 for mpls@uu.net; Fri, 6 Dec 2002 16:29:13 -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 QQnscr21247 for ; Fri, 6 Dec 2002 21:27:59 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 QQnscr10387 for ; Fri, 6 Dec 2002 21:25:28 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 QQnscr21001 for ; Fri, 6 Dec 2002 21:25:28 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 QQnscr20973 for ; Fri, 6 Dec 2002 21:25:26 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 QAA22798; Fri, 6 Dec 2002 16:14:00 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212062114.QAA22798@workhorse.fictitious.org> To: "Gray, Eric" cc: "'George Swallow'" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Fri, 06 Dec 2002 15:40:28 EST." <1117F7D44159934FB116E36F4ABF221B0267ED50@celox-ma1-ems1.celoxnetworks.com> Date: Fri, 06 Dec 2002 16:14:00 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <1117F7D44159934FB116E36F4ABF221B0267ED50@celox-ma1-ems1.celoxnetwor ks.com>, "Gray, Eric" writes: > George, > > Some routers may be hard coded to discard these packets > (which raises another issue, see below). Most will route them > (by default) to the bit bucket. Some (probably a very few) may > have to consume filtering resources (as implied by the spirit > of the RFC) in order to accomplish this. All of which is fine, > unless and until you get such a packet being stripped and sent > on a network containing hosts. What would a host do with the > packet - crash? Why would it crash. A UDP/IP packet to 127.0.0.1 with an unsupported port number is simply discarded and an ICMP packet is sent. Maybe the event is logged. This is IP 101 stuff. Send one to your local BSD box and see what happens. 4.1. Sending an MPLS Echo Request An MPLS echo request is a (possibly) labelled UDP packet. The IP header is set as follows: the source IP address is a routable address of the sender; the destination IP address is a (randomly chosen) address from 127/8; the IP TTL is set to 1. The source UDP port is chosen by the sender; the destination UDP port is set to 3503 (assigned by IANA for MPLS echo requests). If the echo request is labelled, the MPLS TTL on all the labels except the outermost should be set to 1. Note that if port 3503 is supported, the box supports MPLS-Ping. If there is nothing on port 3503, then the normal way to handle this is send an ICMP packet to the source (which according to the above must be routeable). Also why would IANA, the author of RFC1700, assign the UDP port for this usage if this usage violated RFC1700. Maybe a clarification from an AD could end this thread. > Which brings us to the second problem: what happens if a > box is hard coded to push "localhost" packets right back at ya? That's an imagionary box. Such a box doesn't conform to specs (forwards a packet to 127/8 to other than the loopback) and such a box doesn't exist, so why would we need to consider it. Curtis > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > > -----Original Message----- > > From: George Swallow [mailto:swallow@cisco.com] > > Sent: Friday, December 06, 2002 3:02 PM > > To: Shahram Davari > > Cc: 'Thomas D. Nadeau'; mpls@UU.NET; swallow@cisco.com > > Subject: Re: Last call on LSP Ping > > > > > More proof: > > > > > > RFC 1812 (Requirements for IP Version 4 Routers): > > > > > > > > > A router SHOULD NOT forward any packet that has an invalid IP > > > destination address or a destination address on network 0. A router > > > SHOULD NOT forward, except over a loopback interface, any packet that > > > has a destination address on network 127. A router MAY have a switch > > > that allows the network manager to disable these checks. If such a > > > switch is provided, it MUST default to performing the checks... > > > > > > A router SHOULD provide a mechanism to filter out obviously invalid > > > routes (such as those for net 127). > > > > Which is exactly what we want the router that get this to do. > > > > ...George > > > > ================================================================== > > George Swallow Cisco Systems (978) 497-8143 > > 250 Apollo Drive > > Chelmsford, Ma 01824 From owner-mpls@UU.NET Fri Dec 6 16:54:36 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 QAA26387 for ; Fri, 6 Dec 2002 16:54:35 -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 QQnsct01966 for ; Fri, 6 Dec 2002 21:57: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 QQnsct26721; Fri, 6 Dec 2002 21:54:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsct22806 for mpls-outgoing; Fri, 6 Dec 2002 21:54:09 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 QQnsct22797 for ; Fri, 6 Dec 2002 21:54: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 QQnsct26978 for ; Fri, 6 Dec 2002 21:52:33 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 QQnsct23298 for ; Fri, 6 Dec 2002 21:52:32 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 QQnsct23289 for ; Fri, 6 Dec 2002 21:52:32 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 gB6LqUS05839 for ; Fri, 6 Dec 2002 16:52:31 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Dec 2002 22:52:29 +0100 Message-ID: From: "Wijnen, Bert (Bert)" To: "Mpls (E-mail)" Subject: use of MPLS OID branch Date: Fri, 6 Dec 2002 22:52:28 +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 What I was worried about when the WG does its own administration and/or assigments of OIDs has happened. For example: mplsFTNMIB MODULE-IDENTITY ... ::= { mplsMIB 5 } mplsLdpFrameRelayMIB MODULE-IDENTITY ... ::= { mplsMIB 5 } -- to be assigned This is not good... Pls check them all and correct. And what are we going to do to make sure we do not assign an overlap in the future and running the risk that it gets published as RFC ?? Thanks, Bert From owner-mpls@UU.NET Fri Dec 6 17:05:29 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 RAA26958 for ; Fri, 6 Dec 2002 17:05:29 -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 QQnscu24672 for ; Fri, 6 Dec 2002 22:08: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 QQnscu19050; Fri, 6 Dec 2002 22:04:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQnscu03938 for mpls-outgoing; Fri, 6 Dec 2002 22:04:29 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 QQnscu03906 for ; Fri, 6 Dec 2002 22:04: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 QQnscu28363 for ; Fri, 6 Dec 2002 22:03: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 QQnscu17964 for ; Fri, 6 Dec 2002 22:03:08 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 QQnscu17956 for ; Fri, 6 Dec 2002 22:03:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6M3ZtT016471 for ; Fri, 6 Dec 2002 17:03:36 -0500 (EST) 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 RAA05018 for ; Fri, 6 Dec 2002 17:03:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB6M36p16257 for mpls@uu.net; Fri, 6 Dec 2002 17:03:06 -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 QQnscu29062 for ; Fri, 6 Dec 2002 22:01:35 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 QQnscu24051 for ; Fri, 6 Dec 2002 22:00: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 QQnscu15681 for ; Fri, 6 Dec 2002 22:00:06 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 QQnscu15666 for ; Fri, 6 Dec 2002 22:00:06 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 gB6M0KWC016061; Fri, 6 Dec 2002 17:00:20 -0500 (EST) Received: from tnadeau-w2k.cisco.com (che-vpn-cluster-2-87.cisco.com [10.86.242.87]) by bucket.cisco.com (Mirapoint) with ESMTP id ACF69462; Fri, 6 Dec 2002 16:59:50 -0500 (EST) Message-Id: <5.2.0.9.2.20021206165536.046cbd40@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 06 Dec 2002 16:59:48 -0500 To: "Wijnen, Bert (Bert)" From: "Thomas D. Nadeau" Subject: Re: use of MPLS OID branch Cc: "Mpls (E-mail)" , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 10:52 PM 12/6/2002 +0100, Wijnen, Bert (Bert) wrote: >What I was worried about when the WG does its own administration >and/or assigments of OIDs has happened. > >For example: > > mplsFTNMIB MODULE-IDENTITY > ... > ::= { mplsMIB 5 } > > mplsLdpFrameRelayMIB MODULE-IDENTITY > ... > ::= { mplsMIB 5 } -- to be assigned Propose we use: mplsMIB.1 - MPLS-TC mplsMIB.2 - MPLS-LSR mplsMIB.3 - MPLS-TE mplsMIB.4 - MPLS-FTN mplsMIB.5 - MPLS-LDP mplsMIB.6 - MPLS-LDP-GENERIC mplsMIB.6 - MPLS-LDP-ATM mplsMIB.7 - MPLS-LDP-FRAME-RELAY >This is not good... Pls check them all and correct. >And what are we going to do to make sure we do not assign >an overlap in the future and running the risk that it gets >published as RFC ?? I thought that IANA would manage the mplsMIB space, no? --Tom From owner-mpls@UU.NET Fri Dec 6 17:06:56 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 RAA27039 for ; Fri, 6 Dec 2002 17:06:56 -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 QQnscu06764 for ; Fri, 6 Dec 2002 22:09: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 QQnscu03022; Fri, 6 Dec 2002 22:07:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQnscu10832 for mpls-outgoing; Fri, 6 Dec 2002 22:06: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 QQnscu10773 for ; Fri, 6 Dec 2002 22:06: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 QQnscu11919 for ; Fri, 6 Dec 2002 22:05: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 QQnscu19383 for ; Fri, 6 Dec 2002 22:05:09 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 QQnscu19355 for ; Fri, 6 Dec 2002 22:05:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6M5ZLt016778 for ; Fri, 6 Dec 2002 17:05:35 -0500 (EST) 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 RAA05156 for ; Fri, 6 Dec 2002 17:05:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB6M56116438 for mpls@uu.net; Fri, 6 Dec 2002 17:05:06 -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 QQnscu03304 for ; Fri, 6 Dec 2002 22:03:54 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 QQnscu23434 for ; Fri, 6 Dec 2002 22:03:30 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 QQnscu18233 for ; Fri, 6 Dec 2002 22:03:29 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 QQnscu18209 for ; Fri, 6 Dec 2002 22:03:28 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 RAA23239; Fri, 6 Dec 2002 17:02:10 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212062202.RAA23239@workhorse.fictitious.org> To: Shahram Davari cc: "'curtis@fictitious.org'" , "'Thomas D. Nadeau'" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Fri, 06 Dec 2002 13:03:36 PST." <4B6D09F3B826D411A67300D0B706EFDEB03B5B@nt-exch-yow.pmc-sierra.bc.ca> Date: Fri, 06 Dec 2002 17:02:10 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4B6D09F3B826D411A67300D0B706EFDEB03B5B@nt-exch-yow.pmc-sierra.bc.ca >, Shahram Davari writes: > Curtis, > > Could we add a text to the draft that says, all LSRs must be configured to no > t drop 127/8 addresses. > > Yours, > -Shahram We don't need to add anything because it is not suggested that you should drop in RFC1812. You should do exactly the same thing that you would do after processing the source route IP option, deliver the packet to the local loopback interface. Maybe one of the authors can join (do they really want to?) and say whether they would see fit to add a sentence or deem it too obvious. Curtis > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > Sent: Friday, December 06, 2002 3:57 PM > > To: Shahram Davari > > Cc: 'Thomas D. Nadeau'; mpls@UU.NET > > Subject: Re: Last call on LSP Ping > > > > > > > > In message > > <4B6D09F3B826D411A67300D0B706EFDEB03B59@nt-exch-yow.pmc-sierra.bc.ca > > >, Shahram Davari writes: > > > More proof: > > > > > > RFC 1812 (Requirements for IP Version 4 Routers): > > > > > > > > > A router SHOULD NOT forward any packet that has an invalid IP > > > destination address or a destination address on network > > 0. A router > > > SHOULD NOT forward, except over a loopback interface, > > any packet that > > > has a destination address on network 127. A router MAY > > have a switch > > > that allows the network manager to disable these checks. > > If such a > > > switch is provided, it MUST default to performing the checks... > > > > > > A router SHOULD provide a mechanism to filter out > > obviously invalid > > > routes (such as those for net 127). > > > > > > -Shahram > > > > > > We are not propogating a route. If a router advertises reachability > > to 127/8 or any more specific route under 127/8 THE ROUTE should be > > rejected. > > > > A router SHOULD NOT forward, except over a loopback interface, any > > packet that has a destination address on network 127. > > > > This packet is tunneled to a router and then it being sent to the > > local loopback interface. This is exactly the case that this entry > > says is OK. > > > > It doesn't matter if the packet arrives in a source routed packet or > > arrives in an MPLS-ping packet. > > > > Further, even if you interpret this as an invalid usage, the next > > sentence says: > > > > A router MAY have a switch that allows the network manager to > > disable these checks. > > > > We clearly conform to the spirit of the RFCs describing what to do > > with 127/8. > > > > Any way you look at it, we also conform to the letter of this > > particular entry. > > > > You have no valid point to make so I'm dropping off this thread. > > > > Curtis > > > From owner-mpls@UU.NET Fri Dec 6 17:19: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 RAA27370 for ; Fri, 6 Dec 2002 17:19:54 -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 QQnscv10672 for ; Fri, 6 Dec 2002 22:22:43 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 QQnscv08276; Fri, 6 Dec 2002 22:21:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQnscv13394 for mpls-outgoing; Fri, 6 Dec 2002 22:21: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 QQnscv13386 for ; Fri, 6 Dec 2002 22:20:50 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 QQnscv17359 for ; Fri, 6 Dec 2002 22:20: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 QQnscv07788 for ; Fri, 6 Dec 2002 22:20:41 GMT Received: from hoemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQnscv07779 for ; Fri, 6 Dec 2002 22:20:40 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 gB6MKcS17496 for ; Fri, 6 Dec 2002 17:20:38 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Dec 2002 23:20:37 +0100 Message-ID: From: "Wijnen, Bert (Bert)" To: "Thomas D. Nadeau" Cc: "Mpls (E-mail)" , jcucchiara@mindspring.com Subject: RE: use of MPLS OID branch Date: Fri, 6 Dec 2002 23:20:36 +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 > At 10:52 PM 12/6/2002 +0100, Wijnen, Bert (Bert) wrote: > >What I was worried about when the WG does its own administration > >and/or assigments of OIDs has happened. > > > >For example: > > > > mplsFTNMIB MODULE-IDENTITY > > ... > > ::= { mplsMIB 5 } > > > > mplsLdpFrameRelayMIB MODULE-IDENTITY > > ... > > ::= { mplsMIB 5 } -- to be assigned > > Propose we use: > > mplsMIB.1 - MPLS-TC > mplsMIB.2 - MPLS-LSR > mplsMIB.3 - MPLS-TE > mplsMIB.4 - MPLS-FTN > mplsMIB.5 - MPLS-LDP > mplsMIB.6 - MPLS-LDP-GENERIC > mplsMIB.6 - MPLS-LDP-ATM > mplsMIB.7 - MPLS-LDP-FRAME-RELAY > Seems fine > >This is not good... Pls check them all and correct. > >And what are we going to do to make sure we do not assign > >an overlap in the future and running the risk that it gets > >published as RFC ?? > > I thought that IANA would manage the mplsMIB space, > no? > Well, if that is what you want (and that is fine with me) then you need to do 2 things: - In the MPLS-TC-MIB document you must add an IANA Considerations section in which you explain the new OID tree for mplsMib and in whcih you explain the rules/guidelines for IANA on how to decide on new assignments. It is a new namespace for IANA to maintain - In all the MIB Modules you have, use ::= { mplsMib xx } -- xx to be assigned by IANA and add an IANA Considerations Section where you ask IANA to assign the value. You can suggest to assign the value as per your list above. Now that we are on that topic, the things that MPLS-LDP-MIB document imports OID branches in the GENERIC, ATM and FRAME_RELAY MIB Modules from the LLLLDP-MIB module and then starts assigning underneath them, that worries me in a similar manner. The assigments all happen in different MIB mdoules (which can later move into separate documents if they do not progress on stds track at same speed), and then things may get out of sync. Bert > --Tom > > From owner-mpls@UU.NET Fri Dec 6 17:33: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 RAA28025 for ; Fri, 6 Dec 2002 17:33: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 QQnscw28543 for ; Fri, 6 Dec 2002 22:36: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 QQnscw20272; Fri, 6 Dec 2002 22:31:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQnscw14038 for mpls-outgoing; Fri, 6 Dec 2002 22:30: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 QQnscw13975 for ; Fri, 6 Dec 2002 22:30:30 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 QQnscw13341 for ; Fri, 6 Dec 2002 22:30: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 QQnscw19259 for ; Fri, 6 Dec 2002 22:30:07 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 QQnscw19252 for ; Fri, 6 Dec 2002 22:30:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6MUZNB019434 for ; Fri, 6 Dec 2002 17:30:35 -0500 (EST) 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 RAA06767 for ; Fri, 6 Dec 2002 17:30:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB6MU6f22416 for mpls@uu.net; Fri, 6 Dec 2002 17:30:06 -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 QQnscv13856 for ; Fri, 6 Dec 2002 22:28:30 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 QQnscv26209 for ; Fri, 6 Dec 2002 22:27: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 QQnscv16896 for ; Fri, 6 Dec 2002 22:26:59 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 QQnscv16883 for ; Fri, 6 Dec 2002 22:26:59 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 gB6MRKgK019075; Fri, 6 Dec 2002 17:27:20 -0500 (EST) Received: from tnadeau-w2k.cisco.com (che-vpn-cluster-2-87.cisco.com [10.86.242.87]) by bucket.cisco.com (Mirapoint) with ESMTP id ACF69920; Fri, 6 Dec 2002 17:26:50 -0500 (EST) Message-Id: <5.2.0.9.2.20021206172602.0475fb90@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 06 Dec 2002 17:26:48 -0500 To: "Wijnen, Bert (Bert)" From: "Thomas D. Nadeau" Subject: RE: use of MPLS OID branch Cc: "Mpls (E-mail)" , jcucchiara@mindspring.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 11:20 PM 12/6/2002 +0100, Wijnen, Bert (Bert) wrote: > > At 10:52 PM 12/6/2002 +0100, Wijnen, Bert (Bert) wrote: > > >What I was worried about when the WG does its own administration > > >and/or assigments of OIDs has happened. > > > > > >For example: > > > > > > mplsFTNMIB MODULE-IDENTITY > > > ... > > > ::= { mplsMIB 5 } > > > > > > mplsLdpFrameRelayMIB MODULE-IDENTITY > > > ... > > > ::= { mplsMIB 5 } -- to be assigned > > > > Propose we use: > > > > mplsMIB.1 - MPLS-TC > > mplsMIB.2 - MPLS-LSR > > mplsMIB.3 - MPLS-TE > > mplsMIB.4 - MPLS-FTN > > mplsMIB.5 - MPLS-LDP > > mplsMIB.6 - MPLS-LDP-GENERIC > > mplsMIB.6 - MPLS-LDP-ATM > > mplsMIB.7 - MPLS-LDP-FRAME-RELAY > > >Seems fine > > > >This is not good... Pls check them all and correct. > > >And what are we going to do to make sure we do not assign > > >an overlap in the future and running the risk that it gets > > >published as RFC ?? > > > > I thought that IANA would manage the mplsMIB space, > > no? > > >Well, if that is what you want (and that is fine with me) then >you need to do 2 things: > >- In the MPLS-TC-MIB document you must add an IANA Considerations > section in which you explain the new OID tree for mplsMib > and in whcih you explain the rules/guidelines for IANA on > how to decide on new assignments. It is a new namespace > for IANA to maintain > >- In all the MIB Modules you have, use > > ::= { mplsMib xx } -- xx to be assigned by IANA > > and add an IANA Considerations Section where you ask IANA to > assign the value. You can suggest to assign the value as per > your list above. Cool. >Now that we are on that topic, the things that MPLS-LDP-MIB document >imports OID branches in the GENERIC, ATM and FRAME_RELAY MIB Modules >from the LLLLDP-MIB module and then starts assigning underneath them, >that worries me in a similar manner. The assigments all happen in >different MIB mdoules (which can later move into separate documents >if they do not progress on stds track at same speed), and then >things may get out of sync. I will let Joan respond to this. --Tom >Bert > > --Tom > > > > From owner-mpls@UU.NET Fri Dec 6 17:46:43 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 RAA28559 for ; Fri, 6 Dec 2002 17:46:43 -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 QQnscx29592 for ; Fri, 6 Dec 2002 22:49:32 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 QQnscx20736; Fri, 6 Dec 2002 22:45:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQnscw15428 for mpls-outgoing; Fri, 6 Dec 2002 22:44:39 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 QQnscw15415 for ; Fri, 6 Dec 2002 22:44: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 QQnscw26626 for ; Fri, 6 Dec 2002 22:44:30 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 QQnscw08612 for ; Fri, 6 Dec 2002 22:44:30 GMT Received: from ihemail2.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQnscw08608 for ; Fri, 6 Dec 2002 22:44:29 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 gB6MiSi07241 for ; Fri, 6 Dec 2002 17:44:28 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Dec 2002 23:44:27 +0100 Message-ID: From: "Wijnen, Bert (Bert)" To: "Mpls (E-mail)" Subject: review of draft-ietf-mpls-ldp-mib-09.txt Date: Fri, 6 Dec 2002 23:44:26 +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 Here we go (mix of nits and some serious) - missing IPR section - Security considerations probably needs more work Security ADs want you to explain what the vulnerabilities/risks are and what to do against them. Also for read only objects, pls list each (group of) object(s) and explain what sensitivity attributes they have - pls do the consistency checking for descriptors and all that - sect 3.5 1st sentence s/would be/are/ ?? - sect 3.5 2nd para first sentence s/initiation/initiate/ - section 3.5.2 s/mpsl/mpls/ - mplsXxxIndexNext See my comments on FTN MIB and LSR MIB on these type of objects Best to use something aka rfc3289 - RowStatus and StorageType objects see my comments about similar objects in LSR MIB for StorageType might also want to add a DEFVAL - mplsLdpNotifications ... { mplsLdpMib 2 } why not { mplsLdpMib 0} so that it is right away the prefix? I believe LSR MIB does it that way now. You may want to do it consistently for all notifications. I can live with either way, but prefer them to be shorter OIDs. - mplsXxxLastChange does that time stamp only get changed if an addition/deletion takes place? Not if something gets changed via a SNMP SET command? I think I'd prefer to also see changes (modifications) via SET. But in any event, be very explicit about if those are included or not. - mplsLdpLspType All that stuff in the DESCRIPTION clause is just a repeat of the TC DESCRIPTION clause. Seems not needed to me. What if a value gets added later... how do you stay in sync? - mplsFecAddrLength Should that be of SYNTAX InetAddressPrefixLength as per RFC3291? - mplsFecAddrFamily and mplsFecAddr These are strange. The DESCRIPTIONS are certainly not meeting the requirements as specified in RFC3291. At other places you do it correct, so you do understand what is required I think - mplsLdpLspFecTable claims to be a read-only table. Yet you have a read-create RowStatus object in it. - mplsLdpSessionUp and mplsLdpSessionDown Is it not better to just have one notification, namely a mplsLdpSessionStateChange and then the mplsLdpSesState object will explain what the change is? - COMPLIANCE section. I hope that INT ADs are OK with making IPv6 addresses optional. Is that cause current LDP only supports IPv4? If so you may want to add that as an explanation. MPLS-LDP-GENERIC-MIB - same on mplsXXXIndexNext and RowStatus and STorageType objects - this looks wierd: ::= { mplsMib 6 } -- to be assigned use cc instead of 6 if you want IANA to assign, and do tell -- to be assigned by IANA and write something about it in an IANA Considerations Section if this is what you want. - mplsGenModuleROCompliance I would call it mplsGenModuleReadOnlyCompliance You have used ReadOnly and Full in other places/mib modules and it is good to be clear and consistent MPLS-LDP-ATM-MIB - s/Moduel/Module/ - same on mplsXXXIndexNext and RowStatus and STorageType objects - this looks wierd: ::= { mplsMib 4 } -- to be assigned use cc instead of 4 if you want IANA to assign, and do tell -- to be assigned by IANA and write something about it in an IANA Considerations Section if this is what you want. - See earlier remark on Notifications (use zero instead of 2 right away) - There are still some INTEGER enumerations that start with zero It is not a BLOCKING problem... but if acceptable, pls make it start at 1 (as you have done vor various others of these enumerations) - mplsXxxxROCompliance -> better mplsXxxxReadOnlyCompliance - some formatting problems with DEFVAL lines being split on 2 lines? MPLS-LDP_FRAME-RELAY-MIB - consistency in descriptors (FrameRelay vs FR etc) - same on mplsXXXIndexNext and RowStatus and STorageType objects - this looks wierd: ::= { mplsMib 5 } -- to be assigned use cc instead of 5 if you want IANA to assign, and do tell -- to be assigned by IANA and write something about it in an IANA Considerations Section if this is what you want. - See earlier remark on Notifications (use zero instead of 2 right away) - There are still some INTEGER enumerations that start with zero It is not a BLOCKING problem... but if acceptable, pls make it start at 1 (as you have done vor various others of these enumerations) - mplsLdpEntityFrLRComponents OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "Number of LabelRange Components in the Initialization message. This also represents the number of entries in the mplsLdpEntityConfFrLRTable which correspond to this entry." Where is this mplsLdpEntityConfFrLRTable ?? - I see the xxxDlci index objects start at zero. Pls add to DESCRIPTION clauses why zero must be an index. - mplsXxxxROCompliance -> better mplsXxxxReadOnlyCompliance Thanks, Bert From owner-mpls@UU.NET Fri Dec 6 18:36: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 SAA00536 for ; Fri, 6 Dec 2002 18:36: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 QQnsda16308 for ; Fri, 6 Dec 2002 23:39:16 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 QQnsda10400; Fri, 6 Dec 2002 23:36:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsda07078 for mpls-outgoing; Fri, 6 Dec 2002 23:35:59 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 QQnsda07071 for ; Fri, 6 Dec 2002 23:35:40 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 QQnsda08884 for ; Fri, 6 Dec 2002 23:35:24 GMT From: jcucchiara@mindspring.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 QQnsda09194 for ; Fri, 6 Dec 2002 23:35:24 GMT Received: from johnson.mail.mindspring.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: johnson.mail.mindspring.net [207.69.200.177]) id QQnsda09186 for ; Fri, 6 Dec 2002 23:35:24 GMT Received: from smui07.slb.mindspring.net ([199.174.114.17]) by johnson.mail.mindspring.net with esmtp (Exim 3.33 #1) id 18KS0C-0006QB-00; Fri, 06 Dec 2002 18:35:24 -0500 Received: by smui07.slb.mindspring.net id SAA0000017203; Fri, 6 Dec 2002 18:33:49 -0500 (EST) Date: Fri, 06 Dec 2002 18:33:49 -0500 To: "Thomas D. Nadeau" Cc: "Wijnen, Bert (Bert)" , "Mpls (E-mail)" , jcucchiara@mindspring.com Reply-To: jcucchiara@mindspring.com Subject: RE: use of MPLS OID branch Message-ID: X-Originating-IP: 65.89.226.30 Sender: owner-mpls@UU.NET Precedence: bulk On Fri, 06 Dec 2002 17:26:48 -0500 "Thomas D. Nadeau" wrote: > At 11:20 PM 12/6/2002 +0100, Wijnen, Bert > (Bert) wrote: > > > At 10:52 PM 12/6/2002 +0100, Wijnen, Bert > (Bert) wrote: > > > >What I was worried about when the WG does > its own administration > > > >and/or assigments of OIDs has happened. > > > > > > > >For example: > > > > > > > > mplsFTNMIB MODULE-IDENTITY > > > > ... > > > > ::= { mplsMIB 5 } > > > > > > > > mplsLdpFrameRelayMIB MODULE-IDENTITY > > > > ... > > > > ::= { mplsMIB 5 } -- to be assigned > > > > > > Propose we use: > > > > > > mplsMIB.1 - MPLS-TC > > > mplsMIB.2 - MPLS-LSR > > > mplsMIB.3 - MPLS-TE > > > mplsMIB.4 - MPLS-FTN > > > mplsMIB.5 - MPLS-LDP > > > mplsMIB.6 - MPLS-LDP-GENERIC > > > mplsMIB.6 - MPLS-LDP-ATM > > > mplsMIB.7 - MPLS-LDP-FRAME-RELAY > > > > >Seems fine > > > > > >This is not good... Pls check them all and > correct. > > > >And what are we going to do to make sure > we do not assign > > > >an overlap in the future and running the > risk that it gets > > > >published as RFC ?? > > > > > > I thought that IANA would manage > the mplsMIB space, > > > no? > > > > >Well, if that is what you want (and that is > fine with me) then > >you need to do 2 things: > > > >- In the MPLS-TC-MIB document you must add an > IANA Considerations > > section in which you explain the new OID > tree for mplsMib > > and in whcih you explain the > rules/guidelines for IANA on > > how to decide on new assignments. It is a > new namespace > > for IANA to maintain > > > >- In all the MIB Modules you have, use > > > > ::= { mplsMib xx } -- xx to be assigned > by IANA > > > > and add an IANA Considerations Section > where you ask IANA to > > assign the value. You can suggest to assign > the value as per > > your list above. > > Cool. > > >Now that we are on that topic, the things that > MPLS-LDP-MIB document > >imports OID branches in the GENERIC, ATM and > FRAME_RELAY MIB Modules > >from the LLLLDP-MIB module and then starts > assigning underneath them, > >that worries me in a similar manner. The > assigments all happen in > >different MIB mdoules (which can later move > into separate documents > >if they do not progress on stds track at same > speed), and then > >things may get out of sync. > > I will let Joan respond to this. The Generic, ATM and FrameRelay MIB modules IMPORT from the MPLS-TC-MIB for the mplsMIB number (and IMPORT from the MPLS-LDP-MIB for some objects), so would agree that the LDP-MIB document needs to have IANA Consideration Section which asks IANA for mplsMIB number assignments. IF these MIB Modules move to different documents (as Bert suggests above could happen) then would think that these new docs would need an IANA Considerations Section also, right? Would this be a reasonable solution? Thanks, -Joan > > --Tom > > > > >Bert > > > --Tom > > > > > > > > > From owner-mpls@UU.NET Fri Dec 6 18:50: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 SAA01215 for ; Fri, 6 Dec 2002 18:50:11 -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 QQnsdb07367 for ; Fri, 6 Dec 2002 23:53: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 QQnsdb01944; Fri, 6 Dec 2002 23:50:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsdb07952 for mpls-outgoing; Fri, 6 Dec 2002 23:49: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 QQnsdb07939 for ; Fri, 6 Dec 2002 23:49:46 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 QQnsdb29253 for ; Fri, 6 Dec 2002 23:49: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 QQnsdb28600 for ; Fri, 6 Dec 2002 23:49:39 GMT Received: from hoemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQnsdb28592 for ; Fri, 6 Dec 2002 23:49:38 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 gB6Nna112158 for ; Fri, 6 Dec 2002 18:49:37 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Sat, 7 Dec 2002 00:49:36 +0100 Message-ID: From: "Wijnen, Bert (Bert)" To: jcucchiara@mindspring.com, "Thomas D. Nadeau" Cc: "Mpls (E-mail)" Subject: RE: use of MPLS OID branch Date: Sat, 7 Dec 2002 00:49:34 +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 > > >Now that we are on that topic, the things that MPLS-LDP-MIB document > > >imports OID branches in the GENERIC, ATM and FRAME_RELAY MIB Modules > > >from the LLLLDP-MIB module and then starts assigning underneath them, > > >that worries me in a similar manner. The assigments all happen in > > >different MIB mdoules (which can later move into separate documents > > >if they do not progress on stds track at same speed), and then > > >things may get out of sync. > > > > I will let Joan respond to this. > > The Generic, ATM and FrameRelay MIB modules > IMPORT from the MPLS-TC-MIB for the mplsMIB > number (and IMPORT from the MPLS-LDP-MIB for > some objects), so would agree that the > LDP-MIB document needs to have IANA Consideration Section > which asks IANA for mplsMIB number assignments. > Good. > IF these MIB Modules move to different > documents (as Bert suggests above could > happen) then would think that these new > docs would need an IANA Considerations > Section also, right? > Yeah.... but if that is what you want to do you might as well start right away... I am not sure, I jave seen RMON WG maintain their stuff pretty well and they do their own assignments too. I think I only caught them once where they had an overlap. But in case of LDP, you start to import from various branches in the OID tree... and so maintaining a list of which subtrees have been used and which are still avialable gets more difficult For exmample - mpls-ldp-atm-mib imports: mplsLdpEntityObjects, mplsLdpSessionObjects, ... FROM MPLS-LDP-MIB And then assigns branches underneath those: mplsLdpEntityAtmObjects OBJECT IDENTIFIER ::= { mplsLdpEntityObjects 6 } And that is still kind of easy to locate. But then you have: mplsLdpAtmSesTable OBJECT-TYPE ... ::= { mplsLdpSessionObjects 10 } So it does not look very consistent does it? And then GENERIC and FRAME-RELAY mib modules do similar things I think. How do you keep track? Bert > Would this be a reasonable solution? > > Thanks, > -Joan > > > > > > > > --Tom > > > > > > > > >Bert > > > > --Tom > > > > > > > > > > > > > > > From owner-mpls@UU.NET Fri Dec 6 19:35:00 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 TAA03088 for ; Fri, 6 Dec 2002 19:34:59 -0500 (EST) 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 QQnsco05370; Fri, 6 Dec 2002 20:38:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsco25405 for mpls-outgoing; Fri, 6 Dec 2002 20:37:12 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 QQnsco25272 for ; Fri, 6 Dec 2002 20:37:02 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 QQnsco04464 for ; Fri, 6 Dec 2002 20:36:48 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 QQnsco27693 for ; Fri, 6 Dec 2002 20:36:48 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 QQnsco27685 for ; Fri, 6 Dec 2002 20:36:47 GMT Received: from cisco.com (erosen-u10.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6KahK0024250; Fri, 6 Dec 2002 12:36:43 -0800 (PST) Message-Id: <200212062036.gB6KahK0024250@sj-msg-core-1.cisco.com> To: Shahram Davari cc: "'Thomas D. Nadeau'" , mpls@UU.NET Subject: Re: Last call on LSP Ping In-reply-to: Your message of Fri, 06 Dec 2002 11:50:11 -0800. <4B6D09F3B826D411A67300D0B706EFDEB03B59@nt-exch-yow.pmc-sierra.bc.ca> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Fri, 06 Dec 2002 15:36:43 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk > RFC 1812 (Requirements for IP Version 4 Routers): > A router SHOULD NOT forward any packet that has an invalid IP > destination address or a destination address on network 0. A router > SHOULD NOT forward, except over a loopback interface, any packet that > has a destination address on network 127. A router MAY have a switch > that allows the network manager to disable these checks. If such a > switch is provided, it MUST default to performing the checks... > > A router SHOULD provide a mechanism to filter out obviously invalid > routes (such as those for net 127). Thanks for finding this passage. I was worried that the IESG might balk at the proposed use of 127/8, but the above quote, by its use of "SHOULD NOT" rather than "MUST NOT", shows pretty clearly that the proposed use is not prohibited. From owner-mpls@UU.NET Fri Dec 6 22:08:47 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 WAA06683 for ; Fri, 6 Dec 2002 22:08: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 QQnsdo10560 for ; Sat, 7 Dec 2002 03:11:28 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 QQnsdo04952; Sat, 7 Dec 2002 03:08:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsdo04969 for mpls-outgoing; Sat, 7 Dec 2002 03:08: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 QQnsdo04926 for ; Sat, 7 Dec 2002 03:07:51 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 QQnsdo07077 for ; Sat, 7 Dec 2002 03:05:38 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 QQnsdo19846 for ; Sat, 7 Dec 2002 03:05:37 GMT Received: from mail.cad.zju.edu.cn by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: cad.zju.edu.cn [210.32.131.2]) id QQnsdo19825 for ; Sat, 7 Dec 2002 03:05:33 GMT Received: (qmail 15906 invoked from network); 7 Dec 2002 03:11:31 -0000 Received: from unknown (HELO ultra1) (210.32.131.97) by 210.32.131.2 with SMTP; 7 Dec 2002 03:11:31 -0000 Received: from cad.zju.edu.cn (ultra1 [210.32.131.97]) by ultra1 (8.12.6/8.12.6) with ESMTP id gB7362p1013725; Sat, 7 Dec 2002 11:06:03 +0800 (CST) Message-ID: <3DF1659A.978EE288@cad.zju.edu.cn> Date: Sat, 07 Dec 2002 11:06:02 +0800 From: Jing Shen Reply-To: jshen@cad.zju.edu.cn Organization: State Key Lab of CAD&CG X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Eric Osborne CC: "J.C.Ramesh Babu" , mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: [MPLS-OPS]: Jitter and MPLS References: <085301c29d34$503954f0$a4c7fe87@ad.infosys.com> <20021206110156.O28607@eosborne-u10.cisco.com> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Although Eric's idea is taken by many people , our experiements shows this is not the truth at least with the situation of our testbed. In fact we set up a small testbed consisting a Linux based MPLS engine. In order to focus on difference between forwarding performance difference between MPLS and IP, we use CBR traffic with static routing table. The testbed is consist of 3 hops of MPLS(IP) forwarder between source and destination. The experiments shows that: If the hardware and software system is kept at the same level, then: 1) TCP throughput of MPLS is a little smaller than IP when path MTU is the same. and difference increases when path MTU decreases. 2) For UDP traffic, a) when best-effort policy is applied, if link along the path is lightly loaded (below 30%) e2e performance difference IP and MPLS is nearly the same while the IPDV of MPLS is smaller than IP forwarding; if the link along the path is heavily loaded, QoS of MPLS is worse than IP forwarding. the same result is applied to loss rate. b) when resource reservation is applied, both method could guarantee the e2e delay but MPLS shows better IPDV value with a little longer e2e delay. We found the reason for this phenomenon is the encapsulation/decapsulation procedure of MPLS, and the processing of MPLS forwarding. Although we have not experimented with Cisco's express forwarding and the like, and we do not experiment with large scale system with real internet traffic pattern, we concern that the result could applied to large scale network. The reason is, 1) a small testbed could be considered as a emulation of tunnel through large network , and some of large network use LER-to-LER LSP; 2) we focus on forwarding difference between IP and MPLS, and we think technique like CEF and per-port cache could be applied to both technologies. 3) the same queueing mechanism is applied to both technologies in our experiments. 4) comparison should be taken at the same level of cost. The paper on this experiment will be published on Communication Journal ( Chinese) this month. any comment will be highly appreciated. regards > > No, not really. MPLS lets you apply QoS using EXP bits, just like you > can with IP Precedence; any mechanisms you can use with IP Precedence > to reduce jitter (various queing schemes) are equally applicable with > MPLS. Using MPLS-TE can make you more likely to avoid congestion and > therefore less likely to experience delay and jitter, but from a > queueing perspective it's the same with MPLS and with IP routing. > > eric > > > Please let me know > > > > Thanks > > > > J.C.Ramesh Babu > > Technical Specialist. > > Communications and Products Division > > Infosys Technologies Limited > > Electronic City, > > Hosur Road, > > Bangalore. > > > > Ph # > > Off : 91-80-4166472 > > Res: 91-80-6592375 > > ------- > The MPLS-OPS Mailing List > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml -- Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, Z.J. 310027 P.R.China Tel: +86-571-87932423 Mobile: (0)13516813753 Email: jshen@cad.zju.edu.cn ********************************************************************** * The SunShine of life is made up of very little beams which is * * bright all the time * ********************************************************************** From owner-mpls@UU.NET Fri Dec 6 23:39:00 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 XAA08649 for ; Fri, 6 Dec 2002 23:39:00 -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 QQnsdu02620 for ; Sat, 7 Dec 2002 04: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 QQnsdu00671; Sat, 7 Dec 2002 04:40:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsdu00969 for mpls-outgoing; Sat, 7 Dec 2002 04:40:42 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 QQnsdu00962 for ; Sat, 7 Dec 2002 04:40:40 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 QQnsdu27884 for ; Sat, 7 Dec 2002 04:40:33 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 QQnscn05048 for ; Fri, 6 Dec 2002 20:28:35 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Dec 2002 15:28:12 -0500 Message-ID: <1117F7D44159934FB116E36F4ABF221B0267ED4E@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'George Swallow'" Cc: mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Fri, 6 Dec 2002 15:28:11 -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 George, I am a little concerned about your line of reasoning. This usage may be "within the spirit" of what has been specified previously, but it is likely to result in things happening in networks that could never have happened before. It is not so much a matter of insisting on doing things as literally required by specifications as it is a matter of insisting on not introducing behavior in networks that has probably not been a part of test scenarios in the past and is certainly not in the realm of common experience. In this case, a number of packets may start to appear in a network that are addressed to the local host for all host-like entities on that part of the network. Moreover, these packets will be coming to the IP stack of these host-like entities from "underneath" - which is certain to be novel. More-over, the likelihood that this will start to happen is directly related to the likelihood that the portion of the network where this is happening is already in trouble. I wonder if we are not trying to excuse what is most likely a particularly bad hack. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Friday, December 06, 2002 2:32 PM > To: neil.2.harrison@bt.com > Cc: swallow@cisco.com; Shahram_Davari@pmc-sierra.com; mpls@UU.NET; > swallow@cisco.com > Subject: Re: Last call on LSP Ping > > > George....I think the point Shahram was making it is not even allowed > > outside the host/source box according to the text quoted from the RFcs > > below. Wrapping it in some other package (any, not just MPLS) is still > > violating this requirement...and note that it *must* be placed in some > > package to get across any tranmission medium....IP pkts don't go raw on > > wires. > > As far as I'm concerned it is within the spirit of the RFCs. If you > want to insist on the letter of the law, perhaps you should look into > a career as a solicitor. > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 497-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 From owner-mpls@UU.NET Sat Dec 7 00:36:36 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 AAA09890 for ; Sat, 7 Dec 2002 00:36:36 -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 QQnsdy25753 for ; Sat, 7 Dec 2002 05:39: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 QQnsdy22072; Sat, 7 Dec 2002 05:37:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsdy24069 for mpls-outgoing; Sat, 7 Dec 2002 05:36: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 QQnsdy24064 for ; Sat, 7 Dec 2002 05:36:40 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 QQnsdy11854 for ; Sat, 7 Dec 2002 05:35: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 QQnsdy12387 for ; Sat, 7 Dec 2002 05:35:24 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 QQnsdy12375 for ; Sat, 7 Dec 2002 05:35:23 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB75ZpNZ023116 for ; Sat, 7 Dec 2002 00:35:51 -0500 (EST) 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 AAA25115 for ; Sat, 7 Dec 2002 00:35:21 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB75ZLX27358 for mpls@uu.net; Sat, 7 Dec 2002 00:35:21 -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 QQnsdy23808 for ; Sat, 7 Dec 2002 05:33:52 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 QQnsdy06832 for ; Sat, 7 Dec 2002 05:33:37 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 QQnsdy11143 for ; Sat, 7 Dec 2002 05:33:36 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 QQnsdy11128 for ; Sat, 7 Dec 2002 05:33:36 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB75Xf6a022912; Sat, 7 Dec 2002 00:33:42 -0500 (EST) Received: from eosborne-u10.cisco.com (eosborne-u10.cisco.com [161.44.134.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id AAA24974; Sat, 7 Dec 2002 00:33:12 -0500 (EST) Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id AAA00810; Sat, 7 Dec 2002 00:33:12 -0500 (EST) Date: Sat, 7 Dec 2002 00:33:12 -0500 From: Eric Osborne To: Jing Shen Cc: Eric Osborne , "J.C.Ramesh Babu" , mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: [MPLS-OPS]: Jitter and MPLS Message-ID: <20021207003312.U28607@eosborne-u10.cisco.com> References: <085301c29d34$503954f0$a4c7fe87@ad.infosys.com> <20021206110156.O28607@eosborne-u10.cisco.com> <3DF1659A.978EE288@cad.zju.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3DF1659A.978EE288@cad.zju.edu.cn>; from jshen@cad.zju.edu.cn on Sat, Dec 07, 2002 at 11:06:02AM +0800 X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk On Sat, Dec 07, 2002 at 11:06:02AM +0800, Jing Shen wrote: > Although Eric's idea is taken by many people , our experiements shows > this > is not the truth at least with the situation of our testbed. > > In fact we set up a small testbed consisting a Linux based MPLS engine. > In order to focus on difference between forwarding performance > difference > between MPLS and IP, we use CBR traffic with static routing table. > > The testbed is consist of 3 hops of MPLS(IP) forwarder between source > and > destination. The experiments shows that: > > If the hardware and software system is kept at the same level, then: > 1) TCP throughput of MPLS is a little smaller than IP when path MTU is > the same. > and difference increases when path MTU decreases. MPLS packets are 4 bytes (or more) bigger than IP packets. If you do not allow for this in your link MTU, then you have smaller effective bandwidth inside TCP. Allow for that in your link MTU (as any reasonable implementation should) and you don't have this problem. > 2) For UDP traffic, > a) when best-effort policy is applied, if link along the path is > lightly loaded (below 30%) > e2e performance difference IP and MPLS is nearly the same while > the IPDV of MPLS is > smaller than IP forwarding; if the link along the path is > heavily loaded, QoS of MPLS > is worse than IP forwarding. the same result is applied to loss > rate. > b) when resource reservation is applied, both method could > guarantee the e2e delay but > MPLS shows better IPDV value with a little longer e2e delay. > > We found the reason for this phenomenon is the > encapsulation/decapsulation procedure of MPLS, and > the processing of MPLS forwarding. So this is a test of your forwarding equipment. Equipment which takes zero or negligible time to perform this encap/decap will not have this problem. > Although we have not experimented with Cisco's express forwarding > and the like, and we do not experiment with large scale system with > real internet traffic pattern, we concern that the result could > applied to large scale network. I'm concerned about that too, because it means that you're building a large-scale network out of Linux-based software-forwarding devices. But even if you do have a performance hit at encap/decap, you only do label push/pop at the edges of the network, so you'd only take this hypothetical hit at the edges, making scale a nonissue for your particular imaginary problem. > The reason is, 1) a small testbed could > be considered as a > emulation of tunnel through large network , and some of large network > use LER-to-LER LSP; See earlier point about performance hit at the edge only > 2) we focus on forwarding difference between IP and MPLS, and we > think technique like CEF and per-port cache could be applied to both > technologies. The fact that you're considering different lookup methodologies for IP and MPLS suggests even further that what you're profiling is your implementation, and not either a) a purely hypothetical situation (a la OPnet or whatever) b) a particular router implementation I have no problem with you testing your own implementation; I have a major issue if you try to generalize those results to claim that your specific behavior is in fact an artifact of the protocol itself. > 3) the same queueing > mechanism is applied to both > technologies in our experiments. 4) comparison should be taken at the > same level of cost. > I don't understand point #4. What is 'level of cost'? > The paper on this experiment will be published on Communication Journal > ( Chinese) this month. > any comment will be highly appreciated. Any chance of getting a version in English? eric > > regards > > > > > > No, not really. MPLS lets you apply QoS using EXP bits, just like you > > can with IP Precedence; any mechanisms you can use with IP Precedence > > to reduce jitter (various queing schemes) are equally applicable with > > MPLS. Using MPLS-TE can make you more likely to avoid congestion and > > therefore less likely to experience delay and jitter, but from a > > queueing perspective it's the same with MPLS and with IP routing. > > > > eric > > > > > Please let me know > > > > > > Thanks > > > > > > J.C.Ramesh Babu > > > Technical Specialist. > > > Communications and Products Division > > > Infosys Technologies Limited > > > Electronic City, > > > Hosur Road, > > > Bangalore. > > > > > > Ph # > > > Off : 91-80-4166472 > > > Res: 91-80-6592375 > > > > ------- > > The MPLS-OPS Mailing List > > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > > -- > Jing Shen > > State Key Lab of CAD&CG > ZheJiang University(YuQuan) > HangZhou, Z.J. 310027 > P.R.China > > Tel: +86-571-87932423 > Mobile: (0)13516813753 > Email: jshen@cad.zju.edu.cn > > ********************************************************************** > * The SunShine of life is made up of very little beams which is * > * bright all the time * > ********************************************************************** From owner-mpls@UU.NET Sat Dec 7 05:27: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 FAA24945 for ; Sat, 7 Dec 2002 05:27: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 QQnses21466 for ; Sat, 7 Dec 2002 10:30: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 QQnser12079; Sat, 7 Dec 2002 10:25:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQnser17177 for mpls-outgoing; Sat, 7 Dec 2002 10:25: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 QQnser17168 for ; Sat, 7 Dec 2002 10:24: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 QQnser19265 for ; Sat, 7 Dec 2002 10:24:24 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 QQnser10646 for ; Sat, 7 Dec 2002 10:24:23 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 QQnser10642 for ; Sat, 7 Dec 2002 10:24:22 GMT Received: by cbibipnt08.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Sat, 7 Dec 2002 10:23:56 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A35389014CFCB5@i2km07-ukbr.domain1.systemhost.net> To: swallow@cisco.com Cc: Shahram_Davari@pmc-sierra.com, mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Sat, 7 Dec 2002 10:23:40 -0000 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 > > George....I think the point Shahram was making it is not > even allowed > > outside the host/source box according to the text quoted > from the RFcs > > below. Wrapping it in some other package (any, not just > MPLS) is still > > violating this requirement...and note that it *must* be > placed in some > > package to get across any tranmission medium....IP pkts > don't go raw on > > wires. > > As far as I'm concerned it is within the spirit of the RFCs. If you > want to insist on the letter of the law, perhaps you should look into > a career as a solicitor. > > ...George George, I am asking a serious question here and I would have appreciated a serious answer please. I'd also like to see some responses to the other issues that have been raised. My experience to date suggests one only gets responses 'when it suits'. At least others (esp Erics R and G and Curtis) have attempted to provide reasoned answers. This stuff is going to get delivered whatever right?....so I want to be sure that its as fit for purpose as possible (and that's more than this particular 127/8 point). Here's my understanding of the current position on this specific point: There are (at least) 2 possible cases: 1 127/8 addressed pkts should never leave a box 2 127/8 can always leave a box.....since I can put 127/8 addressed pkts in ATM or FR (or ethernet?) directly.....I see no significant technical difference here to the MPLS case that is argued as being justified. [Aside - one could generalise the above case 2 to *any* IP addressed packet, or we could make 127/8 a special case] Now I just want a ruling that 2 is fine (perhaps as a special case?), and as long as its agreed now then that's OK....I don't want this raised by someone X months hence after this stuff is being shipped and operators have deployed it. regards, Neil From owner-mpls@UU.NET Sat Dec 7 08:14:59 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 IAA27474 for ; Sat, 7 Dec 2002 08:14:59 -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 QQnsfd10229 for ; Sat, 7 Dec 2002 13:17:40 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 QQnsfc04807; Sat, 7 Dec 2002 13:14:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsfc24198 for mpls-outgoing; Sat, 7 Dec 2002 13:14: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 QQnsfc24193 for ; Sat, 7 Dec 2002 13:14:22 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 QQnsfc15551 for ; Sat, 7 Dec 2002 13:13:45 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 QQnsfc04030 for ; Sat, 7 Dec 2002 13:13:44 GMT Received: from mail.cad.zju.edu.cn by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: cad.zju.edu.cn [210.32.131.2]) id QQnsfc04021 for ; Sat, 7 Dec 2002 13:13:43 GMT Received: (qmail 24941 invoked from network); 7 Dec 2002 13:19:43 -0000 Received: from unknown (HELO ultra1) (210.32.131.97) by 210.32.131.2 with SMTP; 7 Dec 2002 13:19:43 -0000 Received: from cad.zju.edu.cn (ultra1 [210.32.131.97]) by ultra1 (8.12.6/8.12.6) with ESMTP id gB7DEJp1014419; Sat, 7 Dec 2002 21:14:20 +0800 (CST) Message-ID: <3DF1F42B.9513CCA0@cad.zju.edu.cn> Date: Sat, 07 Dec 2002 21:14:19 +0800 From: Jing Shen Reply-To: jshen@cad.zju.edu.cn Organization: State Key Lab of CAD&CG X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Eric Osborne CC: "J.C.Ramesh Babu" , mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: [MPLS-OPS]: Jitter and MPLS References: <085301c29d34$503954f0$a4c7fe87@ad.infosys.com> <20021206110156.O28607@eosborne-u10.cisco.com> <3DF1659A.978EE288@cad.zju.edu.cn> <20021207003312.U28607@eosborne-u10.cisco.com> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Thanks for Eric's comment. And, read my comment in line please. > > 1) TCP throughput of MPLS is a little smaller than IP when path MTU is > > the same. > > and difference increases when path MTU decreases. > > MPLS packets are 4 bytes (or more) bigger than IP packets. If you do > not allow for this in your link MTU, then you have smaller effective > bandwidth inside TCP. Allow for that in your link MTU (as any > reasonable implementation should) and you don't have this problem. Yes. We notice that at the first stage of our implementation and then we modify the engine to allow for such situation. Our implementation allows for a label stack with depth of 8, and we use only one. But, that do has effect on TCP throughput if the same path is taken by IP and MPLS. > So this is a test of your forwarding equipment. Equipment which takes > zero or negligible time to perform this encap/decap will not have this > problem. As I know some of manufacturers announce that their router/switch could operate at line speed, and the latency in a switch is negeligible. But, what about situation of heavy load? The ability of a linux based forwarding engine is surely not at the same level of any hardware based product, but to my personal opinion any comparation should be taken at the same situation ( hardware, software etc). Another reason is that we try to find out how MPLS compares with IP when realtime multimedia content is loaded. The bandwidth requirement of realtime distributed virtual reality system is at the level of Gbps, and that value may increase when number of people participating increases. So, we want to measure the situation that accumulated dec/enc time is not negligible. Well, if R12000 is as cheap as 2511 that's not a question at all :-) > > > Although we have not experimented with Cisco's express forwarding > > and the like, and we do not experiment with large scale system with > > real internet traffic pattern, we concern that the result could > > applied to large scale network. > > I'm concerned about that too, because it means that you're building a > large-scale network out of Linux-based software-forwarding devices. > But even if you do have a performance hit at encap/decap, you only do > label push/pop at the edges of the network, so you'd only take this > hypothetical hit at the edges, making scale a nonissue for your > particular imaginary problem. > I'm sorry I means label stack operation by encap/decap. That is done at each hop. As I mentioned above, if the load is light there is no difference but when the load is heavy the difference comes up. > > 2) we focus on forwarding difference between IP and MPLS, and we > > think technique like CEF and per-port cache could be applied to both > > technologies. > > The fact that you're considering different lookup methodologies for IP > and MPLS suggests even further that what you're profiling is your > implementation, and not either > a) a purely hypothetical situation (a la OPnet or > whatever) > b) a particular router implementation I agree with you that there is difference between lookup method between IP routing and MPLS switching, this may introduce some performance difference. > > I have no problem with you testing your own implementation; I have a > major issue if you try to generalize those results to claim that your > specific behavior is in fact an artifact of the protocol itself. > I agree that implementation introduces performance difference. So, we take the experiments with the same hardware and software. The conclusion could not be extended to the word like " any implementation of MPLS has smaller jitter than any implementation of IP", and the switching fabric in commerical product is nearly impossible to be congested. But, what about the accumulated delay along a heavy loaded path? > > I don't understand point #4. What is 'level of cost'? I mean that the forwarding engine show has the same building cost. > > Any chance of getting a version in English? I'm sorry we have not done a english version. If you like I'd send you the experimental result. Thanks again. > > eric > > > > > regards > > > > -- Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, Z.J. 310027 P.R.China Tel: +86-571-87932423 Mobile: (0)13516813753 Email: jshen@cad.zju.edu.cn ********************************************************************** * The SunShine of life is made up of very little beams which is * * bright all the time * ********************************************************************** From owner-mpls@UU.NET Sat Dec 7 09:14: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 JAA28322 for ; Sat, 7 Dec 2002 09:14:43 -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 QQnsfh04813 for ; Sat, 7 Dec 2002 14:17: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 QQnsfg28947; Sat, 7 Dec 2002 14:14:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsfg17212 for mpls-outgoing; Sat, 7 Dec 2002 14:13: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 QQnsfg17205 for ; Sat, 7 Dec 2002 14:13: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 QQnsfg23536 for ; Sat, 7 Dec 2002 14:12:42 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 QQnsfg28097 for ; Sat, 7 Dec 2002 14:12:41 GMT Received: from barry.mail.mindspring.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: barry.mail.mindspring.net [207.69.200.25]) id QQnsfg28088 for ; Sat, 7 Dec 2002 14:12:41 GMT Received: from dialup-63.214.78.25.dial1.boston1.level3.net ([63.214.78.25] helo=jluciani-laptop) by barry.mail.mindspring.net with smtp (Exim 3.33 #1) id 18Kfh6-0007Dn-00; Sat, 07 Dec 2002 09:12:36 -0500 Message-Id: <3.0.1.32.20021207092307.0071e398@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sat, 07 Dec 2002 09:23:07 -0500 To: "Wijnen, Bert (Bert)" , "Thomas D. Nadeau" Subject: RE: use of MPLS OID branch Cc: "Mpls (E-mail)" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk At 12:49 AM 12/7/02 +0100, Wijnen, Bert (Bert) wrote: >> > >Now that we are on that topic, the things that MPLS-LDP-MIB document >> > >imports OID branches in the GENERIC, ATM and FRAME_RELAY MIB Modules >> > >from the LLLLDP-MIB module and then starts assigning underneath them, >> > >that worries me in a similar manner. The assigments all happen in >> > >different MIB mdoules (which can later move into separate documents >> > >if they do not progress on stds track at same speed), and then >> > >things may get out of sync. >> > >> > I will let Joan respond to this. >> >> The Generic, ATM and FrameRelay MIB modules >> IMPORT from the MPLS-TC-MIB for the mplsMIB >> number (and IMPORT from the MPLS-LDP-MIB for >> some objects), so would agree that the >> LDP-MIB document needs to have IANA Consideration Section >> which asks IANA for mplsMIB number assignments. >> >Good. > >> IF these MIB Modules move to different >> documents (as Bert suggests above could >> happen) then would think that these new >> docs would need an IANA Considerations >> Section also, right? >> >Yeah.... but if that is what you want to do you might as well >start right away... I am not sure, I jave seen RMON WG maintain >their stuff pretty well and they do their own assignments too. >I think I only caught them once where they had an overlap. > >But in case of LDP, you start to import from various branches >in the OID tree... and so maintaining a list of which subtrees >have been used and which are still avialable gets more difficult > >For exmample > >- mpls-ldp-atm-mib imports: > mplsLdpEntityObjects, > mplsLdpSessionObjects, > ... > FROM MPLS-LDP-MIB > >And then assigns branches underneath those: > mplsLdpEntityAtmObjects OBJECT IDENTIFIER ::= > { mplsLdpEntityObjects 6 } > >And that is still kind of easy to locate. But then you have: > > mplsLdpAtmSesTable OBJECT-TYPE > ... > ::= { mplsLdpSessionObjects 10 } > >So it does not look very consistent does it? > >And then GENERIC and FRAME-RELAY mib modules do similar things I think. >How do you keep track? I see your point. Think we can probably do away with some (most?) of this sort of dependency by not importing the subOids, but need to think about this some more -- will make a note to address this issue in the next (9a) version. Thanks, -Joan > >Bert >> Would this be a reasonable solution? >> >> Thanks, >> -Joan >> >> >> >> >> > >> > --Tom >> > >> > >> > >> > >Bert >> > > > --Tom >> > > > >> > > > >> > >> > >> > >> > From owner-mpls@UU.NET Sat Dec 7 10:22: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 KAA29523 for ; Sat, 7 Dec 2002 10:22:58 -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 QQnsfl06557 for ; Sat, 7 Dec 2002 15:25: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 QQnsfl03825; Sat, 7 Dec 2002 15:23:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsfl11065 for mpls-outgoing; Sat, 7 Dec 2002 15:23: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 QQnsfl11060 for ; Sat, 7 Dec 2002 15:23: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 QQnsfl09007 for ; Sat, 7 Dec 2002 15:23: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 QQnsfl14077 for ; Sat, 7 Dec 2002 15:23:13 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 QQnsfl14072 for ; Sat, 7 Dec 2002 15:23:13 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB7FNesr008813 for ; Sat, 7 Dec 2002 10:23:40 -0500 (EST) 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 KAA18016 for ; Sat, 7 Dec 2002 10:23:10 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB7FNAC01825 for mpls@uu.net; Sat, 7 Dec 2002 10:23:10 -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 QQnsfl11019 for ; Sat, 7 Dec 2002 15:22:07 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 QQnsfl25536 for ; Sat, 7 Dec 2002 15:21:30 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 QQnsfl13123 for ; Sat, 7 Dec 2002 15:21:29 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 QQnsfl13114 for ; Sat, 7 Dec 2002 15:21:29 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB7FLTEF008687; Sat, 7 Dec 2002 10:21:30 -0500 (EST) Received: from eosborne-u10.cisco.com (eosborne-u10.cisco.com [161.44.134.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA17896; Sat, 7 Dec 2002 10:20:48 -0500 (EST) Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA01439; Sat, 7 Dec 2002 10:20:48 -0500 (EST) Date: Sat, 7 Dec 2002 10:20:48 -0500 From: Eric Osborne To: Jing Shen Cc: Eric Osborne , "J.C.Ramesh Babu" , mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: [MPLS-OPS]: Jitter and MPLS Message-ID: <20021207102048.W28607@eosborne-u10.cisco.com> References: <085301c29d34$503954f0$a4c7fe87@ad.infosys.com> <20021206110156.O28607@eosborne-u10.cisco.com> <3DF1659A.978EE288@cad.zju.edu.cn> <20021207003312.U28607@eosborne-u10.cisco.com> <3DF1F42B.9513CCA0@cad.zju.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3DF1F42B.9513CCA0@cad.zju.edu.cn>; from jshen@cad.zju.edu.cn on Sat, Dec 07, 2002 at 09:14:19PM +0800 X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk On Sat, Dec 07, 2002 at 09:14:19PM +0800, Jing Shen wrote: > Thanks for Eric's comment. And, read my comment in line please. > > > > > 1) TCP throughput of MPLS is a little smaller than IP when path MTU is > > > the same. > > > and difference increases when path MTU decreases. > > > > MPLS packets are 4 bytes (or more) bigger than IP packets. If you do > > not allow for this in your link MTU, then you have smaller effective > > bandwidth inside TCP. Allow for that in your link MTU (as any > > reasonable implementation should) and you don't have this problem. > > Yes. We notice that at the first stage of our implementation and then we > modify the engine to allow for such situation. Our implementation allows > for a label stack with depth of 8, and we use only one. But, that do has > effect on TCP throughput if the same path is taken by IP and MPLS. > Have you been able to determine what made this impact? If your TCP segments can open up to the same size under both MPLS and IP, then all you add is another 4 bytes of transmission delay, which should be so close to zero it's inconsequential. And if everything has this small additional delay, then that should in no way create jitter in the network. > > > So this is a test of your forwarding equipment. Equipment which takes > > zero or negligible time to perform this encap/decap will not have this > > problem. > > As I know some of manufacturers announce that their router/switch > could operate at line speed, and the latency in a switch is > negeligible. But, what about situation of heavy load? The ability > of a linux based forwarding engine is surely not at the same level > of any hardware based product, but to my personal opinion any > comparation should be taken at the same situation ( hardware, > software etc). A switch that operates at line rate can still do so under heavy load. There are well-known mechanisms (DiffServ) for controlling performance under heavy load. Theoretically, there should be no difference in the performance of DiffServ whether applied to IP, MPLS, or for that matter, Appletalk, IPX, or any other switched packet technology. If you have found a platform-independent issue inherent to MPLS that causes jitter, I am very interested in seeing it. > Another reason is that we try to find out how MPLS compares with IP > when realtime multimedia content is loaded. The bandwidth > requirement of realtime distributed virtual reality system is at the > level of Gbps, and that value may increase when number of people > participating increases. So, we want to measure the situation that > accumulated dec/enc time is not negligible. OK, that's a fair thing to want to measure. But again, you're testing a specific implementation, and it's not reasonable to extend that comparison to any broader scope. > > Well, if R12000 is as cheap as 2511 that's not a question at all :-) > OK, if you want to talk specific router models, let me speak to the ones I know best. :) A 12k and a 2500[*] are different. They perform differently, are priced differently, and have different interfaces and capabilities. I would never do forwarding performance tests on a 2500 and claim the 12k behaves the same way, nor would I do tests on 12k forwarding and claim the 2500 performed the same way. By the same token, you can't test a Linux forwarding implementation (a lot like a really fast 2500) and claim that its performance is the same as any other router maker. [*] - sidebar to the viewing audience - a 12k (GSR) is a Really Big router, and a 2500 is a Really Small router. > > > Although we have not experimented with Cisco's express forwarding > > > and the like, and we do not experiment with large scale system with > > > real internet traffic pattern, we concern that the result could > > > applied to large scale network. > > > > I'm concerned about that too, because it means that you're building a > > large-scale network out of Linux-based software-forwarding devices. > > But even if you do have a performance hit at encap/decap, you only do > > label push/pop at the edges of the network, so you'd only take this > > hypothetical hit at the edges, making scale a nonissue for your > > particular imaginary problem. > > > > I'm sorry I means label stack operation by encap/decap. That is done at > each hop. As I mentioned above, if the load is light there is no > difference > but when the load is heavy the difference comes up. Then what you're testing is the per-hop performance hit taken by label swapping. This is, again, very implementation-dependent. In MPLS forwarding you have to do a label lookup and label swap, in IP you have to do a FIB lookup. Whether these two are the same speed, insignificantly different, or significantly different is a platform-specific thing. > > > 2) we focus on forwarding difference between IP and MPLS, and we > > > think technique like CEF and per-port cache could be applied to both > > > technologies. > > > > The fact that you're considering different lookup methodologies for IP > > and MPLS suggests even further that what you're profiling is your > > implementation, and not either > > a) a purely hypothetical situation (a la OPnet or > > whatever) > > b) a particular router implementation > > I agree with you that there is difference between lookup method > between IP routing and MPLS switching, this may introduce some > performance difference. Right, but like I said above, the switching mechanism is not a function inherent to the protocol. > > > > I have no problem with you testing your own implementation; I have a > > major issue if you try to generalize those results to claim that your > > specific behavior is in fact an artifact of the protocol itself. > > > > I agree that implementation introduces performance difference. So, > we take the experiments with the same hardware and software. The > conclusion could not be extended to the word like " any > implementation of MPLS has smaller jitter than any implementation of > IP", and the switching fabric in commerical product is nearly > impossible to be congested. But, what about the accumulated delay > along a heavy loaded path? If the per-hop delay due to implementation differences in MPLS processing vs. IP processing is 0, then the accumulated delay is also 0. If the per-hop delay due to different protocols is non-zero but insignificant (let's say 1us per hop), then the total accumulated delay is going to be so small that it's not noticeable by any application using the network, and it will pale in comparison to other sources of delay that must exist in this network. If the per-hop delay is significant, then yes, the total end-to-end delay will also be significant. > > > > I don't understand point #4. What is 'level of cost'? > > I mean that the forwarding engine show has the same building cost. > Cost level has little to do with it. Nothing about either IP or MPLS forwarding inherently takes more money to do. The waaaaay-back, long-ago argument that MPLS is faster at switching because it's a 20-bit lookup rather than 32-bit is obsolete. There's also nothing inherent to the cost of building a forwarding device that induces any jitter, nor is there anything inherent that introduces different jitter per protocol. > > > > Any chance of getting a version in English? > > I'm sorry we have not done a english version. > If you like I'd send you the experimental result. Sure, I'd be interested to see whether there's more to this than I think. eric > Thanks again. > > > > > eric > > > > > > > > regards > > > > > > > > -- > Jing Shen > > State Key Lab of CAD&CG > ZheJiang University(YuQuan) > HangZhou, Z.J. 310027 > P.R.China > > Tel: +86-571-87932423 > Mobile: (0)13516813753 > Email: jshen@cad.zju.edu.cn > > ********************************************************************** > * The SunShine of life is made up of very little beams which is * > * bright all the time * > ********************************************************************** From owner-mpls@UU.NET Sat Dec 7 18: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 SAA10366 for ; Sat, 7 Dec 2002 18:55:01 -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 QQnsgt28392 for ; Sat, 7 Dec 2002 23:57: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 QQnsgt25823; Sat, 7 Dec 2002 23:56:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsgt16142 for mpls-outgoing; Sat, 7 Dec 2002 23:55: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 QQnsgt16124 for ; Sat, 7 Dec 2002 23:55:29 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 QQnsgt29334 for ; Sat, 7 Dec 2002 23: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 QQnsgt11265 for ; Sat, 7 Dec 2002 23:55:07 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 QQnsgt11252 for ; Sat, 7 Dec 2002 23:55:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB7NtZr4005828 for ; Sat, 7 Dec 2002 18:55:35 -0500 (EST) 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 SAA03728 for ; Sat, 7 Dec 2002 18:55:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB7Nt5M27693 for mpls@uu.net; Sat, 7 Dec 2002 18:55:05 -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 QQnsgt16091 for ; Sat, 7 Dec 2002 23:54: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 QQnsgt23189 for ; Sat, 7 Dec 2002 23:54: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 QQnsgt10542 for ; Sat, 7 Dec 2002 23:54:00 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 QQnsgt10530 for ; Sat, 7 Dec 2002 23:53:59 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 SAA28977; Sat, 7 Dec 2002 18:52:22 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212072352.SAA28977@workhorse.fictitious.org> To: neil.2.harrison@bt.com cc: swallow@cisco.com, Shahram_Davari@pmc-sierra.com, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Sat, 07 Dec 2002 10:23:40 GMT." <0536FC9B908BEC4597EE721BE6A35389014CFCB5@i2km07-ukbr.domain1.systemhost.net> Date: Sat, 07 Dec 2002 18:52:22 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <0536FC9B908BEC4597EE721BE6A35389014CFCB5@i2km07-ukbr.domain1.system host.net>, neil.2.harrison@bt.com writes: > > > George....I think the point Shahram was making it is not > > even allowed > > > outside the host/source box according to the text quoted > > from the RFcs > > > below. Wrapping it in some other package (any, not just > > MPLS) is still > > > violating this requirement...and note that it *must* be > > placed in some > > > package to get across any tranmission medium....IP pkts > > don't go raw on > > > wires. > > > > As far as I'm concerned it is within the spirit of the RFCs. If you > > want to insist on the letter of the law, perhaps you should look into > > a career as a solicitor. > > > > ...George > > George, I am asking a serious question here and I would have appreciated a > serious answer please. I'd also like to see some responses to the other > issues that have been raised. My experience to date suggests one only gets > responses 'when it suits'. At least others (esp Erics R and G and Curtis) > have attempted to provide reasoned answers. > > This stuff is going to get delivered whatever right?....so I want to be sure > that its as fit for purpose as possible (and that's more than this > particular 127/8 point). A lot of packets from my site (here at home) go through the Internet, all destined to a subnet of 10/8 (in the office). This (10/8) is also not a routeable address covered in the same sections as 127/8 in RFC1700 and RFC1812. Its OK to deliver these packets since they are encapsulated in something else. It is not considered a violation of RFC1700 or RFC1812 to forward these across the Internet where 10/8 and 127/8 are considered to be "martian packets". Going way back to 1992, the mbone tunnels were originally built out of source routed tunnels with a multicast destination. They later switched to a tunnelled encapsulation due to performance problems of certain routers when handling large volumes of source routed packets. This was not considered a violation of RFC1700 or RFC1812. There are plenty of precedences for using private addresses inside something else. In many circumstances, packets with private addresses are tunneled. You have to separately look at what happens at the end of the tunnel after the encapsulation is stripped off. > Here's my understanding of the current position on this specific point: > > There are (at least) 2 possible cases: > 1 127/8 addressed pkts should never leave a box > 2 127/8 can always leave a box.....since I can put 127/8 addressed > pkts in ATM or FR (or ethernet?) directly.....I see no significant technical > difference here to the MPLS case that is argued as being justified. > [Aside - one could generalise the above case 2 to *any* IP addressed packet, > or we could make 127/8 a special case] 127/8 cannot be forwarded based on the 127/8 destination. Just as traffic from 10/8 can leave a subnet, croos the big-I Internet, and reenter a subnet of 10/8, so can a packet be formed with a 127/8 destination and be encapsulated in something and sent. What happens when the outside encapsulation is stripped off also has to be examined. When the labels are gone, the 127/8 remains and the packet is sent to the loopback address. That is the one exception allowed by RFC1812 and delivery to the loopback is the explicit intended use of 127/8. > Now I just want a ruling that 2 is fine (perhaps as a special case?), and as > long as its agreed now then that's OK....I don't want this raised by someone > X months hence after this stuff is being shipped and operators have deployed > it. If you had a legitimate reason to deliver traffic to the loopback device on the other end of a FR or ATM link, then putting 127.0.0.1 in the destination and a valid UDP payload with a port number for that application, then it would be fine. There is a legitimate reason for selecting a 127/8 address for this application. Because it is used for a diagnostic we DON"T want it to be routeable. RFC1700 and RFC1812 guarentee that it won't be routeable. RFC1700 and RFC1812 explicitly set this address space aside for use with the loopback device. > regards, Neil Once again, I think the MPLS-ping objectors are simply grasping at straws. Curtis From owner-mpls@UU.NET Sat Dec 7 20:42:23 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 UAA11827 for ; Sat, 7 Dec 2002 20:42:22 -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 QQnshb28545 for ; Sun, 8 Dec 2002 01:45: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 QQnsha26338; Sun, 8 Dec 2002 01:44:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsha01568 for mpls-outgoing; Sun, 8 Dec 2002 01:43: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 QQnsha01558 for ; Sun, 8 Dec 2002 01:43:27 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 QQnsha01305 for ; Sun, 8 Dec 2002 01:43: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 QQnsha11664 for ; Sun, 8 Dec 2002 01:43:04 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 QQnsha11657 for ; Sun, 8 Dec 2002 01:43:04 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 UAA21674; Sat, 7 Dec 2002 20:43:00 -0500 (EST) 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 UAA20927; Sat, 7 Dec 2002 20:43:03 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Sat, 7 Dec 2002 20:43:02 -0500 Message-ID: <39469E08BD83D411A3D900204840EC55763471@VIE-MSGUSR-01> From: "Naidu, Venkata" To: "'jshen@cad.zju.edu.cn'" , Eric Osborne Cc: "J.C.Ramesh Babu" , mpls-ops@mplsrc.com, mpls@UU.NET Subject: RE: [MPLS-OPS]: Jitter and MPLS Date: Sat, 7 Dec 2002 20:43:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="gb2312" Sender: owner-mpls@UU.NET Precedence: bulk Jing & Eric, -> Although Eric's idea is taken by many people , our experiements shows -> this is not the truth at least with the situation of our testbed. -> -> In fact we set up a small testbed consisting a Linux based -> MPLS engine. In order to focus on difference between forwarding -> performance difference between MPLS and IP, we use CBR traffic -> with static routing table. -> -> The testbed is consist of 3 hops of MPLS(IP) forwarder -> between source and destination. The experiments shows that: I think your discussion is little deviated. What I understood from Jing's description is that, he didn't apply any form of TE (neither IP-TE nor MPLS-TE) in his network. Jing's measurements are based on straight line topology of 3 nodes, comparing IP and MPLS (forwarding) performance only. IMHO, in such a small topologies, the amortized performance improvements (overall gain of all operations in the worst case) may not be significant. In such straight line topologies (with out applying any form of queuing differentiation or some form of TE in the topology), I don't think MPLS out performs IP just because of MPLS fast forwarding nature (may be small amount of improvement). Remember that, there is no much difference between IP QoS techniques and MPLS QoS techniques (same classes, same queuing methodologies). The major difference between IP and MPLS is in TE techniques. This discussion reminds me of old draft: ftp://ftp.netlab.ohio-state.edu/pub/jain/ietf/draft-bhani-mpls-te-anal-00. txt Where, it is clearly shown that, there is a significant improvement in the throughput of the UDP & TCP flows when MPLS-TE is applied. However, can the same performance improvements are achieved using IP-TE methods (at least near to the performance of MPLS-TE) is still an open ended question? Some very interesting research has been done to prove the above question. But, "at what cost?", "with how much ease of configuration & maintenance?", "with what added benefits?" are still unanswered. Finally, I strongly feel that, the performance matrices change a lot from small topologies to real-complex topologies. We can't directly map the simulation results to real-world topologies. In any case, the average/amortized performance measurements & analysis of real-world complex topologies is not an easy task. If there is any such work, I will be very glad to know. Thank You. -- Venkata. From owner-mpls@UU.NET Sun Dec 8 08:58:30 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 IAA01818 for ; Sun, 8 Dec 2002 08:58:30 -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 QQnsiy13404 for ; Sun, 8 Dec 2002 14:01:23 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 QQnsiy11832; Sun, 8 Dec 2002 14:00:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsiy07422 for mpls-outgoing; Sun, 8 Dec 2002 14:00: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 QQnsiy06832 for ; Sun, 8 Dec 2002 14:00: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 QQnsiy04789 for ; Sun, 8 Dec 2002 14:00:01 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 QQnsiy09361 for ; Sun, 8 Dec 2002 14:00:00 GMT Received: from newdev.harvard.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: newdev.eecs.harvard.edu [140.247.60.212]) id QQnsiy09351 for ; Sun, 8 Dec 2002 14:00:00 GMT Received: (from sob@localhost) by newdev.harvard.edu (8.12.2/8.12.2) id gB8DwAJO019270; Sun, 8 Dec 2002 08:58:10 -0500 (EST) Date: Sun, 8 Dec 2002 08:58:10 -0500 (EST) From: Scott Bradner Message-Id: <200212081358.gB8DwAJO019270@newdev.harvard.edu> To: erosen@cisco.com Subject: Re: Last call on LSP Ping Cc: mpls@UU.NET In-Reply-To: <200212062036.gB6KahK0024250@sj-msg-core-1.cisco.com> Sender: owner-mpls@UU.NET Precedence: bulk > Thanks for finding this passage. I was worried that the IESG might balk at > the proposed use of 127/8, but the above quote, by its use of "SHOULD NOT" > rather than "MUST NOT", shows pretty clearly that the proposed use is not > prohibited fron rfc 2119 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. no, its not "prohibited," but there needs to be a quite good reason to not follow a SHOULD NOT Scott From owner-mpls@UU.NET Sun Dec 8 11:24:47 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 LAA04452 for ; Sun, 8 Dec 2002 11:24:46 -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 QQnsjh29666 for ; Sun, 8 Dec 2002 16:27: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 QQnsjh26544; Sun, 8 Dec 2002 16:25:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsjh11649 for mpls-outgoing; Sun, 8 Dec 2002 16:25:20 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 QQnsjh11639 for ; Sun, 8 Dec 2002 16:25:18 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 QQnsjh22674 for ; Sun, 8 Dec 2002 16:25: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 QQnsjh28786 for ; Sun, 8 Dec 2002 16:25:13 GMT Received: from ihemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQnsjh28782 for ; Sun, 8 Dec 2002 16:25:13 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gB8GPBI20490 for ; Sun, 8 Dec 2002 11:25:12 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Sun, 8 Dec 2002 17:25:10 +0100 Message-ID: From: "Wijnen, Bert (Bert)" To: "Mpls (E-mail)" Subject: RE: review of mpls-mgmt-overview revision 02 Date: Sun, 8 Dec 2002 17:25:08 +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 In addition to my earlier review. I seems to me that the split of the LDP MIB module into four MIB modules has not yet been incorporated into the overview document Thanks, Bert From owner-mpls@UU.NET Sun Dec 8 11:29: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 LAA04510 for ; Sun, 8 Dec 2002 11:29: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 QQnsji05778 for ; Sun, 8 Dec 2002 16:30: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 QQnsjh27452; Sun, 8 Dec 2002 16:26:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsjh11664 for mpls-outgoing; Sun, 8 Dec 2002 16:25:39 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 QQnsjh11653 for ; Sun, 8 Dec 2002 16:25: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 QQnsjh06852 for ; Sun, 8 Dec 2002 16:25:15 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 QQnsjh26278 for ; Sun, 8 Dec 2002 16:25:14 GMT Received: from ihemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQnsjh26266 for ; Sun, 8 Dec 2002 16:25:14 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gB8GPDI20495 for ; Sun, 8 Dec 2002 11:25:13 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Sun, 8 Dec 2002 17:25:10 +0100 Message-ID: From: "Wijnen, Bert (Bert)" To: "Mpls (E-mail)" Subject: smicng errors/warnings for draft-ietf-mpls-te-mib-09.txt Date: Sun, 8 Dec 2002 17:25:08 +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 W: f(mplste.mi2), (2031,19) MIN-ACCESS value identical to access specified for " mplsTunnelOwner" W: f(mplste.mi2), (2056,16) MIN-ACCESS value identical to access specified for " mplsTunnelPrimaryInstance" W: f(mplste.mi2), (2061,19) MIN-ACCESS value identical to access specified for " mplsTunnelPrimaryTimeUp" W: f(mplste.mi2), (2066,19) MIN-ACCESS value identical to access specified for " mplsTunnelPathChanges" W: f(mplste.mi2), (2071,19) MIN-ACCESS value identical to access specified for " mplsTunnelLastPathChange" W: f(mplste.mi2), (2076,19) MIN-ACCESS value identical to access specified for " mplsTunnelCreationTime" W: f(mplste.mi2), (2081,19) MIN-ACCESS value identical to access specified for " mplsTunnelStateTransitions" W: f(mplste.mi2), (2273,19) MIN-ACCESS value identical to access specified for " mplsTunnelPerfPackets" W: f(mplste.mi2), (2278,19) MIN-ACCESS value identical to access specified for " mplsTunnelPerfHCPackets" W: f(mplste.mi2), (2283,19) MIN-ACCESS value identical to access specified for " mplsTunnelPerfErrors" W: f(mplste.mi2), (2288,19) MIN-ACCESS value identical to access specified for " mplsTunnelPerfBytes" W: f(mplste.mi2), (2293,19) MIN-ACCESS value identical to access specified for " mplsTunnelPerfHCBytes" Thanks, Bert From owner-mpls@UU.NET Sun Dec 8 11:51: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 LAA04753 for ; Sun, 8 Dec 2002 11:51:27 -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 QQnsjj15763 for ; Sun, 8 Dec 2002 16:54: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 QQnsjj12728; Sun, 8 Dec 2002 16:52:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsjj14059 for mpls-outgoing; Sun, 8 Dec 2002 16:52:19 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 QQnsjj14054 for ; Sun, 8 Dec 2002 16:52:05 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 QQnsjj07804 for ; Sun, 8 Dec 2002 16:51: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 QQnsjj19607 for ; Sun, 8 Dec 2002 16:51:51 GMT Received: from zcars04f.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQnsjj19592 for ; Sun, 8 Dec 2002 16:51:51 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 gB8GohX13819; Sun, 8 Dec 2002 11:50:44 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 8 Dec 2002 11:50:44 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C0665C23D@zcard031.ca.nortel.com> From: "David Allan" To: "'curtis@fictitious.org'" , neil.2.harrison@bt.com Cc: swallow@cisco.com, Shahram_Davari@pmc-sierra.com, mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Sun, 8 Dec 2002 11:50:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29ED9.A290A81A" 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_01C29ED9.A290A81A Content-Type: text/plain Curtis: Your tone suggests that you think this document is ready for publication, and the objections that have been raised are purely designed to obstruct progress, is this true? cheers Dave -----Original Message----- From: Curtis Villamizar [mailto:curtis@fictitious.org] Sent: Saturday, December 07, 2002 6:52 PM To: neil.2.harrison@bt.com Cc: swallow@cisco.com; Shahram_Davari@pmc-sierra.com; mpls@UU.NET Subject: Re: Last call on LSP Ping In message <0536FC9B908BEC4597EE721BE6A35389014CFCB5@i2km07-ukbr.domain1.system host.net>, neil.2.harrison@bt.com writes: > > > George....I think the point Shahram was making it is not > > even allowed > > > outside the host/source box according to the text quoted > > from the RFcs > > > below. Wrapping it in some other package (any, not just > > MPLS) is still > > > violating this requirement...and note that it *must* be > > placed in some > > > package to get across any tranmission medium....IP pkts > > don't go raw on > > > wires. > > > > As far as I'm concerned it is within the spirit of the RFCs. If you > > want to insist on the letter of the law, perhaps you should look into > > a career as a solicitor. > > > > ...George > > George, I am asking a serious question here and I would have appreciated a > serious answer please. I'd also like to see some responses to the other > issues that have been raised. My experience to date suggests one only gets > responses 'when it suits'. At least others (esp Erics R and G and Curtis) > have attempted to provide reasoned answers. > > This stuff is going to get delivered whatever right?....so I want to be sure > that its as fit for purpose as possible (and that's more than this > particular 127/8 point). A lot of packets from my site (here at home) go through the Internet, all destined to a subnet of 10/8 (in the office). This (10/8) is also not a routeable address covered in the same sections as 127/8 in RFC1700 and RFC1812. Its OK to deliver these packets since they are encapsulated in something else. It is not considered a violation of RFC1700 or RFC1812 to forward these across the Internet where 10/8 and 127/8 are considered to be "martian packets". Going way back to 1992, the mbone tunnels were originally built out of source routed tunnels with a multicast destination. They later switched to a tunnelled encapsulation due to performance problems of certain routers when handling large volumes of source routed packets. This was not considered a violation of RFC1700 or RFC1812. There are plenty of precedences for using private addresses inside something else. In many circumstances, packets with private addresses are tunneled. You have to separately look at what happens at the end of the tunnel after the encapsulation is stripped off. > Here's my understanding of the current position on this specific point: > > There are (at least) 2 possible cases: > 1 127/8 addressed pkts should never leave a box > 2 127/8 can always leave a box.....since I can put 127/8 addressed > pkts in ATM or FR (or ethernet?) directly.....I see no significant technical > difference here to the MPLS case that is argued as being justified. > [Aside - one could generalise the above case 2 to *any* IP addressed packet, > or we could make 127/8 a special case] 127/8 cannot be forwarded based on the 127/8 destination. Just as traffic from 10/8 can leave a subnet, croos the big-I Internet, and reenter a subnet of 10/8, so can a packet be formed with a 127/8 destination and be encapsulated in something and sent. What happens when the outside encapsulation is stripped off also has to be examined. When the labels are gone, the 127/8 remains and the packet is sent to the loopback address. That is the one exception allowed by RFC1812 and delivery to the loopback is the explicit intended use of 127/8. > Now I just want a ruling that 2 is fine (perhaps as a special case?), and as > long as its agreed now then that's OK....I don't want this raised by someone > X months hence after this stuff is being shipped and operators have deployed > it. If you had a legitimate reason to deliver traffic to the loopback device on the other end of a FR or ATM link, then putting 127.0.0.1 in the destination and a valid UDP payload with a port number for that application, then it would be fine. There is a legitimate reason for selecting a 127/8 address for this application. Because it is used for a diagnostic we DON"T want it to be routeable. RFC1700 and RFC1812 guarentee that it won't be routeable. RFC1700 and RFC1812 explicitly set this address space aside for use with the loopback device. > regards, Neil Once again, I think the MPLS-ping objectors are simply grasping at straws. Curtis ------_=_NextPart_001_01C29ED9.A290A81A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Last call on LSP Ping

Curtis:

Your tone suggests that you think this document is = ready for publication, and the objections that have been raised are = purely designed to obstruct progress, is this true?

cheers
Dave

-----Original Message-----
From: Curtis Villamizar [mailto:curtis@fictitious.org]<= /FONT>
Sent: Saturday, December 07, 2002 6:52 PM
To: neil.2.harrison@bt.com
Cc: swallow@cisco.com; = Shahram_Davari@pmc-sierra.com; mpls@UU.NET
Subject: Re: Last call on LSP Ping



In message = <0536FC9B908BEC4597EE721BE6A35389014CFCB5@i2km07-ukbr.domain1.system<= /FONT>
host.net>, neil.2.harrison@bt.com writes:
> > > George....I think the point Shahram = was making it is not
> > even allowed
> > > outside the host/source box according = to the text quoted
> > from the RFcs
> > > below.  Wrapping it in some = other package (any, not just
> > MPLS) is still
> > > violating this requirement...and note = that it *must* be
> > placed in some
> > > package to get across any tranmission = medium....IP pkts
> > don't go raw on
> > > wires.
> >
> > As far as I'm concerned it is within the = spirit of the RFCs.  If you
> > want to insist on the letter of the law, = perhaps you should look into
> > a career as a solicitor.
> >
> > ...George
>
> George, I am asking a serious question here and = I would have appreciated a
> serious answer please.  I'd also like to = see some responses to the other
> issues that have been raised.  My = experience to date suggests one only gets
> responses 'when it suits'.  At least = others (esp Erics R and G and Curtis)
> have attempted to provide reasoned = answers.
>
> This stuff is going to get delivered whatever = right?....so I want to be sure
> that its as fit for purpose as possible (and = that's more than this
> particular 127/8 point).

A lot of packets from my site (here at home) go = through the Internet,
all destined to a subnet of 10/8 (in the = office).  This (10/8) is also
not a routeable address covered in the same sections = as 127/8 in
RFC1700 and RFC1812.  Its OK to deliver these = packets since they are
encapsulated in something else.  It is not = considered a violation of
RFC1700 or RFC1812 to forward these across the = Internet where 10/8 and
127/8 are considered to be "martian = packets".

Going way back to 1992, the mbone tunnels were = originally built out of
source routed tunnels with a multicast = destination.  They later
switched to a tunnelled encapsulation due to = performance problems of
certain routers when handling large volumes of = source routed packets.
This was not considered a violation of RFC1700 or = RFC1812.

There are plenty of precedences for using private = addresses inside
something else.

In many circumstances, packets with private addresses = are tunneled.
You have to separately look at what happens at the = end of the tunnel
after the encapsulation is stripped off.

> Here's my understanding of the current position = on this specific point:
>
> There are (at least) 2 possible cases:
> 1     127/8 addressed pkts = should never leave a box
> 2     127/8 can always = leave a box.....since I can put 127/8 addressed
> pkts in ATM or FR (or ethernet?) directly.....I = see no significant technical
> difference here to the MPLS case that is argued = as being justified.
> [Aside - one could generalise the above case 2 = to *any* IP addressed packet,
> or we could make 127/8 a special case]

127/8 cannot be forwarded based on the 127/8 = destination.  Just as
traffic from 10/8 can leave a subnet, croos the = big-I Internet, and
reenter a subnet of 10/8, so can a packet be formed = with a 127/8
destination and be encapsulated in something and = sent.

What happens when the outside encapsulation is = stripped off also has
to be examined.

When the labels are gone, the 127/8 remains and the = packet is sent to
the loopback address.  That is the one = exception allowed by RFC1812
and delivery to the loopback is the explicit = intended use of 127/8.

> Now I just want a ruling that 2 is fine (perhaps = as a special case?), and as
> long as its agreed now then that's OK....I = don't want this raised by someone
> X months hence after this stuff is being = shipped and operators have deployed
> it.

If you had a legitimate reason to deliver traffic to = the loopback
device on the other end of a FR or ATM link, then = putting 127.0.0.1 in
the destination and a valid UDP payload with a port = number for that
application, then it would be fine.

There is a legitimate reason for selecting a 127/8 = address for this
application.  Because it is used for a = diagnostic we DON"T want it to
be routeable.  RFC1700 and RFC1812 guarentee = that it won't be
routeable.  RFC1700 and RFC1812 explicitly set = this address space
aside for use with the loopback device.

> regards, Neil

Once again, I think the MPLS-ping objectors are = simply grasping at
straws.

Curtis

------_=_NextPart_001_01C29ED9.A290A81A-- From owner-mpls@UU.NET Sun Dec 8 12:03: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 MAA04933 for ; Sun, 8 Dec 2002 12:03: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 QQnsjk28809 for ; Sun, 8 Dec 2002 17:06: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 QQnsjk25417; Sun, 8 Dec 2002 17:04:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsjk01812 for mpls-outgoing; Sun, 8 Dec 2002 17:03:59 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 QQnsjk01779 for ; Sun, 8 Dec 2002 17:03:46 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 QQnsjk17991 for ; Sun, 8 Dec 2002 17:03: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 QQnsjk24967 for ; Sun, 8 Dec 2002 17:03:40 GMT Received: from zcars04e.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQnsjk24959 for ; Sun, 8 Dec 2002 17:03:40 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 gB8H34q29721; Sun, 8 Dec 2002 12:03:05 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 8 Dec 2002 12:03:05 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C0665C23F@zcard031.ca.nortel.com> From: "David Allan" To: "'Gray, Eric'" , "'George Swallow'" Cc: mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Sun, 8 Dec 2002 12:03:04 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Eric: I have similar concerns. LSP-PING supposedly is designed to provide value regardless of the vintage of the gear that is out there (which explains many "interesting" design decisions embodied in it). The use of 127. would appear to run counter to that philosophy. cheers Dave -----Original Message----- From: Gray, Eric [mailto:egray@celoxnetworks.com] Sent: Friday, December 06, 2002 3:28 PM To: 'George Swallow' Cc: mpls@UU.NET Subject: RE: Last call on LSP Ping George, I am a little concerned about your line of reasoning. This usage may be "within the spirit" of what has been specified previously, but it is likely to result in things happening in networks that could never have happened before. It is not so much a matter of insisting on doing things as literally required by specifications as it is a matter of insisting on not introducing behavior in networks that has probably not been a part of test scenarios in the past and is certainly not in the realm of common experience. In this case, a number of packets may start to appear in a network that are addressed to the local host for all host-like entities on that part of the network. Moreover, these packets will be coming to the IP stack of these host-like entities from "underneath" - which is certain to be novel. More-over, the likelihood that this will start to happen is directly related to the likelihood that the portion of the network where this is happening is already in trouble. I wonder if we are not trying to excuse what is most likely a particularly bad hack. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Friday, December 06, 2002 2:32 PM > To: neil.2.harrison@bt.com > Cc: swallow@cisco.com; Shahram_Davari@pmc-sierra.com; mpls@UU.NET; > swallow@cisco.com > Subject: Re: Last call on LSP Ping > > > George....I think the point Shahram was making it is not even allowed > > outside the host/source box according to the text quoted from the RFcs > > below. Wrapping it in some other package (any, not just MPLS) is still > > violating this requirement...and note that it *must* be placed in some > > package to get across any tranmission medium....IP pkts don't go raw on > > wires. > > As far as I'm concerned it is within the spirit of the RFCs. If you > want to insist on the letter of the law, perhaps you should look into > a career as a solicitor. > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 497-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 From owner-mpls@UU.NET Sun Dec 8 12:18:01 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 MAA05271 for ; Sun, 8 Dec 2002 12:18:01 -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 QQnsjl22716 for ; Sun, 8 Dec 2002 17:20:52 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 QQnsjl15465; Sun, 8 Dec 2002 17:16:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsjl04522 for mpls-outgoing; Sun, 8 Dec 2002 17:16: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 QQnsjl04517 for ; Sun, 8 Dec 2002 17:16:35 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 QQnsjk28436 for ; Sun, 8 Dec 2002 17:13: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 QQnsjk12639 for ; Sun, 8 Dec 2002 17:13:20 GMT Received: from zcars04f.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQnsjk12634 for ; Sun, 8 Dec 2002 17:13:19 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 gB8HCrX14077; Sun, 8 Dec 2002 12:12:54 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 8 Dec 2002 12:12:53 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C0665C240@zcard031.ca.nortel.com> From: "David Allan" To: "'curtis@fictitious.org'" , neil.2.harrison@bt.com Cc: swallow@cisco.com, Shahram_Davari@pmc-sierra.com, mpls@UU.NET Subject: RESEND: Last call on LSP Ping Date: Sun, 8 Dec 2002 12:12:52 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Still finding my way around a different e-mail system.... Curtis: Your tone suggests that you think this document is ready for publication, and the objections that have been raised are purely designed to obstruct progress, is this true? cheers Dave -----Original Message----- From: Curtis Villamizar [mailto:curtis@fictitious.org] Sent: Saturday, December 07, 2002 6:52 PM To: neil.2.harrison@bt.com Cc: swallow@cisco.com; Shahram_Davari@pmc-sierra.com; mpls@UU.NET Subject: Re: Last call on LSP Ping In message <0536FC9B908BEC4597EE721BE6A35389014CFCB5@i2km07-ukbr.domain1.system host.net>, neil.2.harrison@bt.com writes: > > > George....I think the point Shahram was making it is not > > even allowed > > > outside the host/source box according to the text quoted > > from the RFcs > > > below. Wrapping it in some other package (any, not just > > MPLS) is still > > > violating this requirement...and note that it *must* be > > placed in some > > > package to get across any tranmission medium....IP pkts > > don't go raw on > > > wires. > > > > As far as I'm concerned it is within the spirit of the RFCs. If you > > want to insist on the letter of the law, perhaps you should look into > > a career as a solicitor. > > > > ...George > > George, I am asking a serious question here and I would have appreciated a > serious answer please. I'd also like to see some responses to the other > issues that have been raised. My experience to date suggests one only gets > responses 'when it suits'. At least others (esp Erics R and G and Curtis) > have attempted to provide reasoned answers. > > This stuff is going to get delivered whatever right?....so I want to be sure > that its as fit for purpose as possible (and that's more than this > particular 127/8 point). A lot of packets from my site (here at home) go through the Internet, all destined to a subnet of 10/8 (in the office). This (10/8) is also not a routeable address covered in the same sections as 127/8 in RFC1700 and RFC1812. Its OK to deliver these packets since they are encapsulated in something else. It is not considered a violation of RFC1700 or RFC1812 to forward these across the Internet where 10/8 and 127/8 are considered to be "martian packets". Going way back to 1992, the mbone tunnels were originally built out of source routed tunnels with a multicast destination. They later switched to a tunnelled encapsulation due to performance problems of certain routers when handling large volumes of source routed packets. This was not considered a violation of RFC1700 or RFC1812. There are plenty of precedences for using private addresses inside something else. In many circumstances, packets with private addresses are tunneled. You have to separately look at what happens at the end of the tunnel after the encapsulation is stripped off. > Here's my understanding of the current position on this specific point: > > There are (at least) 2 possible cases: > 1 127/8 addressed pkts should never leave a box > 2 127/8 can always leave a box.....since I can put 127/8 addressed > pkts in ATM or FR (or ethernet?) directly.....I see no significant technical > difference here to the MPLS case that is argued as being justified. > [Aside - one could generalise the above case 2 to *any* IP addressed packet, > or we could make 127/8 a special case] 127/8 cannot be forwarded based on the 127/8 destination. Just as traffic from 10/8 can leave a subnet, croos the big-I Internet, and reenter a subnet of 10/8, so can a packet be formed with a 127/8 destination and be encapsulated in something and sent. What happens when the outside encapsulation is stripped off also has to be examined. When the labels are gone, the 127/8 remains and the packet is sent to the loopback address. That is the one exception allowed by RFC1812 and delivery to the loopback is the explicit intended use of 127/8. > Now I just want a ruling that 2 is fine (perhaps as a special case?), and as > long as its agreed now then that's OK....I don't want this raised by someone > X months hence after this stuff is being shipped and operators have deployed > it. If you had a legitimate reason to deliver traffic to the loopback device on the other end of a FR or ATM link, then putting 127.0.0.1 in the destination and a valid UDP payload with a port number for that application, then it would be fine. There is a legitimate reason for selecting a 127/8 address for this application. Because it is used for a diagnostic we DON"T want it to be routeable. RFC1700 and RFC1812 guarentee that it won't be routeable. RFC1700 and RFC1812 explicitly set this address space aside for use with the loopback device. > regards, Neil Once again, I think the MPLS-ping objectors are simply grasping at straws. Curtis From owner-mpls@UU.NET Sun Dec 8 14:39: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 OAA08148 for ; Sun, 8 Dec 2002 14:39: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 QQnsju17121 for ; Sun, 8 Dec 2002 19: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 QQnsju13608; Sun, 8 Dec 2002 19:40:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsju22031 for mpls-outgoing; Sun, 8 Dec 2002 19:39:44 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 QQnsju22021 for ; Sun, 8 Dec 2002 19:39:38 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 QQnsju11426 for ; Sun, 8 Dec 2002 19:39: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 QQnsju15633 for ; Sun, 8 Dec 2002 19:39: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 QQnsju15624 for ; Sun, 8 Dec 2002 19:39:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB8JdZFj005485 for ; Sun, 8 Dec 2002 14:39:35 -0500 (EST) 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 OAA12642 for ; Sun, 8 Dec 2002 14:39:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB8Jd5525836 for mpls@uu.net; Sun, 8 Dec 2002 14:39:05 -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 QQnsju21953 for ; Sun, 8 Dec 2002 19:37:40 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 QQnsju07901 for ; Sun, 8 Dec 2002 19:37:28 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 QQnsju11999 for ; Sun, 8 Dec 2002 19:37:28 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 QQnsju11987 for ; Sun, 8 Dec 2002 19:37:27 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 OAA32470; Sun, 8 Dec 2002 14:35:42 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212081935.OAA32470@workhorse.fictitious.org> To: "David Allan" cc: "'curtis@fictitious.org'" , neil.2.harrison@bt.com, swallow@cisco.com, Shahram_Davari@pmc-sierra.com, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: RESEND: Last call on LSP Ping In-reply-to: Your message of "Sun, 08 Dec 2002 12:12:52 EST." <9FBD322B7824D511B36900508BF93C9C0665C240@zcard031.ca.nortel.com> Date: Sun, 08 Dec 2002 14:35:42 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <9FBD322B7824D511B36900508BF93C9C0665C240@zcard031.ca.nortel.com>, " David Allan" writes: > > > Still finding my way around a different e-mail system.... > > Curtis: > > Your tone suggests that you think this document is ready for publication, > and the objections that have been raised are purely designed to obstruct > progress, is this true? > > cheers > Dave Oops ... I guess I shouldn't have replied to the list then. Curtis From owner-mpls@UU.NET Sun Dec 8 14:40: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 OAA08168 for ; Sun, 8 Dec 2002 14:40: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 QQnsju00469 for ; Sun, 8 Dec 2002 19:42: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 QQnsju26167; Sun, 8 Dec 2002 19:39:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsju22007 for mpls-outgoing; Sun, 8 Dec 2002 19:39:03 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 QQnsju21991 for ; Sun, 8 Dec 2002 19:38:50 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 QQnsju09742 for ; Sun, 8 Dec 2002 19:38:13 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 QQnsju15062 for ; Sun, 8 Dec 2002 19:38:12 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 QQnsju14986 for ; Sun, 8 Dec 2002 19:38:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB8JcZnR005440 for ; Sun, 8 Dec 2002 14:38:36 -0500 (EST) 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 OAA12613 for ; Sun, 8 Dec 2002 14:38:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB8Jc6x25783 for mpls@uu.net; Sun, 8 Dec 2002 14:38:06 -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 QQnsju21932 for ; Sun, 8 Dec 2002 19:36: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 QQnsju02122 for ; Sun, 8 Dec 2002 19:36: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 QQnsju24693 for ; Sun, 8 Dec 2002 19:36:12 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 QQnsju24653 for ; Sun, 8 Dec 2002 19:36:10 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 OAA32448; Sun, 8 Dec 2002 14:34:12 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212081934.OAA32448@workhorse.fictitious.org> To: "David Allan" cc: "'curtis@fictitious.org'" , neil.2.harrison@bt.com, swallow@cisco.com, Shahram_Davari@pmc-sierra.com, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Sun, 08 Dec 2002 11:50:44 EST." <9FBD322B7824D511B36900508BF93C9C0665C23D@zcard031.ca.nortel.com> Date: Sun, 08 Dec 2002 14:34:12 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <9FBD322B7824D511B36900508BF93C9C0665C23D@zcard031.ca.nortel.com>, " David Allan" writes: > 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_01C29ED9.A290A81A > Content-Type: text/plain > > Curtis: > > Your tone suggests that you think this document is ready for publication, > and the objections that have been raised are purely designed to obstruct > progress, is this true? > > cheers > Dave Dave, Since you asked, yes I do think the comments by two or more individuals are more obstructionist than constructive, but it seems particularly clear in this issue. As far as whether the document is ready to publish, I think the document could stand a great deal of improvement in clarity, most in explaining how the mechanisms are intended to be used. There is no doubt the wording in many places can stand much improvement but the intent to me seems clear enough (with only minor exceptions) and I feel I could implement from it. The capability is needed and the cost of providing it are minimal, most important they don't impact existing hardware. Given only two simple prerequisites, implementing MPLS-ping is simply a matter of application code. The prerequisites are 1) the ability to inject packets (from the ingress LSR) directly into an MPLS LSP, and 2) the ability to strip off labels and deliver a 127.0.0.1 addressed packet to the loopback. The former is easy enough to add and needed on the LSR for other reasons. The latter simply involves insuring that the LSR does not engage in overzealous filtering. All filters should be configurable so this should not be a problem for any existing LSR. That is not to say that no legitimate issues have been brought up. For example: 1) it is not clear to me how to handle IP src/dst hash based or MPLS label hash based load balancing, as would occur in LDP/ECMP, 2) I'm not clear on the usage of the FEC stack. I think 1) may be a deficiency, 2) is either a clarity or a feature with no clear purpose. Perhaps an example (sent to the list if not in the document) would clear up the purpose of FEC stack. If the dialog were constructive, we'd be trying our best to see the intended use (and I'm not finding that overly difficult) and where it is not clear, asking the author to provide clarification. We wouldn't be acting like a bunch of lawyers trying to stall by making arguments over technicalities where the arguments have very weak if any basis. Perhaps we should do what was done in IDR for bgp4-17 and list the objections and try to gain consensus on each individually. This way if the general feeling is that an objection does not have merit, the issue is resolved as having consensus with possibly one or a very small number of discenting opinions. Looking over the past mail (I think I've saved most or all of it), there are not that many issues though you have to wade through some diatribe. All of the comments do deserve a response. Kireeti, Ping Pan, and the other authors may have to make time for this. Curtis ps - sorry - this is close to technical content free but answering a direct question - now back to the topic of whether the 127/8 issue has any merit (which hopefully won't go on much longer). > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: Saturday, December 07, 2002 6:52 PM > To: neil.2.harrison@bt.com > Cc: swallow@cisco.com; Shahram_Davari@pmc-sierra.com; mpls@UU.NET > Subject: Re: Last call on LSP Ping > > > > In message > <0536FC9B908BEC4597EE721BE6A35389014CFCB5@i2km07-ukbr.domain1.system > host.net>, neil.2.harrison@bt.com writes: > > > > George....I think the point Shahram was making it is not > > > even allowed > > > > outside the host/source box according to the text quoted > > > from the RFcs > > > > below. Wrapping it in some other package (any, not just > > > MPLS) is still > > > > violating this requirement...and note that it *must* be > > > placed in some > > > > package to get across any tranmission medium....IP pkts > > > don't go raw on > > > > wires. > > > > > > As far as I'm concerned it is within the spirit of the RFCs. If you > > > want to insist on the letter of the law, perhaps you should look into > > > a career as a solicitor. > > > > > > ...George > > > > George, I am asking a serious question here and I would have appreciated a > > serious answer please. I'd also like to see some responses to the other > > issues that have been raised. My experience to date suggests one only > gets > > responses 'when it suits'. At least others (esp Erics R and G and Curtis) > > have attempted to provide reasoned answers. > > > > This stuff is going to get delivered whatever right?....so I want to be > sure > > that its as fit for purpose as possible (and that's more than this > > particular 127/8 point). > > A lot of packets from my site (here at home) go through the Internet, > all destined to a subnet of 10/8 (in the office). This (10/8) is also > not a routeable address covered in the same sections as 127/8 in > RFC1700 and RFC1812. Its OK to deliver these packets since they are > encapsulated in something else. It is not considered a violation of > RFC1700 or RFC1812 to forward these across the Internet where 10/8 and > 127/8 are considered to be "martian packets". > > Going way back to 1992, the mbone tunnels were originally built out of > source routed tunnels with a multicast destination. They later > switched to a tunnelled encapsulation due to performance problems of > certain routers when handling large volumes of source routed packets. > This was not considered a violation of RFC1700 or RFC1812. > > There are plenty of precedences for using private addresses inside > something else. > > In many circumstances, packets with private addresses are tunneled. > You have to separately look at what happens at the end of the tunnel > after the encapsulation is stripped off. > > > Here's my understanding of the current position on this specific point: > > > > There are (at least) 2 possible cases: > > 1 127/8 addressed pkts should never leave a box > > 2 127/8 can always leave a box.....since I can put 127/8 addressed > > pkts in ATM or FR (or ethernet?) directly.....I see no significant > technical > > difference here to the MPLS case that is argued as being justified. > > [Aside - one could generalise the above case 2 to *any* IP addressed > packet, > > or we could make 127/8 a special case] > > 127/8 cannot be forwarded based on the 127/8 destination. Just as > traffic from 10/8 can leave a subnet, croos the big-I Internet, and > reenter a subnet of 10/8, so can a packet be formed with a 127/8 > destination and be encapsulated in something and sent. > > What happens when the outside encapsulation is stripped off also has > to be examined. > > When the labels are gone, the 127/8 remains and the packet is sent to > the loopback address. That is the one exception allowed by RFC1812 > and delivery to the loopback is the explicit intended use of 127/8. > > > Now I just want a ruling that 2 is fine (perhaps as a special case?), and > as > > long as its agreed now then that's OK....I don't want this raised by > someone > > X months hence after this stuff is being shipped and operators have > deployed > > it. > > If you had a legitimate reason to deliver traffic to the loopback > device on the other end of a FR or ATM link, then putting 127.0.0.1 in > the destination and a valid UDP payload with a port number for that > application, then it would be fine. > > There is a legitimate reason for selecting a 127/8 address for this > application. Because it is used for a diagnostic we DON"T want it to > be routeable. RFC1700 and RFC1812 guarentee that it won't be > routeable. RFC1700 and RFC1812 explicitly set this address space > aside for use with the loopback device. > > > regards, Neil > > Once again, I think the MPLS-ping objectors are simply grasping at > straws. > > Curtis From owner-mpls@UU.NET Sun Dec 8 14:50:28 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 OAA08263 for ; Sun, 8 Dec 2002 14:50:28 -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 QQnsjv29708 for ; Sun, 8 Dec 2002 19:53: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 QQnsjv25228; Sun, 8 Dec 2002 19:50:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsjv23358 for mpls-outgoing; Sun, 8 Dec 2002 19:50:14 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 QQnsjv23352 for ; Sun, 8 Dec 2002 19:50: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 QQnsjv15380 for ; Sun, 8 Dec 2002 19:49:23 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 QQnsjv24366 for ; Sun, 8 Dec 2002 19:49:22 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 QQnsjv24359 for ; Sun, 8 Dec 2002 19:49:22 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB8JnonR006014 for ; Sun, 8 Dec 2002 14:49:51 -0500 (EST) 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 OAA12900 for ; Sun, 8 Dec 2002 14:49:21 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB8JnLj29367 for mpls@uu.net; Sun, 8 Dec 2002 14:49:21 -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 QQnsjv23293 for ; Sun, 8 Dec 2002 19:48: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 QQnsjv21018 for ; Sun, 8 Dec 2002 19:47: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 QQnsjv23193 for ; Sun, 8 Dec 2002 19:47:41 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 QQnsjv23174 for ; Sun, 8 Dec 2002 19:47:40 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 OAA32515; Sun, 8 Dec 2002 14:45:54 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212081945.OAA32515@workhorse.fictitious.org> To: "David Allan" cc: "'Gray, Eric'" , "'George Swallow'" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Sun, 08 Dec 2002 12:03:04 EST." <9FBD322B7824D511B36900508BF93C9C0665C23F@zcard031.ca.nortel.com> Date: Sun, 08 Dec 2002 14:45:54 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <9FBD322B7824D511B36900508BF93C9C0665C23F@zcard031.ca.nortel.com>, " David Allan" writes: > > > Eric: > > I have similar concerns. > > LSP-PING supposedly is designed to provide value regardless of the vintage > of the gear that is out there (which explains many "interesting" design > decisions embodied in it). The use of 127. would appear to run counter to > that philosophy. > > cheers > Dave Dave, I find it hard to beleive anyone would hard code filters into the hardware. Maybe into downloadable microcode, but that is changeable. If anyone has actually burned the list of "martian networks" (non-routeable, meaning loopback, and private address space) into an ASIC or other part that can't be replaced, they may have to respin some parts and replace boards. I seriously doubt anyone would do this. If not, this is nothing but a hypothetical compatibility issue for which no real instance exists. There are still tier-1 ISPs and carriers that have gear for which no change is required (none of the major routers have hard wired a 127/8 filter into silicon) and want to move forward. Curtis > -----Original Message----- > From: Gray, Eric [mailto:egray@celoxnetworks.com] > Sent: Friday, December 06, 2002 3:28 PM > To: 'George Swallow' > Cc: mpls@UU.NET > Subject: RE: Last call on LSP Ping > > > George, > > I am a little concerned about your line of > reasoning. This usage may be "within the spirit" > of what has been specified previously, but it is > likely to result in things happening in networks > that could never have happened before. It is not > so much a matter of insisting on doing things as > literally required by specifications as it is a > matter of insisting on not introducing behavior > in networks that has probably not been a part of > test scenarios in the past and is certainly not in > the realm of common experience. > > In this case, a number of packets may start > to appear in a network that are addressed to the > local host for all host-like entities on that part > of the network. Moreover, these packets will be > coming to the IP stack of these host-like entities > from "underneath" - which is certain to be novel. > More-over, the likelihood that this will start to > happen is directly related to the likelihood that > the portion of the network where this is happening > is already in trouble. > > I wonder if we are not trying to excuse what > is most likely a particularly bad hack. > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 From owner-mpls@UU.NET Sun Dec 8 23:28:00 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 XAA17034 for ; Sun, 8 Dec 2002 23:28:00 -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 QQnsle28513 for ; Mon, 9 Dec 2002 04:30: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 QQnsld20578; Mon, 9 Dec 2002 04:26:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsld18465 for mpls-outgoing; Mon, 9 Dec 2002 04:25:36 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 QQnsld18456 for ; Mon, 9 Dec 2002 04:25:31 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 QQnsld06674 for ; Mon, 9 Dec 2002 04:25: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 QQnsld02173 for ; Mon, 9 Dec 2002 04:25:06 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 QQnsld02169 for ; Mon, 9 Dec 2002 04:25:06 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB94PYLo012392 for ; Sun, 8 Dec 2002 23:25:35 -0500 (EST) 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 XAA27360 for ; Sun, 8 Dec 2002 23:25:04 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB94P4g26152 for mpls@uu.net; Sun, 8 Dec 2002 23:25:04 -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 QQnsld18405 for ; Mon, 9 Dec 2002 04:23: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 QQnsld03023 for ; Mon, 9 Dec 2002 04:23: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 QQnsld01614 for ; Mon, 9 Dec 2002 04:23:40 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 QQnsld01607 for ; Mon, 9 Dec 2002 04:23:40 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB94MlKb012220; Sun, 8 Dec 2002 23:22:47 -0500 (EST) Received: from eosborne-u10.cisco.com (eosborne-u10.cisco.com [161.44.134.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id XAA27253; Sun, 8 Dec 2002 23:22:06 -0500 (EST) Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id XAA03465; Sun, 8 Dec 2002 23:22:06 -0500 (EST) Date: Sun, 8 Dec 2002 23:22:06 -0500 From: Eric Osborne To: "Naidu, Venkata" Cc: "'jshen@cad.zju.edu.cn'" , Eric Osborne , "J.C.Ramesh Babu" , mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: [MPLS-OPS]: Jitter and MPLS Message-ID: <20021208232206.A28607@eosborne-u10.cisco.com> References: <39469E08BD83D411A3D900204840EC55763471@VIE-MSGUSR-01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <39469E08BD83D411A3D900204840EC55763471@VIE-MSGUSR-01>; from Venkata.Naidu@Marconi.com on Sat, Dec 07, 2002 at 08:43:01PM -0500 X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk On Sat, Dec 07, 2002 at 08:43:01PM -0500, Naidu, Venkata wrote: > Jing & Eric, > > -> Although Eric's idea is taken by many people , our experiements shows > -> this is not the truth at least with the situation of our testbed. > -> > -> In fact we set up a small testbed consisting a Linux based > -> MPLS engine. In order to focus on difference between forwarding > -> performance difference between MPLS and IP, we use CBR traffic > -> with static routing table. > -> > -> The testbed is consist of 3 hops of MPLS(IP) forwarder > -> between source and destination. The experiments shows that: > > I think your discussion is little deviated. What I understood > from Jing's description is that, he didn't apply any form of TE > (neither IP-TE nor MPLS-TE) in his network. Jing's measurements > are based on straight line topology of 3 nodes, comparing IP and > MPLS (forwarding) performance only. Just to make it clear, I'm not talking about TE either. TE is just a more granular way of routing that can reduce the likelyhood of congestion; once you have congestion, QoS kicks in and it doesn't matter whether it's TE or LDP or whatever (ignoring any implementations that do per-LSP scheduling for TE; since the once I know best doesn't do that, I can't speak to it). > > IMHO, in such a small topologies, the amortized performance > improvements (overall gain of all operations in the worst case) > may not be significant. > > In such straight line topologies (with out applying any form > of queuing differentiation or some form of TE in the topology), > I don't think MPLS out performs IP just because of MPLS > fast forwarding nature (may be small amount of improvement). May be small amount of performance hit. May be large amount of {improvement|performance hit}. > Remember that, there is no much difference between IP QoS techniques > and MPLS QoS techniques (same classes, same queuing > methodologies). Agreed - this is what I said to begin with. > The major difference between IP and MPLS is in TE techniques. Well, for this discussion, yes. > This discussion reminds me of old draft: > ftp://ftp.netlab.ohio-state.edu/pub/jain/ietf/draft-bhani-mpls-te-anal-00. > txt > Where, it is clearly shown that, there is a significant improvement > in the throughput of the UDP & TCP flows when MPLS-TE is applied. > I agree with this draft, although I don't think it's showing anything revelationary. If you put the same amount of traffic along a set of links that has bandwidth X, and you do the test again with a set of links of bandwidth Y, and Y >> X, then performance will be better. This is irrespective of TE or not. In the picture on p. 3 of the draft, just make the diverse paths equal-cost and ECMP will probably work fine. > However, can the same performance improvements are achieved using > IP-TE methods (at least near to the performance of MPLS-TE) is > still an open ended question? > Yes, it is an open-ended question. > Some very interesting research has been done to prove the above > question. But, "at what cost?", "with how much ease of configuration > & maintenance?", "with what added benefits?" are still unanswered. > I agree completely. eric > Finally, I strongly feel that, the performance matrices change a lot > from small topologies to real-complex topologies. We can't directly > map the simulation results to real-world topologies. In any case, > the average/amortized performance measurements & analysis of > real-world complex topologies is not an easy task. If there is > any such work, I will be very glad to know. > > Thank You. > > -- > Venkata. From owner-mpls@UU.NET Sun Dec 8 23:28: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 XAA17051 for ; Sun, 8 Dec 2002 23:28:20 -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 QQnsle07799 for ; Mon, 9 Dec 2002 04:31:06 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 QQnsld05113; Mon, 9 Dec 2002 04:29:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsld18816 for mpls-outgoing; Mon, 9 Dec 2002 04:28:59 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 QQnsld18809 for ; Mon, 9 Dec 2002 04:28: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 QQnsld15104 for ; Mon, 9 Dec 2002 04:28:24 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 QQnsld04059 for ; Mon, 9 Dec 2002 04:28:24 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 QQnsld04043 for ; Mon, 9 Dec 2002 04:28:23 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB94Sq9T012574 for ; Sun, 8 Dec 2002 23:28:52 -0500 (EST) 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 XAA27522 for ; Sun, 8 Dec 2002 23:28:22 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB94SMF26520 for mpls@uu.net; Sun, 8 Dec 2002 23:28:22 -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 QQnsld18683 for ; Mon, 9 Dec 2002 04:26:37 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 QQnsld15932 for ; Mon, 9 Dec 2002 04:26:05 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 QQnsld02544 for ; Mon, 9 Dec 2002 04:26:04 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 QQnsld02536 for ; Mon, 9 Dec 2002 04:26:04 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB94PGO9012360; Sun, 8 Dec 2002 23:25:17 -0500 (EST) Received: from eosborne-u10.cisco.com (eosborne-u10.cisco.com [161.44.134.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id XAA27333; Sun, 8 Dec 2002 23:24:46 -0500 (EST) Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id XAA03475; Sun, 8 Dec 2002 23:24:46 -0500 (EST) Date: Sun, 8 Dec 2002 23:24:46 -0500 From: Eric Osborne To: nitin p Cc: "Gopal@Yahoo" , Eric Osborne , Jing Shen , "J.C.Ramesh Babu" , mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: [MPLS-OPS]: Jitter and MPLS Message-ID: <20021208232446.B28607@eosborne-u10.cisco.com> References: <20021208205359.30244.qmail@web20513.mail.yahoo.com> <20021208223411.26669.qmail@web14511.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20021208223411.26669.qmail@web14511.mail.yahoo.com>; from nitin_panj@yahoo.com on Sun, Dec 08, 2002 at 02:34:11PM -0800 X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk On Sun, Dec 08, 2002 at 02:34:11PM -0800, nitin p wrote: > Gopal, > Thanks for clearing me on this. What makes me still > wondered is the huge difference between these two > values. Ok I will mention my results: > > Ingress: 3.665 milli seconds > Egress: 0.035 milliseconds > core: 0.018 milliseconds > > IP: 0.023 milliseconds. > > Now at ingress, if I assume both L3 lookup + L2.5 > forwarding, it doesn't explain me why this value is so > high. What else can happen at Ingress which is causing > this huge delay ? Probably I should dig into code and > find out :) Yeah, or ask Jim Leu, I think it's his code. :) > > Can you please explain, what is aggregation prefix?, > has it to do anything Penultimate Hop Popping(PHP). As > far as I know my code doesn't support PHP. Aggregate prefix is when you have a router doing aggregation that is also the tail of an LSP, like so: 10.1.0.0/24 A \ \ B-----D-----E / / C 10.1.1.0/24 If B sends 10.1.0.0/23 to D, and D sends labeled packets to B that are destined to something inside 10.1.0.0/23, B has to do an IP lookup on the packet (first removing the label stack) to figure out whether to send it to A or C. eric > > Your comments on this will be highly appreciated. > > Thanks, > Nitin > > > > --- "Gopal@Yahoo" wrote: > > Nitin, > > Theoritcal difference btw forwarding operation of > > Ingress LER and Egress LER is: > > Ingress LER: L3 lookup necessary. Depending on the > > implementation, the packet may have to go thru (or > > use) both 'ip forwarding engine/process' and the > > 'tag > > forwarding engine/process'. > > > > Egress LER: L3 lookup not necessary (exception for > > aggregate prefix). 'tag forwaridng engine' can do > > the > > job with the Label lookup. > > > > Because of the above difference in some > > implementations overhead on Ingress and egress may > > be > > different. > > rgds, > > gopal > > > > --- nitin p wrote: > > > Hi, > > > Sorry for interrupting the discussion between Eric > > > and > > > Jing. > > > > > > Recently I have also measured the hop delay in the > > > mpls-linux implementation of sourceforge.net. > > > > > > My results shows that delay at core (LSR) is less > > > than > > > that is observed in IP. > > > Delay at egress(LER) delay in MPLS is slightly > > more > > > than that in IP. > > > But, delay at ingress(LER) is much more than tha > > in > > > IP. > > > > > > With my results I can infer that in a network of > > > 1000s(may be 100s) hops overall delay in MPLS will > > > be > > > less that that in IP, but for samaller networks > > MPLS > > > results much more delay.I am not claiming that my > > > results are applicable to commercial > > > implementations, > > > which might have good hardware support unlike my > > > test > > > where I have used PC. > > > It makes sense that LERs will take more time than > > > LSRs,but what I coudn't understand is the > > > performance > > > difference between Ingress and Egress. > > > > > > Any comments on this are most welcome. > > > Thanks, > > > Nitin > > > > > > > > > --- Eric Osborne wrote: > > > > On Sat, Dec 07, 2002 at 09:14:19PM +0800, Jing > > > Shen > > > > wrote: > > > > > Thanks for Eric's comment. And, read my > > comment > > > in > > > > line please. > > > > > > > > > > > > > > > > > 1) TCP throughput of MPLS is a little > > > > smaller than IP when path MTU is > > > > > > > the same. > > > > > > > and difference increases when path > > MTU > > > > decreases. > > > > > > > > > > > > MPLS packets are 4 bytes (or more) bigger > > than > > > > IP packets. If you do > > > > > > not allow for this in your link MTU, then > > you > > > > have smaller effective > > > > > > bandwidth inside TCP. Allow for that in > > your > > > > link MTU (as any > > > > > > reasonable implementation should) and you > > > don't > > > > have this problem. > > > > > > > > > > Yes. We notice that at the first stage of our > > > > implementation and then we > > > > > modify the engine to allow for such situation. > > > Our > > > > implementation allows > > > > > for a label stack with depth of 8, and we use > > > only > > > > one. But, that do has > > > > > effect on TCP throughput if the same path is > > > taken > > > > by IP and MPLS. > > > > > > > > > > > > > Have you been able to determine what made this > > > > impact? If your TCP > > > > segments can open up to the same size under both > > > > MPLS and IP, then all > > > > you add is another 4 bytes of transmission > > delay, > > > > which should be so > > > > close to zero it's inconsequential. And if > > > > everything has this small > > > > additional delay, then that should in no way > > > create > > > > jitter in the > > > > network. > > > > > > > > > > > > > > > So this is a test of your forwarding > > > equipment. > > > > Equipment which takes > > > > > > zero or negligible time to perform this > > > > encap/decap will not have this > > > > > > problem. > > > > > > > > > > As I know some of manufacturers announce that > > > > their router/switch > > > > > could operate at line speed, and the latency > > in > > > a > > > > switch is > > > > > negeligible. But, what about situation of > > heavy > > > > load? The ability > > > > > of a linux based forwarding engine is surely > > not > > > > at the same level > > > > > of any hardware based product, but to my > > > personal > > > > opinion any > > > > > comparation should be taken at the same > > > situation > > > > ( hardware, > > > > > software etc). > > > > > > > > A switch that operates at line rate can still do > > > so > > > > under heavy load. > > > > There are well-known mechanisms (DiffServ) for > > > > controlling performance > > > > under heavy load. Theoretically, there should > > be > > > no > > > > difference in the > > > > performance of DiffServ whether applied to IP, > > > MPLS, > > > > or for that > > > > matter, Appletalk, IPX, or any other switched > > > packet > > > > technology. If > > > > you have found a platform-independent issue > > > inherent > > > > to MPLS that > > > > causes jitter, I am very interested in seeing > > it. > > > > > > > > > Another reason is that we try to find out how > > > > MPLS compares with IP > > > > > when realtime multimedia content is loaded. > > The > > > > bandwidth > > > > > requirement of realtime distributed virtual > > > > reality system is at the > > > > > level of Gbps, and that value may increase > > when > > > > number of people > > > > > participating increases. So, we want to > > measure > > > > the situation that > > > > > accumulated dec/enc time is not negligible. > > > > > > > > OK, that's a fair thing to want to measure. But > > > > again, you're testing > > > > a specific implementation, and it's not > > reasonable > > > > to extend that > > > > comparison to any broader scope. > > > > > > > > > > > > > > Well, if R12000 is as cheap as 2511 that's not > > a > > > > question at all :-) > > > > > > > > > > > > > OK, if you want to talk specific router models, > > > let > > > > me speak to the > > > > ones I know best. :) A 12k and a 2500[*] are > > > > different. They perform > > > > differently, are priced differently, and have > > > === message truncated === > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com From owner-mpls@UU.NET Mon Dec 9 04:09:35 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 EAA02589 for ; Mon, 9 Dec 2002 04:09:34 -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 QQnslw03023 for ; Mon, 9 Dec 2002 09:12:18 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 QQnslw26975; Mon, 9 Dec 2002 09:08:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQnslw11071 for mpls-outgoing; Mon, 9 Dec 2002 09:08:10 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 QQnslw11035 for ; Mon, 9 Dec 2002 09:07: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 QQnslw21567 for ; Mon, 9 Dec 2002 09:07: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 QQnslw16190 for ; Mon, 9 Dec 2002 09:07:11 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 QQnslw16178 for ; Mon, 9 Dec 2002 09:07:11 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB997dNA000727 for ; Mon, 9 Dec 2002 04:07:40 -0500 (EST) 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 EAA11049 for ; Mon, 9 Dec 2002 04:07:09 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9979C14928 for mpls@uu.net; Mon, 9 Dec 2002 04:07:09 -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 QQnslw10807 for ; Mon, 9 Dec 2002 09:06:26 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 QQnslw00971 for ; Mon, 9 Dec 2002 09:06:06 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 QQnslw24826 for ; Mon, 9 Dec 2002 09:06:06 GMT Received: from mailhost.metro-optix.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.219.248.6]) id QQnslw24809 for ; Mon, 9 Dec 2002 09:06:05 GMT Received: by mailhost.metro-optix.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Dec 2002 03:03:54 -0600 Message-ID: <99EC34181384D611BE56000347227B2C01520E@MAILHOSTNB> From: Manoj Agiwal To: "'Ccamp (E-mail)" Cc: "'mpls@UU.NET'" Subject: Message ID generation Date: Mon, 9 Dec 2002 03:03:42 -0600 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 , These are the lines from Refresh Reduction RFC " Message identification and acknowledgment is done on a per hop basis. All types of MESSAGE_ID objects contain a message identifier. The identifier MUST be unique on a per object generator's IP address basis In case of Gmpls if Per object generators IP address is control channel address then Message ID should be unique for each control channel address , or should it be unique per Neighbour . i.e. If there are two control channel address in a Node that goes to the same neighbor in the data plane , the Message Id generation should be unique per control channel address or Message Id generation should be unique for each neighbor . Regards , Manoj From owner-mpls@UU.NET Mon Dec 9 05:39: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 FAA04341 for ; Mon, 9 Dec 2002 05:39: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 QQnsmc13973 for ; Mon, 9 Dec 2002 10:42: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 QQnsmc07810; Mon, 9 Dec 2002 10:38:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsmc06697 for mpls-outgoing; Mon, 9 Dec 2002 10:38:24 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 QQnsmc06685 for ; Mon, 9 Dec 2002 10:38: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 QQnsmc12825 for ; Mon, 9 Dec 2002 10:37: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 QQnsmc06857 for ; Mon, 9 Dec 2002 10:37:09 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 QQnsmc06852 for ; Mon, 9 Dec 2002 10:37:08 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9Aba9M005427 for ; Mon, 9 Dec 2002 05:37:36 -0500 (EST) 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 FAA13736 for ; Mon, 9 Dec 2002 05:37:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9Ab6Y20831 for mpls@uu.net; Mon, 9 Dec 2002 05:37:06 -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 QQnsmc06585 for ; Mon, 9 Dec 2002 10:36:15 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 QQnsmc27407 for ; Mon, 9 Dec 2002 10:35:23 GMT From: Roberto.Guglielmi@alcatel.it 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 QQnsmc05900 for ; Mon, 9 Dec 2002 10:35:22 GMT Received: from tlvsca.vim.tlt.alcatel.it by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [194.243.74.245]) id QQnsmc05894 for ; Mon, 9 Dec 2002 10:35:21 GMT Received: from itmail02.prod.alcatel.it (localhost [127.0.0.1]) by tlvsca.vim.tlt.alcatel.it (8.12.5/8.12.5) with ESMTP id gB9AYort023839; Mon, 9 Dec 2002 11:34:50 +0100 (MET) Received: from alcatel.it ([151.98.36.75]) by itmail02.prod.alcatel.it (Lotus Domino Release 5.0.8) with ESMTP id 2002120911370493:1353 ; Mon, 9 Dec 2002 11:37:04 +0100 Message-ID: <3DF47015.70809@alcatel.it> Date: Mon, 09 Dec 2002 11:27:33 +0100 User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@UU.NET, puneet@acm.org, bora@cisco.com CC: rurick@nortelnetworks.com Subject: iTTL determination with Ethernet frames X-MIMETrack: Itemize by SMTP Server on ITMAIL02/IT/ALCATEL(Release 5.0.8 |June 18, 2001) at 12/09/2002 11:37:04, Serialize by Router on ITMAIL02/IT/ALCATEL(Release 5.0.8 |June 18, 2001) at 12/09/2002 11:37:06, Serialize complete at 12/09/2002 11:37:06 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi everyone, I have the following question about Time to Live (TTL) Processing in MPLS Networks (Updates RFC 3032) draft. The draft describes the TTL processing with incoming IP/MPLS packets. Consider the following scenario. The incoming flows are Ethernet TLS flow traversing an intervening MPLS network. The typical scenario is to assign each flow, entering and leaving the MPLS network from the same end points, with a VC label (following Martini's draft) and encapsulate all the obtained VC tunnels into a single tunnel LSP, in order to offer all the clients the same service. That is, on each incoming Ethernet frame will be pushed a stack of two label. In this case, what should the iTTL be, since it cannot be inferred neither from an IP header nor from a MPLS header? Wouldn't it be a good idea to extend the content of the draft to the case of transport of layer 2 frames over MPLS as well? Thanks for spending your valuable time. Regards Roberto From owner-mpls@UU.NET Mon Dec 9 06:53:22 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 GAA05263 for ; Mon, 9 Dec 2002 06:53:22 -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 QQnsmh06730 for ; Mon, 9 Dec 2002 11:55:51 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 QQnsmh28130; Mon, 9 Dec 2002 11:51:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsmh00820 for mpls-outgoing; Mon, 9 Dec 2002 11:51:05 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 QQnsmh00771 for ; Mon, 9 Dec 2002 11:50:50 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 QQnsmh12410 for ; Mon, 9 Dec 2002 11:50:11 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 QQnsmh27432 for ; Mon, 9 Dec 2002 11:50:10 GMT Received: from mail.cad.zju.edu.cn by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: cad.zju.edu.cn [210.32.131.2]) id QQnsmh27413 for ; Mon, 9 Dec 2002 11:50:09 GMT Received: (qmail 23012 invoked from network); 9 Dec 2002 11:56:11 -0000 Received: from unknown (HELO ultra1) (210.32.131.97) by 210.32.131.2 with SMTP; 9 Dec 2002 11:56:11 -0000 Received: from cad.zju.edu.cn (ultra1 [210.32.131.97]) by ultra1 (8.12.6/8.12.6) with ESMTP id gB9Bokp1017016; Mon, 9 Dec 2002 19:50:47 +0800 (CST) Message-ID: <3DF48396.494EBECA@cad.zju.edu.cn> Date: Mon, 09 Dec 2002 19:50:46 +0800 From: Jing Shen Reply-To: jshen@cad.zju.edu.cn Organization: State Key Lab of CAD&CG X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: nitin p CC: "Gopal@Yahoo" , Eric Osborne , "J.C.Ramesh Babu" , mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: [MPLS-OPS]: Jitter and MPLS References: <20021208223411.26669.qmail@web14511.mail.yahoo.com> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit nitin, I suggest you to dig into the code or contact Leu. Our implementation generates nearly the same delay when acting as either Ingree or Egress. Is there any on-demand switching enabled? > > Gopal, > Thanks for clearing me on this. What makes me still > wondered is the huge difference between these two > values. Ok I will mention my results: > > Ingress: 3.665 milli seconds > Egress: 0.035 milliseconds > core: 0.018 milliseconds > > IP: 0.023 milliseconds. > > Now at ingress, if I assume both L3 lookup + L2.5 > forwarding, it doesn't explain me why this value is so > high. What else can happen at Ingress which is causing > this huge delay ? Probably I should dig into code and > find out :) > > Can you please explain, what is aggregation prefix?, > has it to do anything Penultimate Hop Popping(PHP). As > far as I know my code doesn't support PHP. > > Your comments on this will be highly appreciated. > > Thanks, > Nitin -- Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, Z.J. 310027 P.R.China Tel: +86-571-87932423 Mobile: (0)13516813753 Email: jshen@cad.zju.edu.cn ********************************************************************** * The SunShine of life is made up of very little beams which is * * bright all the time * ********************************************************************** From owner-mpls@UU.NET Mon Dec 9 07:40: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 HAA06256 for ; Mon, 9 Dec 2002 07:40: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 QQnsmk28818 for ; Mon, 9 Dec 2002 12:43: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 QQnsmk26531; Mon, 9 Dec 2002 12:41:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsmk22875 for mpls-outgoing; Mon, 9 Dec 2002 12:41:25 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 QQnsmk22810 for ; Mon, 9 Dec 2002 12:41:13 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 QQnsmk17525 for ; Mon, 9 Dec 2002 12:40: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 QQnsmk08017 for ; Mon, 9 Dec 2002 12:40:31 GMT Received: from mail.cad.zju.edu.cn by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: cad.zju.edu.cn [210.32.131.2]) id QQnsmk08001 for ; Mon, 9 Dec 2002 12:40:29 GMT Received: (qmail 23772 invoked from network); 9 Dec 2002 12:46:31 -0000 Received: from unknown (HELO ultra1) (210.32.131.97) by 210.32.131.2 with SMTP; 9 Dec 2002 12:46:31 -0000 Received: from cad.zju.edu.cn (ultra1 [210.32.131.97]) by ultra1 (8.12.6/8.12.6) with ESMTP id gB9Cf9p1017069; Mon, 9 Dec 2002 20:41:09 +0800 (CST) Message-ID: <3DF48F65.840949E1@cad.zju.edu.cn> Date: Mon, 09 Dec 2002 20:41:09 +0800 From: Jing Shen Reply-To: jshen@cad.zju.edu.cn Organization: State Key Lab of CAD&CG X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Naidu, Venkata" CC: Eric Osborne , "J.C.Ramesh Babu" , mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: [MPLS-OPS]: Jitter and MPLS References: <39469E08BD83D411A3D900204840EC55763471@VIE-MSGUSR-01> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit It's main conclusion of our experiments that policy based routing must be used with MPLS if e2e QoS is considered carefully. I agree with Naidu that experiments with large scale network consisting of commercial router/switch is needed to find out more details, as theoretical analysis of e2e delay relates to same factor set in either MPLS or IP network, Jitter relates closely to queueing mechanism, but also accumulated processing overhead. there has been discussion on difference between MPLS-TE and IP-TE on some other list, but I don't think IP-TE based only on traffic metrix, linear programing and policy database could be easily set up in ISP networks, the obstacle exists with both traffic metix derivation, optimization period and the policy dealing with broken links. OMP gives a good start on traffic engineering but its traffic division policy is too simple for self-similar internet traffic. I have another question, is OMP implemented in some commerical products? if not, why? The overprovisioning of network resource makes current network works smooth util I come to know that DVE works at Gbps bandwidth requiement. > > I think your discussion is little deviated. What I understood > from Jing's description is that, he didn't apply any form of TE > (neither IP-TE nor MPLS-TE) in his network. Jing's measurements > are based on straight line topology of 3 nodes, comparing IP and > MPLS (forwarding) performance only. > > IMHO, in such a small topologies, the amortized performance > improvements (overall gain of all operations in the worst case) > may not be significant. > > In such straight line topologies (with out applying any form > of queuing differentiation or some form of TE in the topology), > I don't think MPLS out performs IP just because of MPLS > fast forwarding nature (may be small amount of improvement). > Remember that, there is no much difference between IP QoS techniques > and MPLS QoS techniques (same classes, same queuing methodologies). > The major difference between IP and MPLS is in TE techniques. > > This discussion reminds me of old draft: > ftp://ftp.netlab.ohio-state.edu/pub/jain/ietf/draft-bhani-mpls-te-anal-00. > txt > Where, it is clearly shown that, there is a significant improvement > in the throughput of the UDP & TCP flows when MPLS-TE is applied. > > However, can the same performance improvements are achieved using > IP-TE methods (at least near to the performance of MPLS-TE) is > still an open ended question? > > Some very interesting research has been done to prove the above > question. But, "at what cost?", "with how much ease of configuration > & maintenance?", "with what added benefits?" are still unanswered. > > Finally, I strongly feel that, the performance matrices change a lot > from small topologies to real-complex topologies. We can't directly > map the simulation results to real-world topologies. In any case, > the average/amortized performance measurements & analysis of > real-world complex topologies is not an easy task. If there is > any such work, I will be very glad to know. > > Thank You. > > -- > Venkata. -- Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, Z.J. 310027 P.R.China Tel: +86-571-87932423 Mobile: (0)13516813753 Email: jshen@cad.zju.edu.cn ********************************************************************** * The SunShine of life is made up of very little beams which is * * bright all the time * ********************************************************************** From owner-mpls@UU.NET Mon Dec 9 08:13: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 IAA07839 for ; Mon, 9 Dec 2002 08:13:30 -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 QQnsmn03315 for ; Mon, 9 Dec 2002 13:16:23 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 QQnsmm25649; Mon, 9 Dec 2002 13:08:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsmm12913 for mpls-outgoing; Mon, 9 Dec 2002 13:08: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 QQnsmm12878 for ; Mon, 9 Dec 2002 13:07:56 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 QQnsmm25010 for ; Mon, 9 Dec 2002 13:07: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 QQnsmm26142 for ; Mon, 9 Dec 2002 13:07:31 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 QQnsmm26066 for ; Mon, 9 Dec 2002 13:07:25 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9D7seu014530 for ; Mon, 9 Dec 2002 08:07:54 -0500 (EST) 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 IAA18847 for ; Mon, 9 Dec 2002 08:07:24 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9D7OK01647 for mpls@uu.net; Mon, 9 Dec 2002 08:07:24 -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 QQnsmm12592 for ; Mon, 9 Dec 2002 13:06: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 QQnsmm05015 for ; Mon, 9 Dec 2002 13:05: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 QQnsmm22771 for ; Mon, 9 Dec 2002 13:05:47 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 QQnsmm22605 for ; Mon, 9 Dec 2002 13:05:41 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07197; Mon, 9 Dec 2002 08:02:47 -0500 (EST) Message-Id: <200212091302.IAA07197@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-query-05.txt Date: Mon, 09 Dec 2002 08:02:46 -0500 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 : Multi Protocol Label Switching Label Distribution Protocol Query Message Description Author(s) : P. Ashwood-Smith, A. Paraschiv Filename : draft-ietf-mpls-lsp-query-05.txt Pages : 19 Date : 2002-12-6 This document describes the encoding and procedures for three new Label Distribution Protocol (LDP) messages: Query Message, Query- Reply Message and Partial Query-Reply Message (the last one is almost identical to the Query-Reply message; therefore all references to the Query-Reply messages imply the Partial Query-Reply messages as well, unless otherwise specified). A Lable Edge Router (LER) sends a Query message when it needs to find out information about a Label Switched Path (LSP). The Query message is sent for an established LSP. The Query message can be used for LDP LSPs as well as for Constraint- Based Label Switched Paths (CR-LSPs). The queried data is encoded into the Query-Reply messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-query-05.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-query-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-lsp-query-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-12-6140314.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lsp-query-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lsp-query-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-6140314.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Dec 9 08:18:32 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 IAA08167 for ; Mon, 9 Dec 2002 08:18:32 -0500 (EST) 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 QQnsmm15003; Mon, 9 Dec 2002 13:01:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsmm02908 for mpls-outgoing; Mon, 9 Dec 2002 13:01: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 QQnsmm01968 for ; Mon, 9 Dec 2002 13:01:16 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 QQnsml06021 for ; Mon, 9 Dec 2002 12:59: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 QQnsml20601 for ; Mon, 9 Dec 2002 12:59:44 GMT Received: from mail.cad.zju.edu.cn by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: cad.zju.edu.cn [210.32.131.2]) id QQnsml20589 for ; Mon, 9 Dec 2002 12:59:43 GMT Received: (qmail 24198 invoked from network); 9 Dec 2002 13:05:45 -0000 Received: from unknown (HELO ultra1) (210.32.131.97) by 210.32.131.2 with SMTP; 9 Dec 2002 13:05:45 -0000 Received: from cad.zju.edu.cn (ultra1 [210.32.131.97]) by ultra1 (8.12.6/8.12.6) with ESMTP id gB9D0Hp1017093; Mon, 9 Dec 2002 21:00:24 +0800 (CST) Message-ID: <3DF493E1.EC248723@cad.zju.edu.cn> Date: Mon, 09 Dec 2002 21:00:17 +0800 From: Jing Shen Reply-To: jshen@cad.zju.edu.cn Organization: State Key Lab of CAD&CG X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: alok , mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: [MPLS-OPS]: Jitter and MPLS References: <085301c29d34$503954f0$a4c7fe87@ad.infosys.com> <20021206110156.O28607@eosborne-u10.cisco.com> <3DF1659A.978EE288@cad.zju.edu.cn> <20021207003312.U28607@eosborne-u10.cisco.com> <3DF1F42B.9513CCA0@cad.zju.edu.cn> <007f01c29e07$a1cb2540$81c802c0@alok> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit alok, > > I cant figure this point > > are you comparing ethernet--MPLS--IP--TCP frame with ethernet--IP--TCP > frame? well then your frame size is larger....thats about the only > difference i see. That's the reason. The reason why we take that is, we do not consider MPLS as mechanism carrying TCP packet, and MPLS is to add new mechanism to IP networks, so the overhead is considered to be the one affecting throughput. If we want o compare payload of MPLS with payload of IP, I can't find any acceptable parameters to be compared. > > yes, but lets assume that u had a scenario where the MPLS+payload(be it IP > of anything) was compared with IP+(payload) ...where payload is of equal > size, then what is the result? do realise your switching on a smaller > "label" than an whole IP address....and I also assume your switching table > is not optimized for "aggregates etc"..it depends on your switching > mechanism. > We don't want to compare aggregation situation, but want to focus on e2e performance difference. > > well, we put L2 headers in each hop too and in cases of ethernet/Multiaccess > media, the L2 header depends on the next-hop... you would have ASICs doing > it on the interface/FT. > > according to your logic, FR interfaces should give the same > problem.....specially on MultiAccess topologies... > > > [snip] -- Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, Z.J. 310027 P.R.China Tel: +86-571-87932423 Mobile: (0)13516813753 Email: jshen@cad.zju.edu.cn ********************************************************************** * The SunShine of life is made up of very little beams which is * * bright all the time * ********************************************************************** From owner-mpls@UU.NET Mon Dec 9 08:50:44 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 IAA09013 for ; Mon, 9 Dec 2002 08:50:43 -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 QQnsmp00257 for ; Mon, 9 Dec 2002 13:53: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 QQnsmp25156; Mon, 9 Dec 2002 13:50:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsmp17364 for mpls-outgoing; Mon, 9 Dec 2002 13:50:10 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 QQnsmp17333 for ; Mon, 9 Dec 2002 13:49: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 QQnsmp26312 for ; Mon, 9 Dec 2002 13:48: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 QQnsmp17610 for ; Mon, 9 Dec 2002 13:48:28 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 QQnsmp17604 for ; Mon, 9 Dec 2002 13:48:28 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 gB9DmQi18075 for ; Mon, 9 Dec 2002 08:48:27 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Dec 2002 14:48:26 +0100 Message-ID: From: "Wijnen, Bert (Bert)" To: "Mpls (E-mail)" Subject: review of draft-ietf-mpls-te-mib-09.txt Date: Mon, 9 Dec 2002 14:48:23 +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 Seems that a lot of earlier comments I had made to the authors half a year or so ago, have not been addressed. Oh well. Here we go (mix of nits, and more serious things) - missing IPR section - Security considerations probably needs more work Security ADs want you to explain what the vulnerabilities/risks are and what to do against them. Also for read only objects, pls list each (group of) object(s) and explain what sensitivity attributes they have - RowStatus and STorageType objects need better text as per my comments to the other MIB modules. And a special question... " If this variable is set to readOnly(5), and the corresponding entry is removed, then the agent must remove this row shortly thereafter [RFC2579]." What does that mean? What is the "corresponding entry"? That is this row, is it not? - References need to be split in normative and informative - mplsXxxxNext, see my comments in my review of other mpls MIB modules - last bullet sect 4 talks about (non-)persistent tunnels. as does the DESCRIPTION clause of mplsTunnelGroup... but I don't get a good picture of what makes a persistent or a non-persistent tunnel and what the MIB offers for that. - section 9, the example includes mplsTunnelOwner... but it claims that those things are to be part of a SET request. But... in the MIB module I see the mplsTunnelOwner is read-only, so it cannot be part of a SET - section 9 example inlcudes mplsTunnelResourcePointer and syas that it should be SET to mplsTunnelResourceIndex.5 I think that should be mplsResourceMaxRate.5 because that is the first accessible columnar object in a row that table - section 10, first sentence s/to one of its objetcs/to the first accesible object in a row/ last sentence s/to the first column/to the first accessible column/ - I wonder if mplsTunnelConfigured would be better named mplsTunnelsConfigured and mplsTunnelActive better be named mplsTunnelsActive - I ownder if mplsTunnelNotiMaxRate would be better named mplsTunnelNotiInterval May want to add a UNITS clause to this object anyway and why is it not named mplsTunnerNotificationInterval? - mplsTunnelIndexNext well, same comment as to all the mplsXxxNext objects in the other MIB modules. But this one has even another strange thing, namely it is a Interger32 (as opposed to a Unsigned32) and it has a pretty limited range and for all I can tell for no good reason. In fact I see no reason for a upper limit. - mplsTunnelEntry Why is there a reference to RFC1700 ??? That RFC has been obsoleted anyway... - Can someone explain to me why you use the complex indexing scheme for the mplsTunnelTable, namely: INDEX { mplsTunnelIndexIndex, mplsTunnelInstance, mplsTunnelIngressLSRId, mplsTunnelEgressLSRId } - first, I do not understand why it the 1st one is named mplsTunnelIndexIndex instead of just mplsTunnelIndex - 2nd, mplsTunnelIndexIndex claims to "uniquely" identify a row so then no more index objects seem needed - but mplsTunnelInstance seems to also "uniquely" identify a row?? - and then there are yet more index objects. - mplsTunnelIngresLSRId, description talks about "this value". but the index object does not really have a value. It is part of the OID that identifies instances in the table. Why do I not understand this indexing scheme? I think it would be good to include in the DESCRIPTION clause of either the mplsTunnleEntry or of the indices a very good explanation as to how the indexing works here. - I have trouble with the use of DisplaySTring (as mentioned half a year ago). These days we want people to use UTF8 based strings if the strings are intended for human use. So either SnmpAdminString or some other UTF8-based string. Several TCs have been defined to replace DisplayString - I wonder why the mplsTunnelName is ever to be equal to ifName. The link between an entry in the mplsTunnelTable and the ifTable is made by the mplsIfTunnelIndex which is the better way indeed to make the link. - It seems to me that mplsIfTunnelDescription could have a DEFVAL of the empty (zero lenght) string - It seems to me that mplsTunnelIsIf and mplsTunnelIfIndex are overlapping. A value of zero in the mplsTunnelIfIndex means that this tunnel does not correspond to an interface. A nonzero value means that it does correspond to an interface. So why is mplsTunnelIsIf needed? So that people can have conflicting stuff that needs to be chacked and all that? - mplsTunnelSessionAttributes you may want to check the formatting in the DESCRIPTION clause - mplsTunnelOwner is a read-only object and yet the description clause talks about that it cannot be modified when RowStatus is active. That seems redundant text. A read-only object can NEVER be changed - I see mplsTunnelHopTableIndex to be read-create while mplsTunnelARHopTableIndex and mplsTunnelCHopTableIndex are read-only Is that not strange? - I do not understand mplsTunnelPrimaryInstance, but that is probably linked to me not understanding the indexing scheme. - mplsTunnelPathChanges s/paths has changed/path has changed/ or s/path has changed/paths have changed/ ?? - mplsTunnelTotalUptime so is this an aggregate value of multiple entries in this table? and if so of how many? Is that of all entries with the same mplsTunnelIndexIndex, or what? And then... if there are 4 entries aggregated, do all 4 entries then have the same value? And what is the upTime of each entry? I am confused here as to what the purpose of this object is and how it is computed. Under what circumstances would it "not be available"? - mplsTunnelHopListIndexNext well, same comment as to all the mplsXxxNext objects in the other MIB modules. But this one has even another strange thing, namely it is a Interger32 (as opposed to a Unsigned32) and it has a pretty limited range and for all I can tell for no good reason. In fact I see no reason for a upper limit. - mplsTunnelHopTable. again I do not (from the DESCRIPTION clauses) understand the indexing scheme. It seems to have two "seconday" indices. Should that be a secondary and a tertiary? Must be me, since I am not an mpls expert ;-) - I assume that the mplsTunnelHopAddrType and related objects get replaced with a common new TC as discussed at the MPLS MIB meeting in Atlanta - mplsTunnelHopType this sort of ENUMERATION seems to occur a few times, so that it seems to me that you want to create a TC for it. - mplsTunnelHopPathOptionName should be UTF8 based and not DisplayString - mplsTunnelResourceIndexNext well, same comment as to all the mplsXxxNext objects in the other MIB modules. But this one has even another strange thing, namely it is a Interger32 (as opposed to a Unsigned32) and it has a pretty limited range and for all I can tell for no good reason. In fact I see no reason for a upper limit. - mplsTunnelResourceMaxRate and mplsTunnelResourceMeanRate could use a UNITS clause And... you say it is bits per second, while the MplsBitRate TC claims that it is Kbps... oh well - mplsTunnelResourceMaxRate and mplsTunnelResourceMeanRate I don't think I udnerstand what the OID copying is all about and how an agent determines what to do? Or is it the management station who does this? - mplsTunnelResourceFrequency OBJECT-TYPE SYNTAX INTEGER { unspecified(1), frequent(2), veryFrequent(3) I see another occurence in another table. So a good candidate for a TC But I also wonder what "frequent" and "veryFrequent" means? To me they seem very very vague terms, no? - mplsTunnelResourceWeight OBJECT-TYPE SYNTAX Unsigned32(0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "The relative weight for using excess bandwidth above its committed rate. The value of 0 means that weight is not applicable for the CR-LSP." I see this multiple times. Good candidate for a TC - mplsTunnelARHopAddrType and related objects I assume this will be replaced by new TCs as discussed in atlanta - mplsTunnelCHopAddrType and related objects I assume this will be replaced by new TCs as discussed in atlanta - I would suggest to just do counter 64 instead of both 64 and 32 for objects like mplsTunnelPerfPackets Counter32, mplsTunnelPerfHCPackets Counter64, mplsTunnelPerfBytes Counter32, mplsTunnelPerfHCBytes Counter64 In general we also speak about octets instead of bytes, but I can live with bytes. - I wonder if mplsTunnelCRLDPResFlags would not be better represented with a BITS construct instead of an INTEGER enumeration - MODULE COMPLIANCE Maybe a Full and a ReadOnly compliance? See also my comment to other mpls MIB modules. It links to the SYNTAX and WRITE-SYNTAX of some of the objects as well, specifically the RowStatus objects - Pls see also my note in other MIB Module comments about the 'other' for StirageType objetcs. It seems really weird to have that in the compliance. - It is not good to give a group of objects a name that indicates optionality. A gorup is just a group. If it is optional or manadatory, that should become clear in the MODULE COMPLIANCE statement, but not in the name (and/or description clause) of the group Some future MODULE COMPLIANCE may want to make that group mandatory. An OBJECT GROUP is a "logical grouping" of objects. The requirement for mandatory of conditional or optional implementation is to be specified in the MODULE-COMPLIANCE. - I do not understand why there is both mplsTunnelIsIntfcGroup and a mplsTunnelIsNotIntfcGroup? One seems sufficient to me. And why not spell out Intfc as Interface? Thanks, Bert From owner-mpls@UU.NET Mon Dec 9 08:54:47 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 IAA09196 for ; Mon, 9 Dec 2002 08:54: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 QQnsmp07311 for ; Mon, 9 Dec 2002 13:57: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 QQnsmp24909; Mon, 9 Dec 2002 13:50:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsmp17359 for mpls-outgoing; Mon, 9 Dec 2002 13:50:06 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 QQnsmp17332 for ; Mon, 9 Dec 2002 13:49:54 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 QQnsmp25362 for ; Mon, 9 Dec 2002 13:48: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 QQnsmp00142 for ; Mon, 9 Dec 2002 13:48:10 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 QQnsmp00134 for ; Mon, 9 Dec 2002 13:48:10 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9Dmclf018406 for ; Mon, 9 Dec 2002 08:48:38 -0500 (EST) 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 IAA20647 for ; Mon, 9 Dec 2002 08:48:08 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9Dm8v05526 for mpls@uu.net; Mon, 9 Dec 2002 08:48:08 -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 QQnsmp17227 for ; Mon, 9 Dec 2002 13:47: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 QQnsmp21174 for ; Mon, 9 Dec 2002 13:46: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 QQnsmp29272 for ; Mon, 9 Dec 2002 13:46:58 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 QQnsmp29264 for ; Mon, 9 Dec 2002 13:46:57 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9Dl85t018241; Mon, 9 Dec 2002 08:47:09 -0500 (EST) Received: from eosborne-u10.cisco.com (eosborne-u10.cisco.com [161.44.134.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA20580; Mon, 9 Dec 2002 08:46:38 -0500 (EST) Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA04152; Mon, 9 Dec 2002 08:46:38 -0500 (EST) Date: Mon, 9 Dec 2002 08:46:38 -0500 From: Eric Osborne To: Jing Shen Cc: "Naidu, Venkata" , Eric Osborne , "J.C.Ramesh Babu" , mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: [MPLS-OPS]: Jitter and MPLS Message-ID: <20021209084638.D4090@eosborne-u10.cisco.com> References: <39469E08BD83D411A3D900204840EC55763471@VIE-MSGUSR-01> <3DF48F65.840949E1@cad.zju.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3DF48F65.840949E1@cad.zju.edu.cn>; from jshen@cad.zju.edu.cn on Mon, Dec 09, 2002 at 08:41:09PM +0800 X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk On Mon, Dec 09, 2002 at 08:41:09PM +0800, Jing Shen wrote: > It's main conclusion of our experiments that policy based routing must > be used with MPLS if e2e QoS is considered carefully. Why? eric > I agree with > Naidu that experiments with large scale network consisting of commercial > router/switch is needed to find out more details, as theoretical > analysis of e2e delay relates to same factor set in either MPLS or > IP network, Jitter relates closely to queueing mechanism, but also > accumulated processing overhead. > > there has been discussion on difference between MPLS-TE and IP-TE > on some other list, but I don't think IP-TE based only on traffic > metrix, > linear programing and policy database could be easily set up in > ISP networks, the obstacle exists with both traffic metix derivation, > optimization period and the policy dealing with broken links. > > OMP gives a good start on traffic engineering but its traffic division > policy is too simple for self-similar internet traffic. > > I have another question, is OMP implemented in some commerical products? > if not, why? > > The overprovisioning of network resource makes current network works > smooth > util I come to know that DVE works at Gbps bandwidth requiement. > > > > > > > I think your discussion is little deviated. What I understood > > from Jing's description is that, he didn't apply any form of TE > > (neither IP-TE nor MPLS-TE) in his network. Jing's measurements > > are based on straight line topology of 3 nodes, comparing IP and > > MPLS (forwarding) performance only. > > > > IMHO, in such a small topologies, the amortized performance > > improvements (overall gain of all operations in the worst case) > > may not be significant. > > > > In such straight line topologies (with out applying any form > > of queuing differentiation or some form of TE in the topology), > > I don't think MPLS out performs IP just because of MPLS > > fast forwarding nature (may be small amount of improvement). > > Remember that, there is no much difference between IP QoS techniques > > and MPLS QoS techniques (same classes, same queuing methodologies). > > The major difference between IP and MPLS is in TE techniques. > > > > This discussion reminds me of old draft: > > ftp://ftp.netlab.ohio-state.edu/pub/jain/ietf/draft-bhani-mpls-te-anal-00. > > txt > > Where, it is clearly shown that, there is a significant improvement > > in the throughput of the UDP & TCP flows when MPLS-TE is applied. > > > > However, can the same performance improvements are achieved using > > IP-TE methods (at least near to the performance of MPLS-TE) is > > still an open ended question? > > > > Some very interesting research has been done to prove the above > > question. But, "at what cost?", "with how much ease of configuration > > & maintenance?", "with what added benefits?" are still unanswered. > > > > Finally, I strongly feel that, the performance matrices change a lot > > from small topologies to real-complex topologies. We can't directly > > map the simulation results to real-world topologies. In any case, > > the average/amortized performance measurements & analysis of > > real-world complex topologies is not an easy task. If there is > > any such work, I will be very glad to know. > > > > Thank You. > > > > -- > > Venkata. > > -- > Jing Shen > > State Key Lab of CAD&CG > ZheJiang University(YuQuan) > HangZhou, Z.J. 310027 > P.R.China > > Tel: +86-571-87932423 > Mobile: (0)13516813753 > Email: jshen@cad.zju.edu.cn > > ********************************************************************** > * The SunShine of life is made up of very little beams which is * > * bright all the time * > ********************************************************************** From owner-mpls@UU.NET Mon Dec 9 09:01: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 JAA09645 for ; Mon, 9 Dec 2002 09:01: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 QQnsmq18470 for ; Mon, 9 Dec 2002 14:04: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 QQnsmp10288; Mon, 9 Dec 2002 13:59:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsmp18220 for mpls-outgoing; Mon, 9 Dec 2002 13:58: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 QQnsmp18199 for ; Mon, 9 Dec 2002 13:58:42 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 QQnsmp29313 for ; Mon, 9 Dec 2002 13:57:13 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 QQnsmp06980 for ; Mon, 9 Dec 2002 13:57:12 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 QQnsmp06972 for ; Mon, 9 Dec 2002 13:57:12 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9Dve5A019450 for ; Mon, 9 Dec 2002 08:57:41 -0500 (EST) 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 IAA21116 for ; Mon, 9 Dec 2002 08:57:10 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9DvA406717 for mpls@uu.net; Mon, 9 Dec 2002 08:57:10 -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 QQnsmp17837 for ; Mon, 9 Dec 2002 13:55:45 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 QQnsmp18084 for ; Mon, 9 Dec 2002 13:55:38 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 QQnsmp05565 for ; Mon, 9 Dec 2002 13:55:37 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 QQnsmp05561 for ; Mon, 9 Dec 2002 13:55:37 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9DtlUG019192; Mon, 9 Dec 2002 08:55:48 -0500 (EST) Received: from eosborne-u10.cisco.com (eosborne-u10.cisco.com [161.44.134.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA20997; Mon, 9 Dec 2002 08:55:16 -0500 (EST) Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA04164; Mon, 9 Dec 2002 08:55:16 -0500 (EST) Date: Mon, 9 Dec 2002 08:55:16 -0500 From: Eric Osborne To: Jing Shen Cc: alok , mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: [MPLS-OPS]: Jitter and MPLS Message-ID: <20021209085515.E4090@eosborne-u10.cisco.com> References: <085301c29d34$503954f0$a4c7fe87@ad.infosys.com> <20021206110156.O28607@eosborne-u10.cisco.com> <3DF1659A.978EE288@cad.zju.edu.cn> <20021207003312.U28607@eosborne-u10.cisco.com> <3DF1F42B.9513CCA0@cad.zju.edu.cn> <007f01c29e07$a1cb2540$81c802c0@alok> <3DF493E1.EC248723@cad.zju.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3DF493E1.EC248723@cad.zju.edu.cn>; from jshen@cad.zju.edu.cn on Mon, Dec 09, 2002 at 09:00:17PM +0800 X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk On Mon, Dec 09, 2002 at 09:00:17PM +0800, Jing Shen wrote: > alok, > > > > > > > I cant figure this point > > > > are you comparing ethernet--MPLS--IP--TCP frame with ethernet--IP--TCP > > frame? well then your frame size is larger....thats about the only > > difference i see. > > That's the reason. The reason why we take that is, we do not consider > MPLS as mechanism carrying TCP packet, and MPLS is to add new mechanism > to IP networks, so the overhead is considered to be the one affecting > throughput. If we want o compare payload of MPLS with payload of IP, > I can't find any acceptable parameters to be compared. > If you add 4 bytes to a packet, you've made the packet 4 bytes bigger, and increased delay because there are 4 more bytes to transmit. No argument there. Arguing that this has an impact on jitter is something I don't get (a given flow should always have the same additional label imposition delay, so 0 jitter), nor do I think it's reasonable to state that label imposition in the general case has any impact on delay other than the trans/prop delay of 4 extra bytes. As I've said again and again, if your implementation takes extra time to add labels to a packet, it's perfectly fair to profile _your implementation_, but there are ways to do label imposition such that the act of imposition itself take no extra time. Other than increased packet size, delay (and most certainly jitter!) are artifacts of an implementation. Do you agree? As far as comparing TCP/IP/MPLS/linklayer throughput vs. TCP/IP/linklayer throughput, I'm surprised you can't find any good mechanisms to measure there. Surely you can simply look at the size of the TCP windows, time to open up fully, and other such impacts on "goodput" that exist in the T/I/M/LL case and not the T/I/LL case? This seems to be a lot like comparing TCP/IP/PPP vs. TCP/IP/HDLC - you have the same underlying clock rate and the frames are different sizes - how does that affect TCP performance? eric > > > > > yes, but lets assume that u had a scenario where the MPLS+payload(be it IP > > of anything) was compared with IP+(payload) ...where payload is of equal > > size, then what is the result? do realise your switching on a smaller > > "label" than an whole IP address....and I also assume your switching table > > is not optimized for "aggregates etc"..it depends on your switching > > mechanism. > > > > We don't want to compare aggregation situation, but want to focus on > e2e performance difference. > > > > > > well, we put L2 headers in each hop too and in cases of ethernet/Multiaccess > > media, the L2 header depends on the next-hop... you would have ASICs doing > > it on the interface/FT. > > > > according to your logic, FR interfaces should give the same > > problem.....specially on MultiAccess topologies... > > > > > > [snip] > > > -- > Jing Shen > > State Key Lab of CAD&CG > ZheJiang University(YuQuan) > HangZhou, Z.J. 310027 > P.R.China > > Tel: +86-571-87932423 > Mobile: (0)13516813753 > Email: jshen@cad.zju.edu.cn > > ********************************************************************** > * The SunShine of life is made up of very little beams which is * > * bright all the time * > ********************************************************************** From owner-mpls@UU.NET Mon Dec 9 09:54:42 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 JAA11785 for ; Mon, 9 Dec 2002 09:54:42 -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 QQnsmt01850 for ; Mon, 9 Dec 2002 14:57:04 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 QQnsmt26723; Mon, 9 Dec 2002 14:54:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsmt12032 for mpls-outgoing; Mon, 9 Dec 2002 14:53:53 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 QQnsmt12027 for ; Mon, 9 Dec 2002 14:53: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 QQnsmt26318 for ; Mon, 9 Dec 2002 14:53:30 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 QQnsmt25124 for ; Mon, 9 Dec 2002 14:53:29 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 QQnsmt24907 for ; Mon, 9 Dec 2002 14:53:13 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9Erfn2027673 for ; Mon, 9 Dec 2002 09:53:42 -0500 (EST) 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 JAA24615 for ; Mon, 9 Dec 2002 09:53:11 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9ErBt13199 for mpls@uu.net; Mon, 9 Dec 2002 09:53:11 -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 QQnsgl00741 for ; Sat, 7 Dec 2002 21:57: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 QQnsgl28133 for ; Sat, 7 Dec 2002 21:55: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 QQnsgl10039 for ; Sat, 7 Dec 2002 21:55:01 GMT Received: from web14512.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web14512.mail.yahoo.com [216.136.227.51]) id QQnsgl10015 for ; Sat, 7 Dec 2002 21:55:01 GMT Message-ID: <20021207215500.74022.qmail@web14512.mail.yahoo.com> Received: from [130.65.88.107] by web14512.mail.yahoo.com via HTTP; Sat, 07 Dec 2002 13:55:00 PST Date: Sat, 7 Dec 2002 13:55:00 -0800 (PST) From: nitin p Subject: Re: [MPLS-OPS]: Jitter and MPLS To: Eric Osborne , Jing Shen Cc: Eric Osborne , "J.C.Ramesh Babu" , mpls-ops@mplsrc.com, mpls@UU.NET In-Reply-To: <20021207102048.W28607@eosborne-u10.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, Sorry for interrupting the discussion between Eric and Jing. Recently I have also measured the hop delay in the mpls-linux implementation of sourceforge.net. My results shows that delay at core (LSR) is less than that is observed in IP. Delay at egress(LER) delay in MPLS is slightly more than that in IP. But, delay at ingress(LER) is much more than tha in IP. With my results I can infer that in a network of 1000s(may be 100s) hops overall delay in MPLS will be less that that in IP, but for samaller networks MPLS results much more delay.I am not claiming that my results are applicable to commercial implementations, which might have good hardware support unlike my test where I have used PC. It makes sense that LERs will take more time than LSRs,but what I coudn't understand is the performance difference between Ingress and Egress. Any comments on this are most welcome. Thanks, Nitin --- Eric Osborne wrote: > On Sat, Dec 07, 2002 at 09:14:19PM +0800, Jing Shen > wrote: > > Thanks for Eric's comment. And, read my comment in > line please. > > > > > > > > 1) TCP throughput of MPLS is a little > smaller than IP when path MTU is > > > > the same. > > > > and difference increases when path MTU > decreases. > > > > > > MPLS packets are 4 bytes (or more) bigger than > IP packets. If you do > > > not allow for this in your link MTU, then you > have smaller effective > > > bandwidth inside TCP. Allow for that in your > link MTU (as any > > > reasonable implementation should) and you don't > have this problem. > > > > Yes. We notice that at the first stage of our > implementation and then we > > modify the engine to allow for such situation. Our > implementation allows > > for a label stack with depth of 8, and we use only > one. But, that do has > > effect on TCP throughput if the same path is taken > by IP and MPLS. > > > > Have you been able to determine what made this > impact? If your TCP > segments can open up to the same size under both > MPLS and IP, then all > you add is another 4 bytes of transmission delay, > which should be so > close to zero it's inconsequential. And if > everything has this small > additional delay, then that should in no way create > jitter in the > network. > > > > > > So this is a test of your forwarding equipment. > Equipment which takes > > > zero or negligible time to perform this > encap/decap will not have this > > > problem. > > > > As I know some of manufacturers announce that > their router/switch > > could operate at line speed, and the latency in a > switch is > > negeligible. But, what about situation of heavy > load? The ability > > of a linux based forwarding engine is surely not > at the same level > > of any hardware based product, but to my personal > opinion any > > comparation should be taken at the same situation > ( hardware, > > software etc). > > A switch that operates at line rate can still do so > under heavy load. > There are well-known mechanisms (DiffServ) for > controlling performance > under heavy load. Theoretically, there should be no > difference in the > performance of DiffServ whether applied to IP, MPLS, > or for that > matter, Appletalk, IPX, or any other switched packet > technology. If > you have found a platform-independent issue inherent > to MPLS that > causes jitter, I am very interested in seeing it. > > > Another reason is that we try to find out how > MPLS compares with IP > > when realtime multimedia content is loaded. The > bandwidth > > requirement of realtime distributed virtual > reality system is at the > > level of Gbps, and that value may increase when > number of people > > participating increases. So, we want to measure > the situation that > > accumulated dec/enc time is not negligible. > > OK, that's a fair thing to want to measure. But > again, you're testing > a specific implementation, and it's not reasonable > to extend that > comparison to any broader scope. > > > > > Well, if R12000 is as cheap as 2511 that's not a > question at all :-) > > > > OK, if you want to talk specific router models, let > me speak to the > ones I know best. :) A 12k and a 2500[*] are > different. They perform > differently, are priced differently, and have > different interfaces and > capabilities. I would never do forwarding > performance tests on a 2500 > and claim the 12k behaves the same way, nor would I > do tests on 12k > forwarding and claim the 2500 performed the same > way. By the same > token, you can't test a Linux forwarding > implementation (a lot like a > really fast 2500) and claim that its performance is > the same as any > other router maker. > > [*] - sidebar to the viewing audience - a 12k (GSR) > is a Really Big > router, and a 2500 is a Really Small router. > > > > > Although we have not experimented with > Cisco's express forwarding > > > > and the like, and we do not experiment with > large scale system with > > > > real internet traffic pattern, we concern that > the result could > > > > applied to large scale network. > > > > > > I'm concerned about that too, because it means > that you're building a > > > large-scale network out of Linux-based > software-forwarding devices. > > > But even if you do have a performance hit at > encap/decap, you only do > > > label push/pop at the edges of the network, so > you'd only take this > > > hypothetical hit at the edges, making scale a > nonissue for your > > > particular imaginary problem. > > > > > > > I'm sorry I means label stack operation by > encap/decap. That is done at > > each hop. As I mentioned above, if the load is > light there is no > > difference > > but when the load is heavy the difference comes > up. > > Then what you're testing is the per-hop performance > hit taken by label > swapping. This is, again, very > implementation-dependent. In MPLS > forwarding you have to do a label lookup and label > swap, in IP you > have to do a FIB lookup. Whether these two are the > same speed, > insignificantly different, or significantly > different is a > platform-specific thing. > > > > > > 2) we focus on forwarding difference between > IP and MPLS, and we > > > > think technique like CEF and per-port cache > could be applied to both > > > > technologies. > > > > > > The fact that you're considering different > lookup methodologies for IP > > > and MPLS suggests even further that what you're > profiling is your > > > implementation, and not either > > > a) a purely hypothetical > situation (a la OPnet or > > > whatever) > > > b) a particular router > implementation > > > > I agree with you that there is difference between > lookup method > > between IP routing and MPLS switching, this may > introduce some > > performance difference. > > Right, but like I said above, the switching > mechanism is not a > function inherent to the protocol. > > > > > > > > I have no problem with you testing your own > implementation; I have a > > > major issue if you try to generalize those > results to claim that your > > > specific behavior is in fact an artifact of the > protocol itself. > > > > === message truncated === __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From owner-mpls@UU.NET Mon Dec 9 09:56: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 JAA11886 for ; Mon, 9 Dec 2002 09:56:15 -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 QQnsmt07246 for ; Mon, 9 Dec 2002 14:59: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 QQnsmt03371; Mon, 9 Dec 2002 14:56:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsmt12317 for mpls-outgoing; Mon, 9 Dec 2002 14:56: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 QQnsmt12277 for ; Mon, 9 Dec 2002 14:56: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 QQnsmt23255 for ; Mon, 9 Dec 2002 14:55: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 QQnsmt26595 for ; Mon, 9 Dec 2002 14:55:17 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 QQnsmt26575 for ; Mon, 9 Dec 2002 14:55:16 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9EtfqL028012 for ; Mon, 9 Dec 2002 09:55:41 -0500 (EST) 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 JAA24815 for ; Mon, 9 Dec 2002 09:55:11 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9EtAw13325 for mpls@uu.net; Mon, 9 Dec 2002 09:55:10 -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 QQnskg01178 for ; Sun, 8 Dec 2002 22:34: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 QQnskg06170 for ; Sun, 8 Dec 2002 22:34: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 QQnskg28471 for ; Sun, 8 Dec 2002 22:34:13 GMT Received: from web14511.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web14511.mail.yahoo.com [216.136.226.29]) id QQnskg28465 for ; Sun, 8 Dec 2002 22:34:12 GMT Message-ID: <20021208223411.26669.qmail@web14511.mail.yahoo.com> Received: from [130.65.88.109] by web14511.mail.yahoo.com via HTTP; Sun, 08 Dec 2002 14:34:11 PST Date: Sun, 8 Dec 2002 14:34:11 -0800 (PST) From: nitin p Subject: Re: [MPLS-OPS]: Jitter and MPLS To: "Gopal@Yahoo" , Eric Osborne , Jing Shen Cc: Eric Osborne , "J.C.Ramesh Babu" , mpls-ops@mplsrc.com, mpls@UU.NET In-Reply-To: <20021208205359.30244.qmail@web20513.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Gopal, Thanks for clearing me on this. What makes me still wondered is the huge difference between these two values. Ok I will mention my results: Ingress: 3.665 milli seconds Egress: 0.035 milliseconds core: 0.018 milliseconds IP: 0.023 milliseconds. Now at ingress, if I assume both L3 lookup + L2.5 forwarding, it doesn't explain me why this value is so high. What else can happen at Ingress which is causing this huge delay ? Probably I should dig into code and find out :) Can you please explain, what is aggregation prefix?, has it to do anything Penultimate Hop Popping(PHP). As far as I know my code doesn't support PHP. Your comments on this will be highly appreciated. Thanks, Nitin --- "Gopal@Yahoo" wrote: > Nitin, > Theoritcal difference btw forwarding operation of > Ingress LER and Egress LER is: > Ingress LER: L3 lookup necessary. Depending on the > implementation, the packet may have to go thru (or > use) both 'ip forwarding engine/process' and the > 'tag > forwarding engine/process'. > > Egress LER: L3 lookup not necessary (exception for > aggregate prefix). 'tag forwaridng engine' can do > the > job with the Label lookup. > > Because of the above difference in some > implementations overhead on Ingress and egress may > be > different. > rgds, > gopal > > --- nitin p wrote: > > Hi, > > Sorry for interrupting the discussion between Eric > > and > > Jing. > > > > Recently I have also measured the hop delay in the > > mpls-linux implementation of sourceforge.net. > > > > My results shows that delay at core (LSR) is less > > than > > that is observed in IP. > > Delay at egress(LER) delay in MPLS is slightly > more > > than that in IP. > > But, delay at ingress(LER) is much more than tha > in > > IP. > > > > With my results I can infer that in a network of > > 1000s(may be 100s) hops overall delay in MPLS will > > be > > less that that in IP, but for samaller networks > MPLS > > results much more delay.I am not claiming that my > > results are applicable to commercial > > implementations, > > which might have good hardware support unlike my > > test > > where I have used PC. > > It makes sense that LERs will take more time than > > LSRs,but what I coudn't understand is the > > performance > > difference between Ingress and Egress. > > > > Any comments on this are most welcome. > > Thanks, > > Nitin > > > > > > --- Eric Osborne wrote: > > > On Sat, Dec 07, 2002 at 09:14:19PM +0800, Jing > > Shen > > > wrote: > > > > Thanks for Eric's comment. And, read my > comment > > in > > > line please. > > > > > > > > > > > > > > 1) TCP throughput of MPLS is a little > > > smaller than IP when path MTU is > > > > > > the same. > > > > > > and difference increases when path > MTU > > > decreases. > > > > > > > > > > MPLS packets are 4 bytes (or more) bigger > than > > > IP packets. If you do > > > > > not allow for this in your link MTU, then > you > > > have smaller effective > > > > > bandwidth inside TCP. Allow for that in > your > > > link MTU (as any > > > > > reasonable implementation should) and you > > don't > > > have this problem. > > > > > > > > Yes. We notice that at the first stage of our > > > implementation and then we > > > > modify the engine to allow for such situation. > > Our > > > implementation allows > > > > for a label stack with depth of 8, and we use > > only > > > one. But, that do has > > > > effect on TCP throughput if the same path is > > taken > > > by IP and MPLS. > > > > > > > > > > Have you been able to determine what made this > > > impact? If your TCP > > > segments can open up to the same size under both > > > MPLS and IP, then all > > > you add is another 4 bytes of transmission > delay, > > > which should be so > > > close to zero it's inconsequential. And if > > > everything has this small > > > additional delay, then that should in no way > > create > > > jitter in the > > > network. > > > > > > > > > > > > So this is a test of your forwarding > > equipment. > > > Equipment which takes > > > > > zero or negligible time to perform this > > > encap/decap will not have this > > > > > problem. > > > > > > > > As I know some of manufacturers announce that > > > their router/switch > > > > could operate at line speed, and the latency > in > > a > > > switch is > > > > negeligible. But, what about situation of > heavy > > > load? The ability > > > > of a linux based forwarding engine is surely > not > > > at the same level > > > > of any hardware based product, but to my > > personal > > > opinion any > > > > comparation should be taken at the same > > situation > > > ( hardware, > > > > software etc). > > > > > > A switch that operates at line rate can still do > > so > > > under heavy load. > > > There are well-known mechanisms (DiffServ) for > > > controlling performance > > > under heavy load. Theoretically, there should > be > > no > > > difference in the > > > performance of DiffServ whether applied to IP, > > MPLS, > > > or for that > > > matter, Appletalk, IPX, or any other switched > > packet > > > technology. If > > > you have found a platform-independent issue > > inherent > > > to MPLS that > > > causes jitter, I am very interested in seeing > it. > > > > > > > Another reason is that we try to find out how > > > MPLS compares with IP > > > > when realtime multimedia content is loaded. > The > > > bandwidth > > > > requirement of realtime distributed virtual > > > reality system is at the > > > > level of Gbps, and that value may increase > when > > > number of people > > > > participating increases. So, we want to > measure > > > the situation that > > > > accumulated dec/enc time is not negligible. > > > > > > OK, that's a fair thing to want to measure. But > > > again, you're testing > > > a specific implementation, and it's not > reasonable > > > to extend that > > > comparison to any broader scope. > > > > > > > > > > > Well, if R12000 is as cheap as 2511 that's not > a > > > question at all :-) > > > > > > > > > > OK, if you want to talk specific router models, > > let > > > me speak to the > > > ones I know best. :) A 12k and a 2500[*] are > > > different. They perform > > > differently, are priced differently, and have > === message truncated === __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From owner-mpls@UU.NET Mon Dec 9 09:58: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 JAA11959 for ; Mon, 9 Dec 2002 09:58:35 -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 QQnsmu03558 for ; Mon, 9 Dec 2002 15:01:26 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 QQnsmt00846; Mon, 9 Dec 2002 14:59:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsmt12671 for mpls-outgoing; Mon, 9 Dec 2002 14:58:49 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 QQnsmt12556 for ; Mon, 9 Dec 2002 14:57:44 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 QQnsmt05208 for ; Mon, 9 Dec 2002 14:57:25 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 QQnsmt28146 for ; Mon, 9 Dec 2002 14:57:25 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 QQnsmt28137 for ; Mon, 9 Dec 2002 14:57:24 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9EvrAE028377 for ; Mon, 9 Dec 2002 09:57:53 -0500 (EST) 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 JAA24993 for ; Mon, 9 Dec 2002 09:57:23 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9EvNY13622 for mpls@uu.net; Mon, 9 Dec 2002 09:57:23 -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 QQnsmq05757 for ; Mon, 9 Dec 2002 14:04: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 QQnsmq15365 for ; Mon, 9 Dec 2002 14:03:24 GMT From: GAlmaalouf@aol.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 QQnsmq27977 for ; Mon, 9 Dec 2002 14:03:23 GMT Received: from imo-m05.mx.aol.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imo-m05.mx.aol.com [64.12.136.8]) id QQnsmq27972 for ; Mon, 9 Dec 2002 14:03:23 GMT Received: from GAlmaalouf@aol.com by imo-m05.mx.aol.com (mail_out_v34.13.) id r.104.217abc80 (26116); Mon, 9 Dec 2002 09:01:06 -0500 (EST) Message-ID: <104.217abc80.2b25fc22@aol.com> Date: Mon, 9 Dec 2002 09:01:06 EST Subject: Re: [MPLS-OPS]: Jitter and MPLS To: nitin_panj@yahoo.com, eosborne@cisco.com, jshen@cad.zju.edu.cn CC: rameshbabu_j@infosys.com, mpls-ops@mplsrc.com, mpls@UU.NET MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_104.217abc80.2b25fc22_boundary" X-Mailer: AOL 8.0 for Windows US sub 230 Sender: owner-mpls@UU.NET Precedence: bulk --part1_104.217abc80.2b25fc22_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Nitin- It would be much helpful if you can specify the delay in a quantitative manner. This way we can really understand what are you talking about in term of delays. Also, the specific number of Hops or LPS router, how many egress and ingress steps involved in the calculation. A general observation would not be very accurate, since the implementation would be very different from one application versus the other, and from one type of services versus another. Thanks- George --part1_104.217abc80.2b25fc22_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit Nitin-

It would be much helpful if you can specify the delay in a quantitative manner. This way we can really understand what are you talking about in term of delays.  Also, the specific number of Hops or LPS router, how many egress and ingress steps involved in the calculation. A general observation would not  be very accurate, since the implementation would be very different from one application versus the other, and from one type of services versus another.

Thanks-

George


 --part1_104.217abc80.2b25fc22_boundary-- From owner-mpls@UU.NET Mon Dec 9 10:04: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 KAA12227 for ; Mon, 9 Dec 2002 10:04:24 -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 QQnsmu20423 for ; Mon, 9 Dec 2002 15:07:12 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 QQnsmu14262; Mon, 9 Dec 2002 15:03:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsmt12698 for mpls-outgoing; Mon, 9 Dec 2002 14:59:02 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 QQnsmt12462 for ; Mon, 9 Dec 2002 14:57:23 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 QQnsmt27185 for ; Mon, 9 Dec 2002 14:56: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 QQnsmt27768 for ; Mon, 9 Dec 2002 14:56:51 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 QQnsmt27759 for ; Mon, 9 Dec 2002 14:56:51 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9EvKjR028294 for ; Mon, 9 Dec 2002 09:57:20 -0500 (EST) 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 JAA24954 for ; Mon, 9 Dec 2002 09:56:50 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9Euog13474 for mpls@uu.net; Mon, 9 Dec 2002 09:56:50 -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 QQnsmf29187 for ; Mon, 9 Dec 2002 11:26:30 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 QQnsmf11746 for ; Mon, 9 Dec 2002 11:25: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 QQnsmf10156 for ; Mon, 9 Dec 2002 11:25:53 GMT Received: from www.apara.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.106.140.220]) id QQnsmf10143 for ; Mon, 9 Dec 2002 11:25:53 GMT Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id gB9Bf5M30307 for ; Mon, 9 Dec 2002 17:11:05 +0530 Received: from alok ([203.124.140.100]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id gB9BeuT30278; Mon, 9 Dec 2002 17:10:56 +0530 Message-ID: <02ff01c29f76$ec1bd700$81c802c0@alok> From: "alok" To: "Gopal@Yahoo" , "nitin p" , "Eric Osborne" , "Jing Shen" Cc: "Eric Osborne" , "J.C.Ramesh Babu" , , References: <20021208205359.30244.qmail@web20513.mail.yahoo.com> Subject: Re: [MPLS-OPS]: Jitter and MPLS Date: Mon, 9 Dec 2002 17:04:05 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, sorry but im kindof lost on this bit..would appreciate if you could clarify the same, inline... > Nitin, > Theoritcal difference btw forwarding operation of > Ingress LER and Egress LER is: > Ingress LER: L3 lookup necessary. Depending on the > implementation, the packet may have to go thru (or > use) both 'ip forwarding engine/process' and the 'tag > forwarding engine/process'. > so on the ingress LER, in the fwding table it would be more of "incoming interface---destn-ip(till here to be matched)---tag label to be put while outgoing -- outgoing interface" wouldnt it? so essentially are u saying that this makes it slower? the 1st part is the indexing part (till to be matched), the other is the action.... on the P routers u have FT as: "incoming interface---label (till here to be matched)---outgoing label and interface" > Egress LER: L3 lookup not necessary (exception for > aggregate prefix). 'tag forwaridng engine' can do the > job with the Label lookup. on the egress FT entry to match on looks like : "incoming interface--label--destn-subnet-1(to be matched)--outgoing interface" "incoming interface--label--destn-subnet-2(to be matched)--outgoing interface" if your saying i have a supernet advertised via MiBGP to the remote end hence traffic for both come in with 1 label, i need to do a specific network route lookup, after i get the packet on egress.....right? if the table looks like above, why do u say that this would be a problem? (be it hash or trees or whatever algo) am i missing something? i actually dont know how typical ASICs split that functionality (i mean how do u represent interface--and ip and label part etc" in the FT...but assuming u even make a simple hash on that combo..i think its close enuf to assume each entry wud be unique, even if different parameters are involved... not too sure abt that bit, wud be great if someone could clarify... -rgds Alok > > Because of the above difference in some > implementations overhead on Ingress and egress may be > different. > rgds, > gopal > > --- nitin p wrote: > > Hi, > > Sorry for interrupting the discussion between Eric > > and > > Jing. > > > > Recently I have also measured the hop delay in the > > mpls-linux implementation of sourceforge.net. > > > > My results shows that delay at core (LSR) is less > > than > > that is observed in IP. > > Delay at egress(LER) delay in MPLS is slightly more > > than that in IP. > > But, delay at ingress(LER) is much more than tha in > > IP. > > > > With my results I can infer that in a network of > > 1000s(may be 100s) hops overall delay in MPLS will > > be > > less that that in IP, but for samaller networks MPLS > > results much more delay.I am not claiming that my > > results are applicable to commercial > > implementations, > > which might have good hardware support unlike my > > test > > where I have used PC. > > It makes sense that LERs will take more time than > > LSRs,but what I coudn't understand is the > > performance > > difference between Ingress and Egress. > > > > Any comments on this are most welcome. > > Thanks, > > Nitin > > > > > > --- Eric Osborne wrote: > > > On Sat, Dec 07, 2002 at 09:14:19PM +0800, Jing > > Shen > > > wrote: > > > > Thanks for Eric's comment. And, read my comment > > in > > > line please. > > > > > > > > > > > > > > 1) TCP throughput of MPLS is a little > > > smaller than IP when path MTU is > > > > > > the same. > > > > > > and difference increases when path MTU > > > decreases. > > > > > > > > > > MPLS packets are 4 bytes (or more) bigger than > > > IP packets. If you do > > > > > not allow for this in your link MTU, then you > > > have smaller effective > > > > > bandwidth inside TCP. Allow for that in your > > > link MTU (as any > > > > > reasonable implementation should) and you > > don't > > > have this problem. > > > > > > > > Yes. We notice that at the first stage of our > > > implementation and then we > > > > modify the engine to allow for such situation. > > Our > > > implementation allows > > > > for a label stack with depth of 8, and we use > > only > > > one. But, that do has > > > > effect on TCP throughput if the same path is > > taken > > > by IP and MPLS. > > > > > > > > > > Have you been able to determine what made this > > > impact? If your TCP > > > segments can open up to the same size under both > > > MPLS and IP, then all > > > you add is another 4 bytes of transmission delay, > > > which should be so > > > close to zero it's inconsequential. And if > > > everything has this small > > > additional delay, then that should in no way > > create > > > jitter in the > > > network. > > > > > > > > > > > > So this is a test of your forwarding > > equipment. > > > Equipment which takes > > > > > zero or negligible time to perform this > > > encap/decap will not have this > > > > > problem. > > > > > > > > As I know some of manufacturers announce that > > > their router/switch > > > > could operate at line speed, and the latency in > > a > > > switch is > > > > negeligible. But, what about situation of heavy > > > load? The ability > > > > of a linux based forwarding engine is surely not > > > at the same level > > > > of any hardware based product, but to my > > personal > > > opinion any > > > > comparation should be taken at the same > > situation > > > ( hardware, > > > > software etc). > > > > > > A switch that operates at line rate can still do > > so > > > under heavy load. > > > There are well-known mechanisms (DiffServ) for > > > controlling performance > > > under heavy load. Theoretically, there should be > > no > > > difference in the > > > performance of DiffServ whether applied to IP, > > MPLS, > > > or for that > > > matter, Appletalk, IPX, or any other switched > > packet > > > technology. If > > > you have found a platform-independent issue > > inherent > > > to MPLS that > > > causes jitter, I am very interested in seeing it. > > > > > > > Another reason is that we try to find out how > > > MPLS compares with IP > > > > when realtime multimedia content is loaded. The > > > bandwidth > > > > requirement of realtime distributed virtual > > > reality system is at the > > > > level of Gbps, and that value may increase when > > > number of people > > > > participating increases. So, we want to measure > > > the situation that > > > > accumulated dec/enc time is not negligible. > > > > > > OK, that's a fair thing to want to measure. But > > > again, you're testing > > > a specific implementation, and it's not reasonable > > > to extend that > > > comparison to any broader scope. > > > > > > > > > > > Well, if R12000 is as cheap as 2511 that's not a > > > question at all :-) > > > > > > > > > > OK, if you want to talk specific router models, > > let > > > me speak to the > > > ones I know best. :) A 12k and a 2500[*] are > > > different. They perform > > > differently, are priced differently, and have > > > different interfaces and > > > capabilities. I would never do forwarding > > > performance tests on a 2500 > > > and claim the 12k behaves the same way, nor would > > I > > > do tests on 12k > > > forwarding and claim the 2500 performed the same > > > way. By the same > > > token, you can't test a Linux forwarding > > > implementation (a lot like a > > > really fast 2500) and claim that its performance > > is > > > the same as any > > > other router maker. > > > > > > [*] - sidebar to the viewing audience - a 12k > > (GSR) > > > is a Really Big > > > router, and a 2500 is a Really Small router. > > > > > > > > > Although we have not experimented with > > > Cisco's express forwarding > > > > > > and the like, and we do not experiment with > > > large scale system with > > > > > > real internet traffic pattern, we concern > > that > > > the result could > > > > > > applied to large scale network. > > > > > > > > > > I'm concerned about that too, because it means > > > that you're building a > > > > > large-scale network out of Linux-based > > > software-forwarding devices. > > > > > But even if you do have a performance hit at > > > encap/decap, you only do > > > > > label push/pop at the edges of the network, so > > > you'd only take this > > > > > hypothetical hit at the edges, making scale a > > > nonissue for your > > > > > particular imaginary problem. > > > > > > > > === message truncated === > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > > ------- > The MPLS-OPS Mailing List > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > From owner-mpls@UU.NET Mon Dec 9 10:05:44 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 KAA12318 for ; Mon, 9 Dec 2002 10:05:44 -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 QQnsmu22776 for ; Mon, 9 Dec 2002 15:08: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 QQnsmu08526; Mon, 9 Dec 2002 15:00:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsmt12684 for mpls-outgoing; Mon, 9 Dec 2002 14:58:53 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 QQnsmt12591 for ; Mon, 9 Dec 2002 14:58:13 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 QQnsmt10331 for ; Mon, 9 Dec 2002 14:57: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 QQnsmt28447 for ; Mon, 9 Dec 2002 14:57:49 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 QQnsmt28440 for ; Mon, 9 Dec 2002 14:57:48 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9EwG4d028431 for ; Mon, 9 Dec 2002 09:58:16 -0500 (EST) 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 JAA25018 for ; Mon, 9 Dec 2002 09:57:46 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9EvjC13631 for mpls@uu.net; Mon, 9 Dec 2002 09:57:45 -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 QQnsmq06337 for ; Mon, 9 Dec 2002 14:05:04 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 QQnsmq19190 for ; Mon, 9 Dec 2002 14:04: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 QQnsmq19956 for ; Mon, 9 Dec 2002 14:04:53 GMT Received: from web14505.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web14505.mail.yahoo.com [216.136.224.68]) id QQnsmq19922 for ; Mon, 9 Dec 2002 14:04:52 GMT Message-ID: <20021209140451.91166.qmail@web14505.mail.yahoo.com> Received: from [130.65.88.102] by web14505.mail.yahoo.com via HTTP; Mon, 09 Dec 2002 06:04:51 PST Date: Mon, 9 Dec 2002 06:04:51 -0800 (PST) From: nitin p Subject: Re: [MPLS-OPS]: Jitter and MPLS To: jshen@cad.zju.edu.cn Cc: "Gopal@Yahoo" , Eric Osborne , "J.C.Ramesh Babu" , mpls-ops@mplsrc.com, mpls@UU.NET In-Reply-To: <3DF48396.494EBECA@cad.zju.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Jing, --- Jing Shen wrote: > nitin, > > I suggest you to dig into the code or contact Leu. > Our implementation generates nearly the same delay > when acting as either Ingree or Egress. > > Is there any on-demand switching enabled? I couldn' get what you mean by on-demand switching NItin > > > > > > > Gopal, > > Thanks for clearing me on this. What makes me > still > > wondered is the huge difference between these two > > values. Ok I will mention my results: > > > > Ingress: 3.665 milli seconds > > Egress: 0.035 milliseconds > > core: 0.018 milliseconds > > > > IP: 0.023 milliseconds. > > > > Now at ingress, if I assume both L3 lookup + L2.5 > > forwarding, it doesn't explain me why this value > is so > > high. What else can happen at Ingress which is > causing > > this huge delay ? Probably I should dig into code > and > > find out :) > > > > Can you please explain, what is aggregation > prefix?, > > has it to do anything Penultimate Hop > Popping(PHP). As > > far as I know my code doesn't support PHP. > > > > Your comments on this will be highly appreciated. > > > > Thanks, > > Nitin > > -- > Jing Shen > > State Key Lab of CAD&CG > ZheJiang University(YuQuan) > HangZhou, Z.J. 310027 > P.R.China > > Tel: +86-571-87932423 > Mobile: (0)13516813753 > Email: jshen@cad.zju.edu.cn > > ********************************************************************** > * The SunShine of life is made up of very little > beams which is * > * bright all the time > * > ********************************************************************** __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From owner-mpls@UU.NET Mon Dec 9 10:07: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 KAA12420 for ; Mon, 9 Dec 2002 10:07: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 QQnsmu25885 for ; Mon, 9 Dec 2002 15:10:17 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 QQnsmt01607; Mon, 9 Dec 2002 14:56:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsmt12321 for mpls-outgoing; Mon, 9 Dec 2002 14:56: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 QQnsmt12205 for ; Mon, 9 Dec 2002 14:56:05 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 QQnsmt27310 for ; Mon, 9 Dec 2002 14:55:01 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 QQnsmt26226 for ; Mon, 9 Dec 2002 14:55:01 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 QQnsmt26218 for ; Mon, 9 Dec 2002 14:55:00 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9EtSe7027955 for ; Mon, 9 Dec 2002 09:55:29 -0500 (EST) 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 JAA24804 for ; Mon, 9 Dec 2002 09:54:58 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9EswA13282 for mpls@uu.net; Mon, 9 Dec 2002 09:54:58 -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 QQnsjz17139 for ; Sun, 8 Dec 2002 20:55:54 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 QQnsjz13017 for ; Sun, 8 Dec 2002 20:54:01 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 QQnsjz14189 for ; Sun, 8 Dec 2002 20:54:00 GMT Received: from web20513.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web20513.mail.yahoo.com [216.136.174.44]) id QQnsjz14171 for ; Sun, 8 Dec 2002 20:54:00 GMT Message-ID: <20021208205359.30244.qmail@web20513.mail.yahoo.com> Received: from [128.107.253.42] by web20513.mail.yahoo.com via HTTP; Sun, 08 Dec 2002 12:53:59 PST Date: Sun, 8 Dec 2002 12:53:59 -0800 (PST) From: "Gopal@Yahoo" Subject: Re: [MPLS-OPS]: Jitter and MPLS To: nitin p , Eric Osborne , Jing Shen Cc: Eric Osborne , "J.C.Ramesh Babu" , mpls-ops@mplsrc.com, mpls@UU.NET In-Reply-To: <20021207215500.74022.qmail@web14512.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Nitin, Theoritcal difference btw forwarding operation of Ingress LER and Egress LER is: Ingress LER: L3 lookup necessary. Depending on the implementation, the packet may have to go thru (or use) both 'ip forwarding engine/process' and the 'tag forwarding engine/process'. Egress LER: L3 lookup not necessary (exception for aggregate prefix). 'tag forwaridng engine' can do the job with the Label lookup. Because of the above difference in some implementations overhead on Ingress and egress may be different. rgds, gopal --- nitin p wrote: > Hi, > Sorry for interrupting the discussion between Eric > and > Jing. > > Recently I have also measured the hop delay in the > mpls-linux implementation of sourceforge.net. > > My results shows that delay at core (LSR) is less > than > that is observed in IP. > Delay at egress(LER) delay in MPLS is slightly more > than that in IP. > But, delay at ingress(LER) is much more than tha in > IP. > > With my results I can infer that in a network of > 1000s(may be 100s) hops overall delay in MPLS will > be > less that that in IP, but for samaller networks MPLS > results much more delay.I am not claiming that my > results are applicable to commercial > implementations, > which might have good hardware support unlike my > test > where I have used PC. > It makes sense that LERs will take more time than > LSRs,but what I coudn't understand is the > performance > difference between Ingress and Egress. > > Any comments on this are most welcome. > Thanks, > Nitin > > > --- Eric Osborne wrote: > > On Sat, Dec 07, 2002 at 09:14:19PM +0800, Jing > Shen > > wrote: > > > Thanks for Eric's comment. And, read my comment > in > > line please. > > > > > > > > > > > 1) TCP throughput of MPLS is a little > > smaller than IP when path MTU is > > > > > the same. > > > > > and difference increases when path MTU > > decreases. > > > > > > > > MPLS packets are 4 bytes (or more) bigger than > > IP packets. If you do > > > > not allow for this in your link MTU, then you > > have smaller effective > > > > bandwidth inside TCP. Allow for that in your > > link MTU (as any > > > > reasonable implementation should) and you > don't > > have this problem. > > > > > > Yes. We notice that at the first stage of our > > implementation and then we > > > modify the engine to allow for such situation. > Our > > implementation allows > > > for a label stack with depth of 8, and we use > only > > one. But, that do has > > > effect on TCP throughput if the same path is > taken > > by IP and MPLS. > > > > > > > Have you been able to determine what made this > > impact? If your TCP > > segments can open up to the same size under both > > MPLS and IP, then all > > you add is another 4 bytes of transmission delay, > > which should be so > > close to zero it's inconsequential. And if > > everything has this small > > additional delay, then that should in no way > create > > jitter in the > > network. > > > > > > > > > So this is a test of your forwarding > equipment. > > Equipment which takes > > > > zero or negligible time to perform this > > encap/decap will not have this > > > > problem. > > > > > > As I know some of manufacturers announce that > > their router/switch > > > could operate at line speed, and the latency in > a > > switch is > > > negeligible. But, what about situation of heavy > > load? The ability > > > of a linux based forwarding engine is surely not > > at the same level > > > of any hardware based product, but to my > personal > > opinion any > > > comparation should be taken at the same > situation > > ( hardware, > > > software etc). > > > > A switch that operates at line rate can still do > so > > under heavy load. > > There are well-known mechanisms (DiffServ) for > > controlling performance > > under heavy load. Theoretically, there should be > no > > difference in the > > performance of DiffServ whether applied to IP, > MPLS, > > or for that > > matter, Appletalk, IPX, or any other switched > packet > > technology. If > > you have found a platform-independent issue > inherent > > to MPLS that > > causes jitter, I am very interested in seeing it. > > > > > Another reason is that we try to find out how > > MPLS compares with IP > > > when realtime multimedia content is loaded. The > > bandwidth > > > requirement of realtime distributed virtual > > reality system is at the > > > level of Gbps, and that value may increase when > > number of people > > > participating increases. So, we want to measure > > the situation that > > > accumulated dec/enc time is not negligible. > > > > OK, that's a fair thing to want to measure. But > > again, you're testing > > a specific implementation, and it's not reasonable > > to extend that > > comparison to any broader scope. > > > > > > > > Well, if R12000 is as cheap as 2511 that's not a > > question at all :-) > > > > > > > OK, if you want to talk specific router models, > let > > me speak to the > > ones I know best. :) A 12k and a 2500[*] are > > different. They perform > > differently, are priced differently, and have > > different interfaces and > > capabilities. I would never do forwarding > > performance tests on a 2500 > > and claim the 12k behaves the same way, nor would > I > > do tests on 12k > > forwarding and claim the 2500 performed the same > > way. By the same > > token, you can't test a Linux forwarding > > implementation (a lot like a > > really fast 2500) and claim that its performance > is > > the same as any > > other router maker. > > > > [*] - sidebar to the viewing audience - a 12k > (GSR) > > is a Really Big > > router, and a 2500 is a Really Small router. > > > > > > > Although we have not experimented with > > Cisco's express forwarding > > > > > and the like, and we do not experiment with > > large scale system with > > > > > real internet traffic pattern, we concern > that > > the result could > > > > > applied to large scale network. > > > > > > > > I'm concerned about that too, because it means > > that you're building a > > > > large-scale network out of Linux-based > > software-forwarding devices. > > > > But even if you do have a performance hit at > > encap/decap, you only do > > > > label push/pop at the edges of the network, so > > you'd only take this > > > > hypothetical hit at the edges, making scale a > > nonissue for your > > > > particular imaginary problem. > > > > > === message truncated === __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From owner-mpls@UU.NET Mon Dec 9 10:08: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 KAA12445 for ; Mon, 9 Dec 2002 10:08: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 QQnsmu20385 for ; Mon, 9 Dec 2002 15:10: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 QQnsmu07498; Mon, 9 Dec 2002 15:03:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsmu16628 for mpls-outgoing; Mon, 9 Dec 2002 15:01:03 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 QQnsmu15309 for ; Mon, 9 Dec 2002 15:00:32 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 QQnsmt03419 for ; Mon, 9 Dec 2002 14:59:10 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 QQnsmt29795 for ; Mon, 9 Dec 2002 14:59:09 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 QQnsmt29770 for ; Mon, 9 Dec 2002 14:59:09 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9Exbkp028718 for ; Mon, 9 Dec 2002 09:59:37 -0500 (EST) 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 JAA25109 for ; Mon, 9 Dec 2002 09:59:07 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9Ex7X13798 for mpls@uu.net; Mon, 9 Dec 2002 09:59:07 -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 QQnsmt12360 for ; Mon, 9 Dec 2002 14:56:42 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 QQnsmt25520 for ; Mon, 9 Dec 2002 14:56:15 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 QQnsmt27265 for ; Mon, 9 Dec 2002 14:56:14 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 QQnsmt27257 for ; Mon, 9 Dec 2002 14:56:14 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 gB9EueZK028202; Mon, 9 Dec 2002 09:56:40 -0500 (EST) Received: from tnadeau-w2k.cisco.com (che-vpn-cluster-2-87.cisco.com [10.86.242.87]) by bucket.cisco.com (Mirapoint) with ESMTP id ACF85222; Mon, 9 Dec 2002 09:56:09 -0500 (EST) Message-Id: <5.2.0.9.2.20021209095536.049bc030@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 09 Dec 2002 09:56:05 -0500 To: "Wijnen, Bert (Bert)" From: "Thomas D. Nadeau" Subject: RE: review of mpls-mgmt-overview revision 02 Cc: "Mpls (E-mail)" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 05:25 PM 12/8/2002 +0100, Wijnen, Bert (Bert) wrote: >In addition to my earlier review. > >I seems to me that the split of the LDP MIB module into four >MIB modules has not yet been incorporated into the overview >document Yes, that is new since the last revision; will make sure that makes it into the next version. --Tom >Thanks, >Bert From owner-mpls@UU.NET Mon Dec 9 10:33: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 KAA14021 for ; Mon, 9 Dec 2002 10:33:57 -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 QQnsmw11295 for ; Mon, 9 Dec 2002 15:36: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 QQnsmw07159; Mon, 9 Dec 2002 15:34:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsmw04947 for mpls-outgoing; Mon, 9 Dec 2002 15:33: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 QQnsmw04937 for ; Mon, 9 Dec 2002 15:33:48 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 QQnsmw00948 for ; Mon, 9 Dec 2002 15:32:20 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 QQnsmw07890 for ; Mon, 9 Dec 2002 15:32:19 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 QQnsmw07809 for ; Mon, 9 Dec 2002 15:32:08 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9FWbWJ004580 for ; Mon, 9 Dec 2002 10:32:37 -0500 (EST) 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 KAA27711 for ; Mon, 9 Dec 2002 10:32:07 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9FW7o26331 for mpls@uu.net; Mon, 9 Dec 2002 10:32:07 -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 QQnsmw04826 for ; Mon, 9 Dec 2002 15:30:23 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 QQnsmw24963 for ; Mon, 9 Dec 2002 15:30:11 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 QQnsmw06274 for ; Mon, 9 Dec 2002 15:30:11 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 QQnsmw06251 for ; Mon, 9 Dec 2002 15:30:10 GMT Received: (qmail 21344 invoked by uid 104); 9 Dec 2002 15:30:06 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4236. . Clean. Processed in 0.481914 secs); 09 Dec 2002 15:30:06 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 9 Dec 2002 15:30: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 gB9FU1Q26197; Mon, 9 Dec 2002 07:30:05 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Mon, 9 Dec 2002 07:30:00 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B5E@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'curtis@fictitious.org'" , David Allan Cc: neil.2.harrison@bt.com, swallow@cisco.com, mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Mon, 9 Dec 2002 07:29:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Curtis, > Dave, > > Since you asked, yes I do think the comments by two or more > individuals are more obstructionist than constructive, but it seems > particularly clear in this issue. > I am disturbed by this statement. Would you please point out which of my ignored comments are obstructive rather than constructive? As far as I can see many of my comments were even echoed by Eric rosen (unless you believe that he intends to obstruct his own company's proposal). Regarding the 127/8 issue, many others have the same concern. Besides, this is not an obstructive comment, because there are many other ways around it. Obstructive means the draft will fall apart without it. -Shahram From owner-mpls@UU.NET Mon Dec 9 10:54: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 KAA14793 for ; Mon, 9 Dec 2002 10:54:57 -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 QQnsmx00845 for ; Mon, 9 Dec 2002 15:57: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 QQnsmx24946; Mon, 9 Dec 2002 15:54:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsmx06387 for mpls-outgoing; Mon, 9 Dec 2002 15:54:08 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 QQnsmx06380 for ; Mon, 9 Dec 2002 15:53: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 QQnsmx03890 for ; Mon, 9 Dec 2002 15:52: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 QQnsmx23655 for ; Mon, 9 Dec 2002 15:52:43 GMT Received: from server by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [61.11.21.56]) id QQnsmx23599 for ; Mon, 9 Dec 2002 15:52:38 GMT Received: from ANISH ([192.168.10.12]) by server (8.11.2/8.8.7) with SMTP id gA9LNMr06081; Sun, 10 Nov 2002 02:53:22 +0530 Message-ID: <01e201c29f9a$d6293540$0c0aa8c0@ANISH> From: "Anish Verma" To: "nitin p" Cc: References: <20021207215500.74022.qmail@web14512.mail.yahoo.com> Subject: Re: [MPLS-OPS]: Jitter and MPLS Date: Mon, 9 Dec 2002 21:21:28 +0530 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit hi nitin, Could you plz show the topology that u r using? I mean whether destination and egress node in ur topology r same. if egress node and destination r same, then at the egress the IP lookup will not be there as packet is destined for the node itself. That make dealy at egress much lesser than the ingress. correct me if i am wrong anish ----- Original Message ----- From: "nitin p" To: "Eric Osborne" ; "Jing Shen" Cc: "Eric Osborne" ; "J.C.Ramesh Babu" ; ; Sent: Sunday, December 08, 2002 3:25 AM Subject: Re: [MPLS-OPS]: Jitter and MPLS > Hi, > Sorry for interrupting the discussion between Eric and > Jing. > > Recently I have also measured the hop delay in the > mpls-linux implementation of sourceforge.net. > > My results shows that delay at core (LSR) is less than > that is observed in IP. > Delay at egress(LER) delay in MPLS is slightly more > than that in IP. > But, delay at ingress(LER) is much more than tha in > IP. > > With my results I can infer that in a network of > 1000s(may be 100s) hops overall delay in MPLS will be > less that that in IP, but for samaller networks MPLS > results much more delay.I am not claiming that my > results are applicable to commercial implementations, > which might have good hardware support unlike my test > where I have used PC. > It makes sense that LERs will take more time than > LSRs,but what I coudn't understand is the performance > difference between Ingress and Egress. > > Any comments on this are most welcome. > Thanks, > Nitin > > > --- Eric Osborne wrote: > > On Sat, Dec 07, 2002 at 09:14:19PM +0800, Jing Shen > > wrote: > > > Thanks for Eric's comment. And, read my comment in > > line please. > > > > > > > > > > > 1) TCP throughput of MPLS is a little > > smaller than IP when path MTU is > > > > > the same. > > > > > and difference increases when path MTU > > decreases. > > > > > > > > MPLS packets are 4 bytes (or more) bigger than > > IP packets. If you do > > > > not allow for this in your link MTU, then you > > have smaller effective > > > > bandwidth inside TCP. Allow for that in your > > link MTU (as any > > > > reasonable implementation should) and you don't > > have this problem. > > > > > > Yes. We notice that at the first stage of our > > implementation and then we > > > modify the engine to allow for such situation. Our > > implementation allows > > > for a label stack with depth of 8, and we use only > > one. But, that do has > > > effect on TCP throughput if the same path is taken > > by IP and MPLS. > > > > > > > Have you been able to determine what made this > > impact? If your TCP > > segments can open up to the same size under both > > MPLS and IP, then all > > you add is another 4 bytes of transmission delay, > > which should be so > > close to zero it's inconsequential. And if > > everything has this small > > additional delay, then that should in no way create > > jitter in the > > network. > > > > > > > > > So this is a test of your forwarding equipment. > > Equipment which takes > > > > zero or negligible time to perform this > > encap/decap will not have this > > > > problem. > > > > > > As I know some of manufacturers announce that > > their router/switch > > > could operate at line speed, and the latency in a > > switch is > > > negeligible. But, what about situation of heavy > > load? The ability > > > of a linux based forwarding engine is surely not > > at the same level > > > of any hardware based product, but to my personal > > opinion any > > > comparation should be taken at the same situation > > ( hardware, > > > software etc). > > > > A switch that operates at line rate can still do so > > under heavy load. > > There are well-known mechanisms (DiffServ) for > > controlling performance > > under heavy load. Theoretically, there should be no > > difference in the > > performance of DiffServ whether applied to IP, MPLS, > > or for that > > matter, Appletalk, IPX, or any other switched packet > > technology. If > > you have found a platform-independent issue inherent > > to MPLS that > > causes jitter, I am very interested in seeing it. > > > > > Another reason is that we try to find out how > > MPLS compares with IP > > > when realtime multimedia content is loaded. The > > bandwidth > > > requirement of realtime distributed virtual > > reality system is at the > > > level of Gbps, and that value may increase when > > number of people > > > participating increases. So, we want to measure > > the situation that > > > accumulated dec/enc time is not negligible. > > > > OK, that's a fair thing to want to measure. But > > again, you're testing > > a specific implementation, and it's not reasonable > > to extend that > > comparison to any broader scope. > > > > > > > > Well, if R12000 is as cheap as 2511 that's not a > > question at all :-) > > > > > > > OK, if you want to talk specific router models, let > > me speak to the > > ones I know best. :) A 12k and a 2500[*] are > > different. They perform > > differently, are priced differently, and have > > different interfaces and > > capabilities. I would never do forwarding > > performance tests on a 2500 > > and claim the 12k behaves the same way, nor would I > > do tests on 12k > > forwarding and claim the 2500 performed the same > > way. By the same > > token, you can't test a Linux forwarding > > implementation (a lot like a > > really fast 2500) and claim that its performance is > > the same as any > > other router maker. > > > > [*] - sidebar to the viewing audience - a 12k (GSR) > > is a Really Big > > router, and a 2500 is a Really Small router. > > > > > > > Although we have not experimented with > > Cisco's express forwarding > > > > > and the like, and we do not experiment with > > large scale system with > > > > > real internet traffic pattern, we concern that > > the result could > > > > > applied to large scale network. > > > > > > > > I'm concerned about that too, because it means > > that you're building a > > > > large-scale network out of Linux-based > > software-forwarding devices. > > > > But even if you do have a performance hit at > > encap/decap, you only do > > > > label push/pop at the edges of the network, so > > you'd only take this > > > > hypothetical hit at the edges, making scale a > > nonissue for your > > > > particular imaginary problem. > > > > > > > > > > I'm sorry I means label stack operation by > > encap/decap. That is done at > > > each hop. As I mentioned above, if the load is > > light there is no > > > difference > > > but when the load is heavy the difference comes > > up. > > > > Then what you're testing is the per-hop performance > > hit taken by label > > swapping. This is, again, very > > implementation-dependent. In MPLS > > forwarding you have to do a label lookup and label > > swap, in IP you > > have to do a FIB lookup. Whether these two are the > > same speed, > > insignificantly different, or significantly > > different is a > > platform-specific thing. > > > > > > > > > 2) we focus on forwarding difference between > > IP and MPLS, and we > > > > > think technique like CEF and per-port cache > > could be applied to both > > > > > technologies. > > > > > > > > The fact that you're considering different > > lookup methodologies for IP > > > > and MPLS suggests even further that what you're > > profiling is your > > > > implementation, and not either > > > > a) a purely hypothetical > > situation (a la OPnet or > > > > whatever) > > > > b) a particular router > > implementation > > > > > > I agree with you that there is difference between > > lookup method > > > between IP routing and MPLS switching, this may > > introduce some > > > performance difference. > > > > Right, but like I said above, the switching > > mechanism is not a > > function inherent to the protocol. > > > > > > > > > > > > I have no problem with you testing your own > > implementation; I have a > > > > major issue if you try to generalize those > > results to claim that your > > > > specific behavior is in fact an artifact of the > > protocol itself. > > > > > > > === message truncated === > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com From owner-mpls@UU.NET Mon Dec 9 11:24: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 LAA16379 for ; Mon, 9 Dec 2002 11:24:35 -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 QQnsmz23807 for ; Mon, 9 Dec 2002 16:27: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 QQnsmz20327; Mon, 9 Dec 2002 16:25:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsmz26406 for mpls-outgoing; Mon, 9 Dec 2002 16:25: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 QQnsmz26401 for ; Mon, 9 Dec 2002 16:25: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 QQnsmz21229 for ; Mon, 9 Dec 2002 16:24:25 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 QQnsmz00714 for ; Mon, 9 Dec 2002 16:24:24 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 QQnsmz00701 for ; Mon, 9 Dec 2002 16:24:24 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Dec 2002 11:24:24 -0500 Message-ID: <1117F7D44159934FB116E36F4ABF221B0267ED57@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'curtis@fictitious.org'" Cc: mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Mon, 9 Dec 2002 11:24:20 -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, You probably need to remember that it's generally not considered polite to speculate cynical motivations for why people object to an idea that you have no particular objection to. Your stated belief that people are "grasping at straws" in objecting to the use of the 127/8 address range because they object to MPLS-Ping may be completely false in every case - and is certainly so in my own case. Please try to avoid bringing things to the personal level. It's highly unprofessional, at the very least, and certainly not conducive to rational discussion. I object to the use of this address range for the purpose that has been stated thus far. The reason why I object to it, is that I see it as pointless and possibly problematic. I have no objection to MPLS-Ping itself. From a posting by George Swallow (roughly 7:00 P.M. on 12/05/02 - see excerpt below), I got the clear impression that the use of this address range was intended to allow a sender to "tickle" all of the paths that might be used by an ECMP load sharing set of LSPs. If that is the case, this is hopelessly useless for that intent, since the last byte in the IP destination address is NOT going to be used for ECMP load sharing of LSPs in many reasonable LSR ECMP implementations. It is not even guaranteed to be used in IP forwarding. There are, for example, perfectly reasonable hashing algorithms that use the first two bytes in both the source and destination IP addresses. There are other ECMP hash algorithms that use SIPA exclusively. What is the point in using the 127/8 address range if any of these are in use? If there is another reason for using this address range, it either has not been stated, or I missed it. If there is a good reason to do it, I would not object to it. But there is not and - IMHO - there is a non-zero risk in using it. In other words, cost is possibly higher than we know and benefit is definitely lower than we seem to be led to believe. So I object to the use of the address range, not to the usefulness of MPLS-Ping. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 > ----- Excerpt from a message from George Swallow ------- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Thursday, December 05, 2002 7:01 PM > To: erosen@cisco.com > Cc: George Swallow; mpls@UU.NET; swallow@cisco.com > Subject: Re: Last call on LSP Ping [...] >> The suggestion to randomly choose IP destination addresses from the 127/8 >> block is, presumably, the way to ensure that the various paths created by >> equal cost load splitting get exercised. The question is, how many pings >> do you need to send in order to get good coverage? > > Obviously this depends on the number of ECMPs that exist. Which is > both a function of the topology and the number of hops between the > source and destination. If you have better suggestions on how to do > this I'm quite eager to hear them. This is the best we've been able > to come up with so far. [...] > ----- Original Message [from Curtis Villamizar] ----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: Saturday, December 07, 2002 6:52 PM > To: neil.2.harrison@bt.com > Cc: swallow@cisco.com; Shahram_Davari@pmc-sierra.com; mpls@UU.NET > Subject: Re: Last call on LSP Ping > > > In message <0536FC9B908BEC4597EE721BE6A35389014CFCB5@i2km07- > ukbr.domain1.system > host.net>, neil.2.harrison@bt.com writes: > > > > George....I think the point Shahram was making it is not > > > even allowed > > > > outside the host/source box according to the text quoted > > > from the RFcs > > > > below. Wrapping it in some other package (any, not just > > > MPLS) is still > > > > violating this requirement...and note that it *must* be > > > placed in some > > > > package to get across any tranmission medium....IP pkts > > > don't go raw on > > > > wires. > > > > > > As far as I'm concerned it is within the spirit of the RFCs. If you > > > want to insist on the letter of the law, perhaps you should look into > > > a career as a solicitor. > > > > > > ...George > > > > George, I am asking a serious question here and I would have appreciated > a > > serious answer please. I'd also like to see some responses to the other > > issues that have been raised. My experience to date suggests one only > gets > > responses 'when it suits'. At least others (esp Erics R and G and > Curtis) > > have attempted to provide reasoned answers. > > > > This stuff is going to get delivered whatever right?....so I want to be > sure > > that its as fit for purpose as possible (and that's more than this > > particular 127/8 point). > > A lot of packets from my site (here at home) go through the Internet, > all destined to a subnet of 10/8 (in the office). This (10/8) is also > not a routeable address covered in the same sections as 127/8 in > RFC1700 and RFC1812. Its OK to deliver these packets since they are > encapsulated in something else. It is not considered a violation of > RFC1700 or RFC1812 to forward these across the Internet where 10/8 and > 127/8 are considered to be "martian packets". > > Going way back to 1992, the mbone tunnels were originally built out of > source routed tunnels with a multicast destination. They later > switched to a tunnelled encapsulation due to performance problems of > certain routers when handling large volumes of source routed packets. > This was not considered a violation of RFC1700 or RFC1812. > > There are plenty of precedences for using private addresses inside > something else. > > In many circumstances, packets with private addresses are tunneled. > You have to separately look at what happens at the end of the tunnel > after the encapsulation is stripped off. > > > Here's my understanding of the current position on this specific point: > > > > There are (at least) 2 possible cases: > > 1 127/8 addressed pkts should never leave a box > > 2 127/8 can always leave a box.....since I can put 127/8 addressed > > pkts in ATM or FR (or ethernet?) directly.....I see no significant > technical > > difference here to the MPLS case that is argued as being justified. > > [Aside - one could generalise the above case 2 to *any* IP addressed > packet, > > or we could make 127/8 a special case] > > 127/8 cannot be forwarded based on the 127/8 destination. Just as > traffic from 10/8 can leave a subnet, croos the big-I Internet, and > reenter a subnet of 10/8, so can a packet be formed with a 127/8 > destination and be encapsulated in something and sent. > > What happens when the outside encapsulation is stripped off also has > to be examined. > > When the labels are gone, the 127/8 remains and the packet is sent to > the loopback address. That is the one exception allowed by RFC1812 > and delivery to the loopback is the explicit intended use of 127/8. > > > Now I just want a ruling that 2 is fine (perhaps as a special case?), > and as > > long as its agreed now then that's OK....I don't want this raised by > someone > > X months hence after this stuff is being shipped and operators have > deployed > > it. > > If you had a legitimate reason to deliver traffic to the loopback > device on the other end of a FR or ATM link, then putting 127.0.0.1 in > the destination and a valid UDP payload with a port number for that > application, then it would be fine. > > There is a legitimate reason for selecting a 127/8 address for this > application. Because it is used for a diagnostic we DON"T want it to > be routeable. RFC1700 and RFC1812 guarentee that it won't be > routeable. RFC1700 and RFC1812 explicitly set this address space > aside for use with the loopback device. > > > regards, Neil > > Once again, I think the MPLS-ping objectors are simply grasping at > straws. > > Curtis From owner-mpls@UU.NET Mon Dec 9 11:36: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 LAA16937 for ; Mon, 9 Dec 2002 11:36:55 -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 QQnsna10030 for ; Mon, 9 Dec 2002 16:39: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 QQnsna04273; Mon, 9 Dec 2002 16:36:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsna26924 for mpls-outgoing; Mon, 9 Dec 2002 16:35:44 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 QQnsna26919 for ; Mon, 9 Dec 2002 16:35: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 QQnsna10843 for ; Mon, 9 Dec 2002 16:35: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 QQnsna03704 for ; Mon, 9 Dec 2002 16:35:11 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 QQnsna03694 for ; Mon, 9 Dec 2002 16:35:10 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9GZbgX015658 for ; Mon, 9 Dec 2002 11:35:37 -0500 (EST) 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 LAA02661 for ; Mon, 9 Dec 2002 11:35:07 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9GZ7Z03975 for mpls@uu.net; Mon, 9 Dec 2002 11:35:07 -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 QQnsna26862 for ; Mon, 9 Dec 2002 16:34:30 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 QQnsna06483 for ; Mon, 9 Dec 2002 16:33: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 QQnsna02479 for ; Mon, 9 Dec 2002 16:33:22 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 QQnsna02466 for ; Mon, 9 Dec 2002 16:33:22 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 gB9GXnDm015366; Mon, 9 Dec 2002 11:33:49 -0500 (EST) Received: from tnadeau-w2k.cisco.com (che-vpn-cluster-2-87.cisco.com [10.86.242.87]) by bucket.cisco.com (Mirapoint) with ESMTP id ACF87663; Mon, 9 Dec 2002 11:33:18 -0500 (EST) Message-Id: <5.2.0.9.2.20021209103518.04a105e8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 09 Dec 2002 11:33:15 -0500 To: "Wijnen, Bert (Bert)" From: "Thomas D. Nadeau" Subject: Re: review of draft-ietf-mpls-te-mib-09.txt Cc: "Mpls (E-mail)" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >Seems that a lot of earlier comments I had made to the authors >half a year or so ago, have not been addressed. Oh well. >Here we go (mix of nits, and more serious things) > >- missing IPR section >- Security considerations probably needs more work > Security ADs want you to explain what the vulnerabilities/risks > are and what to do against them. > Also for read only objects, pls list each (group of) object(s) > and explain what sensitivity attributes they have >- RowStatus and STorageType objects need better text as per my comments > to the other MIB modules. Well, it is not from lack of trying. In many cases, I would ask that you make suggestions as to what exact text you would like to see. In particular, things like the examples and security sections have been updated to what we thought addressed your comments. For this and the other MIBs you have returned comments on you have stated that they are not up to snuff. Please instead of going back and forth 50 times on this via email, please just propose some text as you have done in other DESCRIPTION clause fixes, which will greatly speed things along. > And a special question... > " If this variable > is set to readOnly(5), and the corresponding entry > is removed, then the agent must remove this row > shortly thereafter [RFC2579]." > What does that mean? > What is the "corresponding entry"? That is this row, is it not? >- References need to be split in normative and informative I thought Arun did this. Which ones do you think are not? >- mplsXxxxNext, see my comments in my review of other mpls MIB modules Will use the description in the FTN MIB. >- last bullet sect 4 talks about (non-)persistent tunnels. > as does the DESCRIPTION clause of mplsTunnelGroup... > but I don't get a good picture of what makes a persistent > or a non-persistent tunnel and what the MIB offers for that. >- section 9, the example > includes mplsTunnelOwner... but it claims that those things > are to be part of a SET request. But... in the MIB module I see > the mplsTunnelOwner is read-only, so it cannot be part > of a SET Right. Need to clarify. The owner is gleaned from who creates the entry, as is described in the TC. >- section 9 example > inlcudes mplsTunnelResourcePointer and syas that it should > be SET to mplsTunnelResourceIndex.5 > I think that should be mplsResourceMaxRate.5 because that > is the first accessible columnar object in a row that table Yes. >- section 10, > first sentence > s/to one of its objetcs/to the first accesible object in a row/ > last sentence > s/to the first column/to the first accessible column/ >- I wonder if mplsTunnelConfigured would be better named > mplsTunnelsConfigured and mplsTunnelActive better be named > mplsTunnelsActive >- I ownder if mplsTunnelNotiMaxRate would be better named > mplsTunnelNotiInterval > May want to add a UNITS clause to this object anyway > and why is it not named mplsTunnerNotificationInterval? Looks like a typo. >- mplsTunnelIndexNext > well, same comment as to all the mplsXxxNext objects in the > other MIB modules. > But this one has even another strange thing, namely it is > a Interger32 (as opposed to a Unsigned32) and it has a pretty > limited range and for all I can tell for no good reason. > In fact I see no reason for a upper limit. It is supposed to match the indexing of the tunnel table. >- mplsTunnelEntry > Why is there a reference to RFC1700 ??? That RFC has been > obsoleted anyway... >- Can someone explain to me why you use the complex indexing > scheme for the mplsTunnelTable, namely: > INDEX { > mplsTunnelIndexIndex, > mplsTunnelInstance, > mplsTunnelIngressLSRId, > mplsTunnelEgressLSRId > } > > - first, I do not understand why it the 1st one is named > mplsTunnelIndexIndex instead of just mplsTunnelIndex Compiler complained because the type is MplsTunnelIndex. > - 2nd, mplsTunnelIndexIndex claims to "uniquely" identify a row > so then no more index objects seem needed > - but mplsTunnelInstance seems to also "uniquely" identify a row?? > - and then there are yet more index objects. > - mplsTunnelIngresLSRId, description talks about "this value". > but the index object does not really have a value. It is part > of the OID that identifies instances in the table. > Why do I not understand this indexing scheme? We went over this during the MIB meeting. This is basically just the RSVP-TE indexing required. > I think it would be good to include in the DESCRIPTION clause of > either the mplsTunnleEntry or of the indices a very good explanation > as to how the indexing works here. Yes. We agreed to improve the description as an action from the MIB meeting. >- I have trouble with the use of DisplaySTring (as mentioned half a year > ago). These days we want people to use UTF8 based strings if the strings > are intended for human use. So either SnmpAdminString or some other > UTF8-based string. Several TCs have been defined to replace DisplayString Yes, will use SnmpAdminString. >- I wonder why the mplsTunnelName is ever to be equal to ifName. > The link between an entry in the mplsTunnelTable and the ifTable is > made by the mplsIfTunnelIndex which is the better way indeed to make > the link. The idea is that in cases where the tunnel is an ifEntry too, this makes sense so they are associated. >- It seems to me that mplsIfTunnelDescription could have a DEFVAL > of the empty (zero lenght) string >- It seems to me that mplsTunnelIsIf and mplsTunnelIfIndex are overlapping. > A value of zero in the mplsTunnelIfIndex means that this tunnel does > not correspond to an interface. A nonzero value means that it does > correspond to an interface. So why is mplsTunnelIsIf needed? So that > people can have conflicting stuff that needs to be chacked and all that? The idea is that you can quickly determine the type of tunnel. I suppose that we could eliminate this object and just state that if ifIndex = 0 that it is NOT an ifIndex. >- mplsTunnelSessionAttributes > you may want to check the formatting in the DESCRIPTION clause >- mplsTunnelOwner is a read-only object and yet the description clause > talks about that it cannot be modified when RowStatus is active. > That seems redundant text. A read-only object can NEVER be changed Again, this should be the same as that in the TC that we discussed (the agent sets this value). >- I see mplsTunnelHopTableIndex to be read-create while > mplsTunnelARHopTableIndex and mplsTunnelCHopTableIndex are read-only > Is that not strange? Nope. The actual route hop table is what is spit out by the CSPF computation; not operator programmable. >- I do not understand mplsTunnelPrimaryInstance, but that is probably linked > to me not understanding the indexing scheme. >- mplsTunnelPathChanges > s/paths has changed/path has changed/ or > s/path has changed/paths have changed/ ?? >- mplsTunnelTotalUptime > so is this an aggregate value of multiple entries in this table? This is the up time of all LSP instances of the tunnel. > and if so of how many? Is that of all entries with the same > mplsTunnelIndexIndex, or what? Yes, the same group of tunnel instances (the same primary tunnel index). > And then... if there are 4 entries aggregated, do all 4 entries then > have the same value? > And what is the upTime of each entry? mplsTunnelPrimaryTimeUp shows the time of the primary instance that this tunnel mplsTunnelTotalUpTime is the aggregate time of all instances of this tunnel (head). mplsTunnelInstanceUpTime is the time this instance has been up. > I am confused here as to what the purpose of this object is and how > it is computed. Under what circumstances would it "not be available"? It might not be available if no instances exist for the tunnel. I suppose it might be simpler to just remove this text, but the thinking was that we specified an initial value for when no tunnel instances (other than 0) existed. >- mplsTunnelHopListIndexNext > well, same comment as to all the mplsXxxNext objects in the > other MIB modules. > But this one has even another strange thing, namely it is > a Interger32 (as opposed to a Unsigned32) and it has a pretty > limited range and for all I can tell for no good reason. > In fact I see no reason for a upper limit. >- mplsTunnelHopTable. > again I do not (from the DESCRIPTION clauses) understand the indexing > scheme. It seems to have two "seconday" indices. Should that be a secondary > and a tertiary? Must be me, since I am not an mpls expert ;-) >- I assume that the mplsTunnelHopAddrType and related objects get replaced > with a common new TC as discussed at the MPLS MIB meeting in Atlanta Yes. >- mplsTunnelHopType > this sort of ENUMERATION seems to occur a few times, so that it seems to > me that you want to create a TC for it. Okay. >- mplsTunnelHopPathOptionName should be UTF8 based and not DisplayString SnmpAdminString okay? >- mplsTunnelResourceIndexNext > well, same comment as to all the mplsXxxNext objects in the > other MIB modules. > But this one has even another strange thing, namely it is > a Interger32 (as opposed to a Unsigned32) and it has a pretty > limited range and for all I can tell for no good reason. > In fact I see no reason for a upper limit. >- mplsTunnelResourceMaxRate and mplsTunnelResourceMeanRate > could use a UNITS clause > And... you say it is bits per second, while the MplsBitRate TC claims > that it is Kbps... oh well >- mplsTunnelResourceMaxRate and mplsTunnelResourceMeanRate > I don't think I udnerstand what the OID copying is all about and > how an agent determines what to do? Or is it the management station > who does this? The text you are referring to is: This object is copied to an instance of mplsTrafficParamMaxRate in mplsTrafficParamTable the OID of which is copied into the corresponding mplsInSegmentTrafficParamPtr. this refers to the fact the values should be copied down to those see in the LSR MIB's resource table. This is now moot, as we are removing the LSR MIB's table. I will remove the aforementioned text. In fact, this text appears all over the place in the resource table, so I will fix. >- mplsTunnelResourceFrequency OBJECT-TYPE > SYNTAX INTEGER { > unspecified(1), > frequent(2), > veryFrequent(3) > I see another occurence in another table. So a good candidate for a TC > But I also wonder what "frequent" and "veryFrequent" means? > To me they seem very very vague terms, no? I believe this comes from CR-LDP and does not apply for RSVP-TE (you would use unspecified). See the reference of CR-LDP Specification, Section 4.3 for more details. I would actually prefer to ditch this and the other CR-LDP tables to make things simpler... >- mplsTunnelResourceWeight OBJECT-TYPE > SYNTAX Unsigned32(0..255) > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The relative weight for using excess bandwidth above > its committed rate. The value of 0 means that > weight is not applicable for the CR-LSP." > I see this multiple times. Good candidate for a TC I only see it twice. Can we skip this? >- mplsTunnelARHopAddrType and related objects > I assume this will be replaced by new TCs as discussed in atlanta >- mplsTunnelCHopAddrType and related objects > I assume this will be replaced by new TCs as discussed in atlanta >- I would suggest to just do counter 64 instead of both 64 and 32 > for objects like > mplsTunnelPerfPackets Counter32, > mplsTunnelPerfHCPackets Counter64, > mplsTunnelPerfBytes Counter32, > mplsTunnelPerfHCBytes Counter64 > In general we also speak about octets instead of bytes, but I can > live with bytes. >- I wonder if mplsTunnelCRLDPResFlags would not be better represented > with a BITS construct instead of an INTEGER enumeration We have been over this several times. The representation is based on what is found in the CR-LDP protocol. The WG preferred to leave the value this way, so I would prefer to leave it (unless we can ditch all of the CR-LDP related stuff). >- MODULE COMPLIANCE > Maybe a Full and a ReadOnly compliance? Will add. > See also my comment to other mpls MIB modules. It links to the > SYNTAX and WRITE-SYNTAX of some of the objects as well, specifically > the RowStatus objects >- Pls see also my note in other MIB Module comments about the > 'other' for StirageType objetcs. It seems really weird to have > that in the compliance. >- It is not good to give a group of objects a name that indicates > optionality. A gorup is just a group. If it is optional or > manadatory, that should become clear in the MODULE COMPLIANCE > statement, but not in the name (and/or description clause) of the group Okay. > Some future MODULE COMPLIANCE may want to make that group mandatory. > An OBJECT GROUP is a "logical grouping" of objects. The requirement > for mandatory of conditional or optional implementation is to be > specified in the MODULE-COMPLIANCE. >- I do not understand why there is both mplsTunnelIsIntfcGroup and a > mplsTunnelIsNotIntfcGroup? Because some objects make sense only for when the tunnel entry is implemented as an ifIndex. >One seems sufficient to me. This is moot if we just remove the IsIf object from the tunnelEntry. > And why not spell out Intfc as Interface? Brevity? *) We actually wanted to be consistent with the rest of the MIB, which I think uses "if". --Tom >Thanks, >Bert From owner-mpls@UU.NET Mon Dec 9 11:37: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 LAA16963 for ; Mon, 9 Dec 2002 11:37:06 -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 QQnsna29886 for ; Mon, 9 Dec 2002 16:39:57 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 QQnsna26858; Mon, 9 Dec 2002 16:38:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsna27062 for mpls-outgoing; Mon, 9 Dec 2002 16:38:20 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 QQnsna27050 for ; Mon, 9 Dec 2002 16:38: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 QQnsna04022 for ; Mon, 9 Dec 2002 16:37: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 QQnsna25903 for ; Mon, 9 Dec 2002 16:37:22 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQnsna25746 for ; Mon, 9 Dec 2002 16:37:07 GMT Received: from cisco.com (erosen-u10.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9GavFp025626; Mon, 9 Dec 2002 08:36:57 -0800 (PST) Message-Id: <200212091636.gB9GavFp025626@sj-msg-core-1.cisco.com> To: "Gray, Eric" cc: "'curtis@fictitious.org'" , mpls@UU.NET Subject: Re: Last call on LSP Ping In-reply-to: Your message of Mon, 09 Dec 2002 11:24:20 -0500. <1117F7D44159934FB116E36F4ABF221B0267ED57@celox-ma1-ems1.celoxnetworks.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Mon, 09 Dec 2002 11:36:56 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk EricG> If there is another reason for using this address range, it either EricG> has not been stated, or I missed it. Well, what should the tunnel ingress put into the IP destination field of the "LSP Ping" UDP packet? We want the packet to be consumed by the egress even if the egress isn't who the ingress thinks it is. (That's how we get the error response indicating that the tunneled packets have been misrouted.) Thus we need to put in a "well known" address which will be interpreted by the tunnel egress as meaning "for me". Use of one of the loopback addresses (127.x.y.z) seems to achieve this goal. I think it's kind of a nifty hack ;-) As Curtis has pointed out, there is ample precedent for having a tunneled packet carry addressing information which is to be interpreted in the context of the egress. From owner-mpls@UU.NET Mon Dec 9 11:42: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 LAA17248 for ; Mon, 9 Dec 2002 11:42:13 -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 QQnsna09542 for ; Mon, 9 Dec 2002 16:44:56 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 QQnsna06346; Mon, 9 Dec 2002 16:43:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsna27476 for mpls-outgoing; Mon, 9 Dec 2002 16:42:51 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 QQnsna27460 for ; Mon, 9 Dec 2002 16:42: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 QQnsna08563 for ; Mon, 9 Dec 2002 16:42: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 QQnsna13877 for ; Mon, 9 Dec 2002 16:42:07 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 QQnsna13846 for ; Mon, 9 Dec 2002 16:42:06 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9GgO9Y016825 for ; Mon, 9 Dec 2002 11:42:24 -0500 (EST) 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 LAA03246 for ; Mon, 9 Dec 2002 11:41:54 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9GfsY04941 for mpls@uu.net; Mon, 9 Dec 2002 11:41:54 -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 QQnsna27092 for ; Mon, 9 Dec 2002 16:39:01 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 QQnsna07025 for ; Mon, 9 Dec 2002 16:38:17 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 QQnsna12473 for ; Mon, 9 Dec 2002 16:38:16 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 QQnsna12460 for ; Mon, 9 Dec 2002 16:38:15 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 LAA35389; Mon, 9 Dec 2002 11:35:55 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212091635.LAA35389@workhorse.fictitious.org> To: jshen@cad.zju.edu.cn cc: "Naidu, Venkata" , Eric Osborne , "J.C.Ramesh Babu" , mpls-ops@mplsrc.com, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: [MPLS-OPS]: Jitter and MPLS In-reply-to: Your message of "Mon, 09 Dec 2002 20:41:09 +0800." <3DF48F65.840949E1@cad.zju.edu.cn> Date: Mon, 09 Dec 2002 11:35:55 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3DF48F65.840949E1@cad.zju.edu.cn>, Jing Shen writes: > > OMP gives a good start on traffic engineering but its traffic division > policy is too simple for self-similar internet traffic. I don't see any basis for this assertion. The IP src/dst hash is used almost universally in ECMP for OSPF, ISIS, LDP (after payload snooping consistently indicates that payload is IP), and MPLS/TE implementations (when L3PID indicates IP traffic), as well as in proprietary link bundling (for example: Avici Composite Links (tm) and others). It works very well with Internet traffic. > I have another question, is OMP implemented in some commerical products? > if not, why? There have been a few research implementations that have come to my attention, mostly grad student projects. Implementing in a commercial router is a much larger undertaking due to added complexity (forwarding cards are separate from router processors, more is done in hardware or microcode, 100s or 1000s of interfaces pose greater scaling challenges, etc) and the software quality requirements. Without a customer expressing strong interest this hasn't happenned. Curtis From owner-mpls@UU.NET Mon Dec 9 11:59: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 LAA18455 for ; Mon, 9 Dec 2002 11:59:52 -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 QQnsnc29364 for ; Mon, 9 Dec 2002 17:02: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 QQnsnb22862; Mon, 9 Dec 2002 16:59:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsnb29207 for mpls-outgoing; Mon, 9 Dec 2002 16:59:11 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 QQnsnb29184 for ; Mon, 9 Dec 2002 16:59:05 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 QQnsnb10743 for ; Mon, 9 Dec 2002 16:58: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 QQnsnb22222 for ; Mon, 9 Dec 2002 16:58:48 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 QQnsnb22216 for ; Mon, 9 Dec 2002 16:58: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 LAA01877 for ; Mon, 9 Dec 2002 11:58:44 -0500 (EST) 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 LAA00813 for ; Mon, 9 Dec 2002 11:58:46 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 9 Dec 2002 11:58:45 -0500 Message-ID: <313680C9A886D511A06000204840E1CF8F52BB@whq-msgusr-02.pit.comms.marconi.com> From: "Choudhury, Sanjaya" To: "'mpls@UU.NET'" Subject: Few label space questions in context of RFC3031 and LSR-MIB Date: Mon, 9 Dec 2002 11:58:38 -0500 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 Hi! I have few questions related to the "label spaces" as defined in RFC3031 and used in LSR-MIB. Your help will be appreciated. 1. RFC3031 Section 3.14, page 16 states the following: "In MPLS there is no notion of having a different label space for different levels of the hierarchy; when interpreting a label, the level of the label is irrelevant." Are the following interpretation correct? (a) ALL the labels in a label stack of a LSP _MUST_ be from the same label space (b) One cannot have a LSP where one of the label in the label stack is from a "per-interface label space", while other is from a "per-platform label space". 2. LSR-MIB: (a) mplsInterfaceLabelParticipationType's MAX-ACCESS is read-only. Should this be made a read-write field, so that the user can configure the participation type? (b) mplsInterfaceLabelParticipationType allows the interface to participate in BOTH "per-interface" and "per-platform" label space. In such a case: (i) How does the indexing of the mplsInputSegmentEntry will work? case1: If1 , 300 (platform label space) If2, 300 (interface label space) !!! case2: If1, 500 (platform label space) If1, 500 (interface label space) ->un-supported (illegal config?) (ii) What should the mplsInterfaceLabelMinIn,MinOut,MaxIn Maxout? Thanks, sanjay From owner-mpls@UU.NET Mon Dec 9 12:00: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 MAA18526 for ; Mon, 9 Dec 2002 12:00:13 -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 QQnsnc00202 for ; Mon, 9 Dec 2002 17:03:04 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 QQnsnc23879; Mon, 9 Dec 2002 17:00:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsnb29214 for mpls-outgoing; Mon, 9 Dec 2002 16:59: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 QQnsnb29209 for ; Mon, 9 Dec 2002 16:59: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 QQnsnb02664 for ; Mon, 9 Dec 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 QQnsnb29262 for ; Mon, 9 Dec 2002 16:57:48 GMT Received: from mailhost.avici.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host128.avici.com [208.246.215.128]) id QQnsnb29251 for ; Mon, 9 Dec 2002 16:57:47 GMT Received: from aatlas-lt.avici.com (b2-pc95.avici.com [10.2.100.125]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id gB9Gvku03808 for ; Mon, 9 Dec 2002 11:57:46 -0500 (EST) Message-Id: <5.1.0.14.2.20021209114830.01f57698@mailhost.avici.com> X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 09 Dec 2002 11:59:24 -0500 To: mpls@UU.NET From: Alia Atlas Subject: Re: Last Call on MPLS ping Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk I have a few questions on MPLS ping, particularly as it applies to pseudo-wires and L3VPNs. For a simple non-hierarchical TE-LSP or LDP, it seems to be viable (though rather complex to implement) and to depend upon knowing an alternate IP only route for every ingress LER in the network. First, for pseudo-wires, it appears to me that MPLS ping is using the bottom-of-stack bit to help make a forwarding decision. I.e., consider if a packet comes in with a PSN label, PW label, and then an IPv4 Explicit NULL, as specified in Section 5.3: "To test an LSP that carries non-IP traffic, before injecting ICMP and MPLS ping messages into the LSP, the IPv4 Explicit NULL label should be prepended to such messages. The ingress and egress LSR's must follow the procedures defined in [LABEL-STACKING]" Now, normally, the PSN label (if present) would be popped off and then the PW label would be consulted as for how to forward the packet. The PW label indicates the outgoing interface and that the packet inside should be encapsulated according to the pseudo-wire type. However, with MPLS ping, if the bottom-of-stack bit is not set, then the hardware must consider the label underneath the PW label, discover that it is an IPv4 Explicit NULL label and treat the packet accordingly. This indicates to me that the forwarding paradigm has changed to support this - now the forwarding decision is made as a result of not just the 20-bit label, but also the bottom-of-stack bit. Am I missing something here? The solution could be changing the label stack to be PSN label, Router Alert Label, PW label. Then the software would look at the PW label and underneath and determine that it is an MPLS ping packet (in some fashion). A similar question applies for L3VPNs. First, let me quote briefly from 2547bis about the label distribution. "Suppose that a PE has assigned label L to route R, and has distributed this label mapping via BGP. If R is an aggregate of a set of routes in the VRF, the PE will know that packets from the backbone which arrive with this label must have their destination addresses looked up in a VRF. When the PE looks up the label in its Label Information Base, it learns which VRF must be used. On the other hand, if R is not an aggregate, then when the PE looks up the label, it learns the egress attachment circuit, as well as the encapsulation header for the packet. In this case, no lookup in the VRF is done. We would expect that the most common case would be the case where the route is NOT an aggregate." So, my concern here is for the case where the route is not an aggregate and the label indicates the egress attachment circuit as well as the encapsulation header for the packet. In this case, LSP ping would send an IP packet with the specific route's label and then the PSN's label. However, the egress LER would look at the specific route's label and immediately forward the packet, whatever it contained, to the egress attachment circuit. My understanding is that certain implementations do aggregate the routes in a VRF together so that an egress lookup in the VRF is done. However, certain implementations do not, and 2547bis expects this to be the most common case. Three other concerns are as follows: 1) Setting the TTL of all labels except the top label to 1 doesn't seem viable for the LDP LSP over an RSVP LSP, unless the RSVP LSP is in uniform mode. I.e., suppose that the ingress of the LDP LSP wishes to send an LSP ping, and, furthermore, that the LDP LSP enters an RSVP LSP at that ingress, but the RSVP LSP ends before the egress of the LDP LSP under consideration. In that case, if the RSVP LSP is not doing the uniform TTL mode, the TTL of the LDP LSP's label will be exposed and used, but be too small. 2) For the trace-route case with an intermediate router which doesn't support MPLS ping, I am not clear on how/why a further router would include the DOWNSTREAM_MAPPING TLV, since that wouldn't be in the Echo Request, because the ingress doesn't have an appropriate DOWNSTREAM_MAPPING TLV to insert in, due to the non-supportive intermediate router. Perhaps it would be clearer if the ingress could specify, via a flag, that a DOWNSTREAM_MAPPING TLV should be included. 3) Also, it's not clear to me how well the trace-route mode would work with LSPs which are not using the uniform model. I.e., if one were to set all the TTL of all the labels underneath the top one to 1, then it wouldn't matter how much you increased the TTL of the top label - when that LSP ended, the trace-route mode would go to the next hop always. Of course, you would notice this due to differences in the DOWNSTREAM_MAPPING, but that doesn't help in tracing the LSP, and it wouldn't indicate a control-plane problem, as was intended, but simply that the top LSP was not using the uniform model. Thanks for any responses, Alia Atlas From owner-mpls@UU.NET Mon Dec 9 12:06:27 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 MAA18927 for ; Mon, 9 Dec 2002 12:06:27 -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 QQnsnc13078 for ; Mon, 9 Dec 2002 17:09:19 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 QQnsnc06329; Mon, 9 Dec 2002 17:05:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsnc17236 for mpls-outgoing; Mon, 9 Dec 2002 17:04:52 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 QQnsnc16825 for ; Mon, 9 Dec 2002 17:04: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 QQnsnc25471 for ; Mon, 9 Dec 2002 17:04: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 QQnsnc01374 for ; Mon, 9 Dec 2002 17:04:26 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 QQnsnc01335 for ; Mon, 9 Dec 2002 17:04:20 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9H4nfb020498 for ; Mon, 9 Dec 2002 12:04:49 -0500 (EST) 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 MAA05134 for ; Mon, 9 Dec 2002 12:04:19 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9H4Jn12127 for mpls@uu.net; Mon, 9 Dec 2002 12:04:19 -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 QQnsnc11162 for ; Mon, 9 Dec 2002 17:02:54 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 QQnsnc21583 for ; Mon, 9 Dec 2002 17:01: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 QQnsnc28551 for ; Mon, 9 Dec 2002 17:01:22 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 QQnsnc28533 for ; Mon, 9 Dec 2002 17:01:21 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 gB9H1cFn020047; Mon, 9 Dec 2002 12:01:38 -0500 (EST) Received: from tnadeau-w2k.cisco.com (che-vpn-cluster-2-87.cisco.com [10.86.242.87]) by bucket.cisco.com (Mirapoint) with ESMTP id ACF88431; Mon, 9 Dec 2002 12:01:06 -0500 (EST) Message-Id: <5.2.0.9.2.20021209114424.04a7e0f8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 09 Dec 2002 12:01:02 -0500 To: "Gray, Eric" From: "Thomas D. Nadeau" Subject: RE: Last call on LSP Ping Cc: "'curtis@fictitious.org'" , mpls@UU.NET In-Reply-To: <1117F7D44159934FB116E36F4ABF221B0267ED57@celox-ma1-ems1.ce loxnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk [snip] > I object to the use of this address range for the >purpose that has been stated thus far. The reason why I >object to it, is that I see it as pointless and possibly >problematic. I have no objection to MPLS-Ping itself. > > From a posting by George Swallow (roughly 7:00 >P.M. on 12/05/02 - see excerpt below), I got the clear >impression that the use of this address range was >intended to allow a sender to "tickle" all of the paths >that might be used by an ECMP load sharing set of LSPs. >If that is the case, this is hopelessly useless for that >intent, since the last byte in the IP destination address >is NOT going to be used for ECMP load sharing of LSPs in >many reasonable LSR ECMP implementations. It is not even >guaranteed to be used in IP forwarding. There are, for >example, perfectly reasonable hashing algorithms that use >the first two bytes in both the source and destination IP >addresses. There are other ECMP hash algorithms that use >SIPA exclusively. What is the point in using the 127/8 >address range if any of these are in use? > > If there is another reason for using this address >range, it either has not been stated, or I missed it. If >there is a good reason to do it, I would not object to it. >But there is not and - IMHO - there is a non-zero risk in >using it. In other words, cost is possibly higher than >we know and benefit is definitely lower than we seem to >be led to believe. > > So I object to the use of the address range, not to >the usefulness of MPLS-Ping. What addresses other than the 127.* addresses would you put into the UDP packet contained in the LSP ping message? This satisfies the requirement that LSP ping packets are not forwarded if the header is popped, and also the requirement that the ping messages are forwarded the same way as a data packet. This works whether hashing is done whether or not you look past the MPLS header. Quite a nifty and effective (albeit a bit hacky) solution if you ask me. --Tom >Eric W. Gray >Systems Architect >Celox Networks, Inc. >egray@celoxnetworks.com >508 305 7214 > > > ----- Excerpt from a message from George Swallow ------- > > From: George Swallow [mailto:swallow@cisco.com] > > Sent: Thursday, December 05, 2002 7:01 PM > > To: erosen@cisco.com > > Cc: George Swallow; mpls@UU.NET; swallow@cisco.com > > Subject: Re: Last call on LSP Ping > >[...] > > >> The suggestion to randomly choose IP destination addresses from the 127/8 > >> block is, presumably, the way to ensure that the various paths created by > >> equal cost load splitting get exercised. The question is, how many pings > > >> do you need to send in order to get good coverage? > > > > Obviously this depends on the number of ECMPs that exist. Which is > > both a function of the topology and the number of hops between the > > source and destination. If you have better suggestions on how to do > > this I'm quite eager to hear them. This is the best we've been able > > to come up with so far. > >[...] > > > ----- Original Message [from Curtis Villamizar] ----- > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > Sent: Saturday, December 07, 2002 6:52 PM > > To: neil.2.harrison@bt.com > > Cc: swallow@cisco.com; Shahram_Davari@pmc-sierra.com; mpls@UU.NET > > Subject: Re: Last call on LSP Ping > > > > > > In message <0536FC9B908BEC4597EE721BE6A35389014CFCB5@i2km07- > > ukbr.domain1.system > > host.net>, neil.2.harrison@bt.com writes: > > > > > George....I think the point Shahram was making it is not > > > > even allowed > > > > > outside the host/source box according to the text quoted > > > > from the RFcs > > > > > below. Wrapping it in some other package (any, not just > > > > MPLS) is still > > > > > violating this requirement...and note that it *must* be > > > > placed in some > > > > > package to get across any tranmission medium....IP pkts > > > > don't go raw on > > > > > wires. > > > > > > > > As far as I'm concerned it is within the spirit of the RFCs. If you > > > > want to insist on the letter of the law, perhaps you should look into > > > > a career as a solicitor. > > > > > > > > ...George > > > > > > George, I am asking a serious question here and I would have appreciated > > a > > > serious answer please. I'd also like to see some responses to the other > > > issues that have been raised. My experience to date suggests one only > > gets > > > responses 'when it suits'. At least others (esp Erics R and G and > > Curtis) > > > have attempted to provide reasoned answers. > > > > > > This stuff is going to get delivered whatever right?....so I want to be > > sure > > > that its as fit for purpose as possible (and that's more than this > > > particular 127/8 point). > > > > A lot of packets from my site (here at home) go through the Internet, > > all destined to a subnet of 10/8 (in the office). This (10/8) is also > > not a routeable address covered in the same sections as 127/8 in > > RFC1700 and RFC1812. Its OK to deliver these packets since they are > > encapsulated in something else. It is not considered a violation of > > RFC1700 or RFC1812 to forward these across the Internet where 10/8 and > > 127/8 are considered to be "martian packets". > > > > Going way back to 1992, the mbone tunnels were originally built out of > > source routed tunnels with a multicast destination. They later > > switched to a tunnelled encapsulation due to performance problems of > > certain routers when handling large volumes of source routed packets. > > This was not considered a violation of RFC1700 or RFC1812. > > > > There are plenty of precedences for using private addresses inside > > something else. > > > > In many circumstances, packets with private addresses are tunneled. > > You have to separately look at what happens at the end of the tunnel > > after the encapsulation is stripped off. > > > > > Here's my understanding of the current position on this specific point: > > > > > > There are (at least) 2 possible cases: > > > 1 127/8 addressed pkts should never leave a box > > > 2 127/8 can always leave a box.....since I can put 127/8 addressed > > > pkts in ATM or FR (or ethernet?) directly.....I see no significant > > technical > > > difference here to the MPLS case that is argued as being justified. > > > [Aside - one could generalise the above case 2 to *any* IP addressed > > packet, > > > or we could make 127/8 a special case] > > > > 127/8 cannot be forwarded based on the 127/8 destination. Just as > > traffic from 10/8 can leave a subnet, croos the big-I Internet, and > > reenter a subnet of 10/8, so can a packet be formed with a 127/8 > > destination and be encapsulated in something and sent. > > > > What happens when the outside encapsulation is stripped off also has > > to be examined. > > > > When the labels are gone, the 127/8 remains and the packet is sent to > > the loopback address. That is the one exception allowed by RFC1812 > > and delivery to the loopback is the explicit intended use of 127/8. > > > > > Now I just want a ruling that 2 is fine (perhaps as a special case?), > > and as > > > long as its agreed now then that's OK....I don't want this raised by > > someone > > > X months hence after this stuff is being shipped and operators have > > deployed > > > it. > > > > If you had a legitimate reason to deliver traffic to the loopback > > device on the other end of a FR or ATM link, then putting 127.0.0.1 in > > the destination and a valid UDP payload with a port number for that > > application, then it would be fine. > > > > There is a legitimate reason for selecting a 127/8 address for this > > application. Because it is used for a diagnostic we DON"T want it to > > be routeable. RFC1700 and RFC1812 guarentee that it won't be > > routeable. RFC1700 and RFC1812 explicitly set this address space > > aside for use with the loopback device. > > > > > regards, Neil > > > > Once again, I think the MPLS-ping objectors are simply grasping at > > straws. > > > > Curtis From owner-mpls@UU.NET Mon Dec 9 12:33:23 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 MAA20032 for ; Mon, 9 Dec 2002 12:33:23 -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 QQnsne28804 for ; Mon, 9 Dec 2002 17:36:10 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 QQnsnd18038; Mon, 9 Dec 2002 17:29:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsnd20367 for mpls-outgoing; Mon, 9 Dec 2002 17:29:36 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 QQnsnd20360 for ; Mon, 9 Dec 2002 17:29: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 QQnsnd15123 for ; Mon, 9 Dec 2002 17:29: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 QQnsnd17585 for ; Mon, 9 Dec 2002 17:29:08 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 QQnsnd17575 for ; Mon, 9 Dec 2002 17:29:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9HTa5N024020 for ; Mon, 9 Dec 2002 12:29:36 -0500 (EST) 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 MAA07133 for ; Mon, 9 Dec 2002 12:29:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9HT6P14792 for mpls@uu.net; Mon, 9 Dec 2002 12:29:06 -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 QQnsnd20293 for ; Mon, 9 Dec 2002 17:27:43 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 QQnsnd11307 for ; Mon, 9 Dec 2002 17:26: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 QQnsnd21158 for ; Mon, 9 Dec 2002 17:26:04 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 QQnsnd21148 for ; Mon, 9 Dec 2002 17:26:03 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 MAA35648; Mon, 9 Dec 2002 12:23:00 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212091723.MAA35648@workhorse.fictitious.org> To: Shahram Davari cc: "'curtis@fictitious.org'" , David Allan , neil.2.harrison@bt.com, swallow@cisco.com, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Mon, 09 Dec 2002 07:29:58 PST." <4B6D09F3B826D411A67300D0B706EFDEB03B5E@nt-exch-yow.pmc-sierra.bc.ca> Date: Mon, 09 Dec 2002 12:23:00 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4B6D09F3B826D411A67300D0B706EFDEB03B5E@nt-exch-yow.pmc-sierra.bc.ca >, Shahram Davari writes: > Curtis, > > > Dave, > > > > Since you asked, yes I do think the comments by two or more > > individuals are more obstructionist than constructive, but it seems > > particularly clear in this issue. > > > > I am disturbed by this statement. Would you please point out which of my > ignored comments are obstructive rather than constructive? As far as > I can see many of my comments were even echoed by Eric rosen (unless you beli > eve > that he intends to obstruct his own company's proposal). > > Regarding the 127/8 issue, many others have the same concern. Besides, > this is not an obstructive comment, because there are many other ways around > it. > Obstructive means the draft will fall apart without it. > > -Shahram You have not cited any technical reason for avoiding 127/8. You have cited documents and tried to manipulate the interpretation to claim that any use of 127/8 is forbidden. What alternate did you propose that would have the characteristics of never being routeable and therefore never have to potential to be delivered by IP rather than the intended MPLS LSP(s)? I must have missed that proposal. Obstruction means getting in the way (of some sort of progress) for no other reason than to get in the way. If you are making a point to steer us toward a better solution, that certainly hasn't been clear. If you think some entirely alternate solution (Y.1711) is a better solution, then you should work on that solution and stay out of this discussion. It is like disrupting the ISIS WG with a constant "OSPF is better" mantra or insisting that ISIS do everything the OSPF way (or doing the same in the OSPF WG). Curtis From owner-mpls@UU.NET Mon Dec 9 12:41:12 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 MAA20659 for ; Mon, 9 Dec 2002 12:41:12 -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 QQnsne16976 for ; Mon, 9 Dec 2002 17:44:03 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 QQnsne09989; Mon, 9 Dec 2002 17:40:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsne21342 for mpls-outgoing; Mon, 9 Dec 2002 17:40: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 QQnsne21324 for ; Mon, 9 Dec 2002 17:40:14 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 QQnsne22653 for ; Mon, 9 Dec 2002 17:38:45 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 QQnsne08267 for ; Mon, 9 Dec 2002 17:38:44 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQnsne08245 for ; Mon, 9 Dec 2002 17:38:43 GMT Received: from cisco.com (erosen-u10.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9HbnFp012669; Mon, 9 Dec 2002 09:37:49 -0800 (PST) Message-Id: <200212091737.gB9HbnFp012669@sj-msg-core-1.cisco.com> To: Alia Atlas cc: mpls@UU.NET Subject: Re: Last Call on MPLS ping In-reply-to: Your message of Mon, 09 Dec 2002 11:59:24 -0500. <5.1.0.14.2.20021209114830.01f57698@mailhost.avici.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Mon, 09 Dec 2002 12:37:49 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Alia> So, my concern here is for the case where the route is not an Alia> aggregate and the label indicates the egress attachment circuit as Alia> well as the encapsulation header for the packet. Alia> In this case, LSP ping would send an IP packet with the specific Alia> route's label and then the PSN's label. That isn't my interpretation of the draft. I think the intention is that the LSP ping carries only the "PSN label". That is, it carries only the label or labels needed to get it to the egress PE, not the label that identifies a particular VPN route (or a particular PWE3 pseudowire). If you wanted to know not only whether a particular LSP leads to the intended PE, but also whether that PE is a proper egress for a particular VPN route (or PWE3 pseudowire), then I think you would need to use the FEC stack TLV in the body of the message to identify that VPN route. Alia> I.e., consider if Alia> a packet comes in with a PSN label, PW label, and then an IPv4 Explicit Alia> NULL, as specified in Section 5.3: Alia> "To test an LSP that carries non-IP traffic, before injecting ICMP Alia> and MPLS ping messages into the LSP, the IPv4 Explicit NULL label Alia> should be prepended to such messages. The ingress and egress LSR's Alia> must follow the procedures defined in [LABEL-STACKING]" I'd agree that this is a strange passage ;-) Remember though that the context is RSVP-TE only. I'd guess that the purpose of the explicit null is to counteract the effect of the RSVP-TE L3PID field. From owner-mpls@UU.NET Mon Dec 9 12:57: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 MAA21820 for ; Mon, 9 Dec 2002 12:57:30 -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 QQnsng17704 for ; Mon, 9 Dec 2002 18:00: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 QQnsnf14391; Mon, 9 Dec 2002 17:58:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsnf22964 for mpls-outgoing; Mon, 9 Dec 2002 17:57: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 QQnsnf22939 for ; Mon, 9 Dec 2002 17:57:38 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 QQnsnf05804 for ; Mon, 9 Dec 2002 17:57: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 QQnsnf00019 for ; Mon, 9 Dec 2002 17:57:14 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 QQnsnf29947 for ; Mon, 9 Dec 2002 17:57:09 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9Hvb97027816 for ; Mon, 9 Dec 2002 12:57:38 -0500 (EST) 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 MAA09263 for ; Mon, 9 Dec 2002 12:57:07 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9Hv7I18721 for mpls@uu.net; Mon, 9 Dec 2002 12:57:07 -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 QQnsnf22759 for ; Mon, 9 Dec 2002 17:56: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 QQnsnf00775 for ; Mon, 9 Dec 2002 17:55:15 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 QQnsnf12548 for ; Mon, 9 Dec 2002 17:55:14 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 QQnsnf12530 for ; Mon, 9 Dec 2002 17:55:13 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 MAA36011; Mon, 9 Dec 2002 12:53:26 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212091753.MAA36011@workhorse.fictitious.org> To: "Gray, Eric" cc: "'curtis@fictitious.org'" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Mon, 09 Dec 2002 11:24:20 EST." <1117F7D44159934FB116E36F4ABF221B0267ED57@celox-ma1-ems1.celoxnetworks.com> Date: Mon, 09 Dec 2002 12:53:26 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <1117F7D44159934FB116E36F4ABF221B0267ED57@celox-ma1-ems1.celoxnetwor ks.com>, "Gray, Eric" writes: > Curtis, > > You probably need to remember that it's generally > not considered polite to speculate cynical motivations > for why people object to an idea that you have no > particular objection to. Your stated belief that people > are "grasping at straws" in objecting to the use of the > 127/8 address range because they object to MPLS-Ping may > be completely false in every case - and is certainly so > in my own case. Fine. Lets hear the technical reasons for the objections. [btw- I was replying to a request that I elaborate on that.] > Please try to avoid bringing things to the personal > level. It's highly unprofessional, at the very least, > and certainly not conducive to rational discussion. > > I object to the use of this address range for the > purpose that has been stated thus far. The reason why I > object to it, is that I see it as pointless and possibly > problematic. I have no objection to MPLS-Ping itself. > > From a posting by George Swallow (roughly 7:00 > P.M. on 12/05/02 - see excerpt below), I got the clear > impression that the use of this address range was > intended to allow a sender to "tickle" all of the paths > that might be used by an ECMP load sharing set of LSPs. > If that is the case, this is hopelessly useless for that > intent, since the last byte in the IP destination address > is NOT going to be used for ECMP load sharing of LSPs in > many reasonable LSR ECMP implementations. It is not even > guaranteed to be used in IP forwarding. There are, for > example, perfectly reasonable hashing algorithms that use > the first two bytes in both the source and destination IP > addresses. There are other ECMP hash algorithms that use > SIPA exclusively. What is the point in using the 127/8 > address range if any of these are in use? I think ECMP processing is broken and that use of the lower 8 or even 24 bits of 127/8 is not the way to handle it. I'll provide more detail on ECMP in a later response (there are a number of thread). > If there is another reason for using this address > range, it either has not been stated, or I missed it. If > there is a good reason to do it, I would not object to it. > But there is not and - IMHO - there is a non-zero risk in > using it. In other words, cost is possibly higher than > we know and benefit is definitely lower than we seem to > be led to believe. The reason for using it is that 127/8 is never routable so it won't wander any further than the egress of the LSP due to IP forwarding. If the LSP is somehow misrouted it is a way of indicating "whoever gets this please respond". For LDP the ingress may not know the routeable loopback address of the LDP endpoint. > So I object to the use of the address range, not to > the usefulness of MPLS-Ping. OK. And by citing ECMP, you have now cited a technical reason so we can have a technical discussion. I'll reply to Eric Rosen's reply to this and give more detail. Curtis > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 From owner-mpls@UU.NET Mon Dec 9 13:12: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 NAA22614 for ; Mon, 9 Dec 2002 13:12: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 QQnsnh03922 for ; Mon, 9 Dec 2002 18:15: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 QQnsng22690; Mon, 9 Dec 2002 18:08:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsng11528 for mpls-outgoing; Mon, 9 Dec 2002 18:07: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 QQnsng11518 for ; Mon, 9 Dec 2002 18:07: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 QQnsng00234 for ; Mon, 9 Dec 2002 18:07: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 QQnsng09539 for ; Mon, 9 Dec 2002 18:07:12 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 QQnsng09525 for ; Mon, 9 Dec 2002 18:07:11 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9I7eDt029459 for ; Mon, 9 Dec 2002 13:07:40 -0500 (EST) 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 NAA10067 for ; Mon, 9 Dec 2002 13:07:10 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9I79o20992 for mpls@uu.net; Mon, 9 Dec 2002 13:07:09 -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 QQnsng11089 for ; Mon, 9 Dec 2002 18:05:38 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 QQnsng26250 for ; Mon, 9 Dec 2002 18:05: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 QQnsng25424 for ; Mon, 9 Dec 2002 18:05: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 QQnsng25420 for ; Mon, 9 Dec 2002 18:05:35 GMT Received: (qmail 14246 invoked by uid 104); 9 Dec 2002 18:05:34 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4236. . Clean. Processed in 0.538757 secs); 09 Dec 2002 18:05:34 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 9 Dec 2002 18:05:34 -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 gB9I5XQ29357; Mon, 9 Dec 2002 10:05:33 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Mon, 9 Dec 2002 10:05:33 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B64@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'curtis@fictitious.org'" Cc: David Allan , neil.2.harrison@bt.com, swallow@cisco.com, mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Mon, 9 Dec 2002 10:05:32 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk I think you are just imagining things that are not true. -Shahram > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: Monday, December 09, 2002 12:23 PM > To: Shahram Davari > Cc: 'curtis@fictitious.org'; David Allan; neil.2.harrison@bt.com; > swallow@cisco.com; mpls@UU.NET > Subject: Re: Last call on LSP Ping > > > > In message > <4B6D09F3B826D411A67300D0B706EFDEB03B5E@nt-exch-yow.pmc-sierra.bc.ca > >, Shahram Davari writes: > > Curtis, > > > > > Dave, > > > > > > Since you asked, yes I do think the comments by two or more > > > individuals are more obstructionist than constructive, > but it seems > > > particularly clear in this issue. > > > > > > > I am disturbed by this statement. Would you please point > out which of my > > ignored comments are obstructive rather than constructive? As far as > > I can see many of my comments were even echoed by Eric > rosen (unless you beli > > eve > > that he intends to obstruct his own company's proposal). > > > > Regarding the 127/8 issue, many others have the same > concern. Besides, > > this is not an obstructive comment, because there are many > other ways around > > it. > > Obstructive means the draft will fall apart without it. > > > > -Shahram > > > You have not cited any technical reason for avoiding 127/8. You have > cited documents and tried to manipulate the interpretation to claim > that any use of 127/8 is forbidden. > > What alternate did you propose that would have the characteristics of > never being routeable and therefore never have to potential to be > delivered by IP rather than the intended MPLS LSP(s)? I must have > missed that proposal. > > Obstruction means getting in the way (of some sort of progress) for no > other reason than to get in the way. > > If you are making a point to steer us toward a better solution, that > certainly hasn't been clear. If you think some entirely alternate > solution (Y.1711) is a better solution, then you should work on that > solution and stay out of this discussion. It is like disrupting the > ISIS WG with a constant "OSPF is better" mantra or insisting that ISIS > do everything the OSPF way (or doing the same in the OSPF WG). > > Curtis > From owner-mpls@UU.NET Mon Dec 9 13:17: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 NAA22963 for ; Mon, 9 Dec 2002 13:17:52 -0500 (EST) 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 QQnsmt06066; Mon, 9 Dec 2002 14:59:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsmt12668 for mpls-outgoing; Mon, 9 Dec 2002 14:58: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 QQnsmt12608 for ; Mon, 9 Dec 2002 14:58:15 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 QQnsmt29947 for ; Mon, 9 Dec 2002 14:57:56 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 QQnsmt28517 for ; Mon, 9 Dec 2002 14:57:55 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 QQnsmt28512 for ; Mon, 9 Dec 2002 14:57:55 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9EwNMh028461 for ; Mon, 9 Dec 2002 09:58:23 -0500 (EST) 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 JAA25029 for ; Mon, 9 Dec 2002 09:57:52 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9EvqI13638 for mpls@uu.net; Mon, 9 Dec 2002 09:57:52 -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 QQnsmr09008 for ; Mon, 9 Dec 2002 14:24: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 QQnsmr20454 for ; Mon, 9 Dec 2002 14:24: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 QQnsmr05312 for ; Mon, 9 Dec 2002 14:24:06 GMT Received: from web14509.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web14509.mail.yahoo.com [216.136.224.168]) id QQnsmr05293 for ; Mon, 9 Dec 2002 14:24:05 GMT Message-ID: <20021209142401.24278.qmail@web14509.mail.yahoo.com> Received: from [130.65.88.102] by web14509.mail.yahoo.com via HTTP; Mon, 09 Dec 2002 06:24:01 PST Date: Mon, 9 Dec 2002 06:24:01 -0800 (PST) From: nitin p Subject: Re: [MPLS-OPS]: Jitter and MPLS To: GAlmaalouf@aol.com, eosborne@cisco.com, jshen@cad.zju.edu.cn Cc: rameshbabu_j@infosys.com, mpls-ops@mplsrc.com, mpls@UU.NET In-Reply-To: <104.217abc80.2b25fc22@aol.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi George, I have posted my results in of the mails, but here they are again: Ingress: 3.665 milli seconds Egress: 0.035 milliseconds core: 0.018 milliseconds IP: 0.023 milliseconds. For my measurements I have attached a sniffer at both incomming and outgoing interface (same sniffer for both so no clocking issue). I did the same thing for boths LSR and LERs. Question of number of LSRs should not affect the results, considering my measuring technique. Jing said He is also getting similar results, I am not sure how he has done his measurement. Thanks, Nitin --- GAlmaalouf@aol.com wrote: > Nitin- > > It would be much helpful if you can specify the > delay in a quantitative > manner. This way we can really understand what are > you talking about in term > of delays. Also, the specific number of Hops or LPS > router, how many egress > and ingress steps involved in the calculation. A > general observation would > not be very accurate, since the implementation > would be very different from > one application versus the other, and from one type > of services versus > another. > > Thanks- > > George > > > __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From owner-mpls@UU.NET Mon Dec 9 13:18: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 NAA23028 for ; Mon, 9 Dec 2002 13:18:37 -0500 (EST) 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 QQnsmu10236; Mon, 9 Dec 2002 15:01:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsmt12692 for mpls-outgoing; Mon, 9 Dec 2002 14:58:57 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 QQnsmt12586 for ; Mon, 9 Dec 2002 14:58:11 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 QQnsmt11188 for ; Mon, 9 Dec 2002 14:58: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 QQnsmt28641 for ; Mon, 9 Dec 2002 14:58:04 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 QQnsmt28632 for ; Mon, 9 Dec 2002 14:58:04 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9EwVGK028485 for ; Mon, 9 Dec 2002 09:58:32 -0500 (EST) 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 JAA25038 for ; Mon, 9 Dec 2002 09:58:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9Ew1F13648 for mpls@uu.net; Mon, 9 Dec 2002 09:58:01 -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 QQnsms09988 for ; Mon, 9 Dec 2002 14:38: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 QQnsms08966 for ; Mon, 9 Dec 2002 14:38: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 QQnsms15134 for ; Mon, 9 Dec 2002 14:38:31 GMT Received: from www.apara.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.106.140.220]) id QQnsms15130 for ; Mon, 9 Dec 2002 14:38:31 GMT Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id gB9ErhM05177 for ; Mon, 9 Dec 2002 20:23:43 +0530 Received: from alok ([203.124.140.100]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id gB9EraT05153; Mon, 9 Dec 2002 20:23:37 +0530 Message-ID: <021001c29f91$d4de2dc0$81c802c0@alok> From: "alok" To: "nitin p" , , , Cc: , , References: <20021209142401.24278.qmail@web14509.mail.yahoo.com> Subject: Re: [MPLS-OPS]: Jitter and MPLS Date: Mon, 9 Dec 2002 20:16:44 +0530 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.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit hi Nitin, just curious... your IP result says "0.023" end to end.. can u share "IP across what was your ingress LER" IP across your Egress LER and IP across your core too for a given packet? -rgds alok ----- Original Message ----- From: nitin p To: ; ; Cc: ; ; Sent: Monday, December 09, 2002 7:54 PM Subject: Re: [MPLS-OPS]: Jitter and MPLS > Hi George, > I have posted my results in of the mails, but here > they are again: > > Ingress: 3.665 milli seconds > Egress: 0.035 milliseconds > core: 0.018 milliseconds > > IP: 0.023 milliseconds. > > For my measurements I have attached a sniffer at both > incomming and outgoing interface (same sniffer for > both so no clocking issue). I did the same thing for > boths LSR and LERs. Question of number of LSRs should > not affect the results, considering my measuring > technique. > Jing said He is also getting similar results, I am not > sure how he has done his measurement. > > Thanks, > Nitin > > > > --- GAlmaalouf@aol.com wrote: > > Nitin- > > > > It would be much helpful if you can specify the > > delay in a quantitative > > manner. This way we can really understand what are > > you talking about in term > > of delays. Also, the specific number of Hops or LPS > > router, how many egress > > and ingress steps involved in the calculation. A > > general observation would > > not be very accurate, since the implementation > > would be very different from > > one application versus the other, and from one type > > of services versus > > another. > > > > Thanks- > > > > George > > > > > > > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > > ------- > The MPLS-OPS Mailing List > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > From owner-mpls@UU.NET Mon Dec 9 13:33:08 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 NAA23618 for ; Mon, 9 Dec 2002 13:33:07 -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 QQnsni21628 for ; Mon, 9 Dec 2002 18:35: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 QQnsni16112; Mon, 9 Dec 2002 18:33:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsni14393 for mpls-outgoing; Mon, 9 Dec 2002 18:32: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 QQnsni14384 for ; Mon, 9 Dec 2002 18:32: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 QQnsni01313 for ; Mon, 9 Dec 2002 18:31: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 QQnsni02734 for ; Mon, 9 Dec 2002 18:31:58 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 QQnsni02728 for ; Mon, 9 Dec 2002 18:31:58 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Dec 2002 13:31:58 -0500 Message-ID: <1117F7D44159934FB116E36F4ABF221B0267ED59@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'erosen@cisco.com'" , "Gray, Eric" Cc: "'curtis@fictitious.org'" , mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Mon, 9 Dec 2002 13:31:53 -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 Eric, Hmmm, how about 0.0.0.0? Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Monday, December 09, 2002 11:37 AM > To: Gray, Eric > Cc: 'curtis@fictitious.org'; mpls@UU.NET > Subject: Re: Last call on LSP Ping > > > EricG> If there is another reason for using this address range, it > either > EricG> has not been stated, or I missed it. > > Well, what should the tunnel ingress put into the IP destination field > of > the "LSP Ping" UDP packet? We want the packet to be consumed by the > egress > even if the egress isn't who the ingress thinks it is. (That's how we > get > the error response indicating that the tunneled packets have > been > misrouted.) Thus we need to put in a "well known" address which will > be > interpreted by the tunnel egress as meaning "for me". > > Use of one of the loopback addresses (127.x.y.z) seems to achieve this > goal. > I think it's kind of a nifty hack ;-) > > As Curtis has pointed out, there is ample precedent for having a > tunneled > packet carry addressing information which is to be interpreted in > the > context of the egress. From owner-mpls@UU.NET Mon Dec 9 13:37:02 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 NAA23823 for ; Mon, 9 Dec 2002 13:37:02 -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 QQnsni12199 for ; Mon, 9 Dec 2002 18:39:49 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 QQnsni07076; Mon, 9 Dec 2002 18:36:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsni14880 for mpls-outgoing; Mon, 9 Dec 2002 18:36: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 QQnsni14824 for ; Mon, 9 Dec 2002 18:36:31 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 QQnsni29504 for ; Mon, 9 Dec 2002 18:36: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 QQnsni06425 for ; Mon, 9 Dec 2002 18:36:16 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 QQnsni06419 for ; Mon, 9 Dec 2002 18:36:15 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9Iai4Y007197 for ; Mon, 9 Dec 2002 13:36:44 -0500 (EST) 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 NAA12420 for ; Mon, 9 Dec 2002 13:36:13 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9IaDw26038 for mpls@uu.net; Mon, 9 Dec 2002 13:36:13 -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 QQnsni14535 for ; Mon, 9 Dec 2002 18:35:12 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 QQnsni09790 for ; Mon, 9 Dec 2002 18:34: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 QQnsni19245 for ; Mon, 9 Dec 2002 18:34:32 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 QQnsni19149 for ; Mon, 9 Dec 2002 18:34:28 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 NAA36084; Mon, 9 Dec 2002 13:32:34 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212091832.NAA36084@workhorse.fictitious.org> To: erosen@cisco.com cc: "Gray, Eric" , "'curtis@fictitious.org'" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Mon, 09 Dec 2002 11:36:56 EST." <200212091636.gB9GavFp025626@sj-msg-core-1.cisco.com> Date: Mon, 09 Dec 2002 13:32:34 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <200212091636.gB9GavFp025626@sj-msg-core-1.cisco.com>, Eric Rosen wr ites: > > EricG> If there is another reason for using this address range, it either > EricG> has not been stated, or I missed it. > > Well, what should the tunnel ingress put into the IP destination field of > the "LSP Ping" UDP packet? We want the packet to be consumed by the egress > even if the egress isn't who the ingress thinks it is. (That's how we get > the error response indicating that the tunneled packets have been > misrouted.) Thus we need to put in a "well known" address which will be > interpreted by the tunnel egress as meaning "for me". > > Use of one of the loopback addresses (127.x.y.z) seems to achieve this goal. > I think it's kind of a nifty hack ;-) > > As Curtis has pointed out, there is ample precedent for having a tunneled > packet carry addressing information which is to be interpreted in the > context of the egress. Eric, I think the use of 127.0.0.1 is a good idea, however, I don't think the use of 127.x.y.z to test ECMP is a good idea. I am not objecting to use of 127/8, just the way ECMP is proposed to be handled. In the simple case, the ingress puts on one label or a small label stack. That ingress may take traffic and spread it over more than one LSP, but then the label stack is different. Even though ECMP is used, the ingress has more than one LSP to test. If you step TTL in increments of one, at each MPLS LSP hop TTL will expire if TTL is being decremented. That LSR can then provide its mapping and LSP-ping need the ability for that midpoint LSR to provide more than one mapping if ECMP is used. The ingress then needs to know how many mappings there are and how to get packets into each of the available mappings. There are two types of possible mappings at a point that does ECMP, label stack based, and IP header based. For label stack based mappings, there will only be one mapping for a given label stack (although for a given LSP there may be multiple paths used for different lower labels). The point is that for a label stack based ECMP, only one label mapping is returned, the one for the exact label stack used. If you want to know all mappings, don't include a lower label. For a TE tunnel, there is no branching at midpoints for an LSP. Therefore there is only one mapping. The hashing and ECMP occurs only at the ingress. The remaining case is an LDP tunnel that uses IP header based ECMP at midpoint. To do this an LSR has to be snooping the traffic for IP headers and consistently seeing them. Please lets not go into a tangient over whether this is a good idea, simply accept that it happens and MPLS-ping has to deal with it. In this case, TTL expires and the midpoint has to return more than one mapping. If the spliting algorithm is proprietary or uses a seeded hash, then the simplest way to indicate how to get into any one path is for the midpoint to provide a address within some range, that the ingress can use to get there. Even this is problematic since some implementations periodically reseed the hash with a random number. To be general, the ingress would need to provide an acceptable range (such as 127/24 or 127/8) and the midpoint would need to provide an address and a time duration for which that address will work (indication of when the seed will be changed). The only case where a traffic split occurs in a TE midpoint is proprietary link bundlings which use either label stack or IP header methods of splitting. In this case, the bundling is better exposed for diagnostic capability and the same issues as above hold. A very minor points I don't know about you but I can ping 127.0.0.1 but not 127.0.0.2 on my BSD boxes (no big deal, just a change). So I'm still in favor of using 127/8 but think that ECMP could be done better. Curtis From owner-mpls@UU.NET Mon Dec 9 13:40: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 NAA23967 for ; Mon, 9 Dec 2002 13:40:01 -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 QQnsni25968 for ; Mon, 9 Dec 2002 18:42: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 QQnsni21814; Mon, 9 Dec 2002 18:40:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsni15128 for mpls-outgoing; Mon, 9 Dec 2002 18:39: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 QQnsni15103 for ; Mon, 9 Dec 2002 18:39: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 QQnsni04633 for ; Mon, 9 Dec 2002 18:37: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 QQnsni08340 for ; Mon, 9 Dec 2002 18:37:43 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 QQnsni08265 for ; Mon, 9 Dec 2002 18:37:36 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9IbteY007647 for ; Mon, 9 Dec 2002 13:37:55 -0500 (EST) 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 NAA12500 for ; Mon, 9 Dec 2002 13:37:24 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9IbOU26264 for mpls@uu.net; Mon, 9 Dec 2002 13:37:24 -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 QQnsni14732 for ; Mon, 9 Dec 2002 18:36:13 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 QQnsni08443 for ; Mon, 9 Dec 2002 18:34: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 QQnsni04992 for ; Mon, 9 Dec 2002 18:34:41 GMT Received: from father.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQnsni04979 for ; Mon, 9 Dec 2002 18:34:40 GMT Received: (qmail 6266 invoked by uid 104); 9 Dec 2002 18:34:39 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4236. . Clean. Processed in 0.49742 secs); 09 Dec 2002 18:34:39 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 9 Dec 2002 18:34:38 -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 gB9IYXQ17138; Mon, 9 Dec 2002 10:34:33 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Mon, 9 Dec 2002 10:34:33 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B65@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'curtis@fictitious.org'" Cc: David Allan , neil.2.harrison@bt.com, swallow@cisco.com, mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Mon, 9 Dec 2002 10:34:32 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > You have not cited any technical reason for avoiding 127/8. You have > cited documents and tried to manipulate the interpretation to claim > that any use of 127/8 is forbidden. Isn't compliance to RFCs a legitimate technical reason? It is like not stopping at red light, and asking for a reason even though the traffic law says "A car SHOULD never pass a red light". SHOULD is there because ambulances could pass. > > What alternate did you propose that would have the characteristics of > never being routeable and therefore never have to potential to be > delivered by IP rather than the intended MPLS LSP(s)? I must have > missed that proposal. First of all I did propose using the egress IP address and setting the TTL=1 in the IP header. This makes sure that the LSP-ping packet will not get forwarded after the MPLS labels are poped. Secondly, it is not my draft, those who have written it should find alternate methods. > > Obstruction means getting in the way (of some sort of progress) for no > other reason than to get in the way. And how did you reach to this conclusion? (imaginations I guess !) > > If you are making a point to steer us toward a better solution, that > certainly hasn't been clear. Ok., let me make it clear: I want LSP-ping to be improved. > If you think some entirely alternate > solution (Y.1711) is a better solution, then you should work on that > solution and stay out of this discussion. > It is like disrupting the > ISIS WG with a constant "OSPF is better" mantra or insisting that ISIS > do everything the OSPF way (or doing the same in the OSPF WG). Again imaginations........ This has nothing to do with Y.1711. In fact LSP-ping can never do the job of Y.1711, since it is more complex and very slow. I want LSP-ping for diagnostics purpose. So I don't benefit from stopping it. All I want is a reasonable draft, that does not behave different in different networks. -Shahram > > Curtis > From owner-mpls@UU.NET Mon Dec 9 13:41: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 NAA24126 for ; Mon, 9 Dec 2002 13:41:58 -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 QQnsni04624 for ; Mon, 9 Dec 2002 18:44:27 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 QQnsni29013; Mon, 9 Dec 2002 18:41:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsni15449 for mpls-outgoing; Mon, 9 Dec 2002 18:41: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 QQnsni15290 for ; Mon, 9 Dec 2002 18:40:57 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 QQnsni24892 for ; Mon, 9 Dec 2002 18:40:36 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 QQnsni13579 for ; Mon, 9 Dec 2002 18:40:35 GMT Received: from newdev.harvard.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: newdev.eecs.harvard.edu [140.247.60.212]) id QQnsni13561 for ; Mon, 9 Dec 2002 18:40:35 GMT Received: (from sob@localhost) by newdev.harvard.edu (8.12.2/8.12.2) id gB9Id1g2023552 for mpls@uu.net; Mon, 9 Dec 2002 13:39:01 -0500 (EST) Date: Mon, 9 Dec 2002 13:39:01 -0500 (EST) From: Scott Bradner Message-Id: <200212091839.gB9Id1g2023552@newdev.harvard.edu> To: mpls@UU.NET Subject: Re: a personal opinion on what to do about the sub-ip area Sender: owner-mpls@UU.NET Precedence: bulk if you have an opinion on the future of the sub-ip area and want to express it - please send that opinion to the ietf@ietf.org &/or the iesg@ietf.org lists for my current opinion (whatever that is worth) please see http://www.ietf.org//mail-archive/ietf/Current/msg18465.html thanks Scott From owner-mpls@UU.NET Mon Dec 9 13:46:43 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 NAA24350 for ; Mon, 9 Dec 2002 13:46:43 -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 QQnsnj28737 for ; Mon, 9 Dec 2002 18:49:11 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 QQnsnj20736; Mon, 9 Dec 2002 18:45:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsni15873 for mpls-outgoing; Mon, 9 Dec 2002 18:44:41 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 QQnsni15786 for ; Mon, 9 Dec 2002 18:44:26 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 QQnsni29894 for ; Mon, 9 Dec 2002 18:43:16 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 QQnsni00956 for ; Mon, 9 Dec 2002 18:42:40 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQnsni00944 for ; Mon, 9 Dec 2002 18:42:39 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Dec 2002 13:42:39 -0500 Message-ID: <1117F7D44159934FB116E36F4ABF221B0267ED5A@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'curtis@fictitious.org'" , erosen@cisco.com Cc: "Gray, Eric" , mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Mon, 9 Dec 2002 13:42:29 -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 I also would think this better if it specifically said use 127.0.0.1 as opposed to what it currently says. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: Monday, December 09, 2002 1:33 PM > To: erosen@cisco.com > Cc: Gray, Eric; 'curtis@fictitious.org'; mpls@UU.NET > Subject: Re: Last call on LSP Ping > > > In message <200212091636.gB9GavFp025626@sj-msg-core-1.cisco.com>, Eric > Rosen wr > ites: > > > > EricG> If there is another reason for using this address range, it > either > > EricG> has not been stated, or I missed it. > > > > Well, what should the tunnel ingress put into the IP destination > field of > > the "LSP Ping" UDP packet? We want the packet to be consumed by the > egress > > even if the egress isn't who the ingress thinks it is. (That's how we > get > > the error response indicating that the tunneled packets have > been > > misrouted.) Thus we need to put in a "well known" address which > will be > > interpreted by the tunnel egress as meaning "for me". > > > > Use of one of the loopback addresses (127.x.y.z) seems to achieve this > goal. > > I think it's kind of a nifty hack ;-) > > > > As Curtis has pointed out, there is ample precedent for having a > tunneled > > packet carry addressing information which is to be interpreted in > the > > context of the egress. > > > > Eric, > > I think the use of 127.0.0.1 is a good idea, however, I don't think > the use of 127.x.y.z to test ECMP is a good idea. I am not objecting > to use of 127/8, just the way ECMP is proposed to be handled. > > In the simple case, the ingress puts on one label or a small label > stack. That ingress may take traffic and spread it over more than one > LSP, but then the label stack is different. Even though ECMP is used, > the ingress has more than one LSP to test. > > If you step TTL in increments of one, at each MPLS LSP hop TTL will > expire if TTL is being decremented. That LSR can then provide its > mapping and LSP-ping need the ability for that midpoint LSR to provide > more than one mapping if ECMP is used. > > The ingress then needs to know how many mappings there are and how to > get packets into each of the available mappings. There are two types > of possible mappings at a point that does ECMP, label stack based, and > IP header based. > > For label stack based mappings, there will only be one mapping for a > given label stack (although for a given LSP there may be multiple > paths used for different lower labels). The point is that for a label > stack based ECMP, only one label mapping is returned, the one for the > exact label stack used. If you want to know all mappings, don't > include a lower label. > > For a TE tunnel, there is no branching at midpoints for an LSP. > Therefore there is only one mapping. The hashing and ECMP occurs > only at the ingress. > > The remaining case is an LDP tunnel that uses IP header based ECMP at > midpoint. To do this an LSR has to be snooping the traffic for IP > headers and consistently seeing them. Please lets not go into a > tangient over whether this is a good idea, simply accept that it > happens and MPLS-ping has to deal with it. In this case, TTL expires > and the midpoint has to return more than one mapping. If the spliting > algorithm is proprietary or uses a seeded hash, then the simplest way > to indicate how to get into any one path is for the midpoint to > provide a address within some range, that the ingress can use to get > there. Even this is problematic since some implementations > periodically reseed the hash with a random number. To be general, the > ingress would need to provide an acceptable range (such as 127/24 or > 127/8) and the midpoint would need to provide an address and a time > duration for which that address will work (indication of when the seed > will be changed). > > The only case where a traffic split occurs in a TE midpoint is > proprietary link bundlings which use either label stack or IP header > methods of splitting. In this case, the bundling is better exposed > for diagnostic capability and the same issues as above hold. > > A very minor points I don't know about you but I can ping 127.0.0.1 > but not 127.0.0.2 on my BSD boxes (no big deal, just a change). > > So I'm still in favor of using 127/8 but think that ECMP could be done > better. > > Curtis From owner-mpls@UU.NET Mon Dec 9 13:54:13 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 NAA24719 for ; Mon, 9 Dec 2002 13:54:12 -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 QQnsnj13442 for ; Mon, 9 Dec 2002 18:57:01 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 QQnsnj03210; Mon, 9 Dec 2002 18:51:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsnj17090 for mpls-outgoing; Mon, 9 Dec 2002 18:50:57 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 QQnsnj17080 for ; Mon, 9 Dec 2002 18:50: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 QQnsnj14739 for ; Mon, 9 Dec 2002 18:50: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 QQnsnj00906 for ; Mon, 9 Dec 2002 18:50:16 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 QQnsnj00704 for ; Mon, 9 Dec 2002 18:50:09 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9Iobn7011274 for ; Mon, 9 Dec 2002 13:50:37 -0500 (EST) 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 NAA13519 for ; Mon, 9 Dec 2002 13:50:07 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9Io7b29664 for mpls@uu.net; Mon, 9 Dec 2002 13:50:07 -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 QQnsnj16895 for ; Mon, 9 Dec 2002 18:48:28 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 QQnsnj16147 for ; Mon, 9 Dec 2002 18:48:27 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 QQnsnj26984 for ; Mon, 9 Dec 2002 18:48:16 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 QQnsnj26532 for ; Mon, 9 Dec 2002 18:48:01 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 NAA36310; Mon, 9 Dec 2002 13:46:00 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212091846.NAA36310@workhorse.fictitious.org> To: "Gray, Eric" cc: "'erosen@cisco.com'" , "'curtis@fictitious.org'" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Mon, 09 Dec 2002 13:31:53 EST." <1117F7D44159934FB116E36F4ABF221B0267ED59@celox-ma1-ems1.celoxnetworks.com> Date: Mon, 09 Dec 2002 13:46:00 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <1117F7D44159934FB116E36F4ABF221B0267ED59@celox-ma1-ems1.celoxnetwor ks.com>, "Gray, Eric" writes: > Eric, > > Hmmm, how about 0.0.0.0? And the advantages are... ? For ECMP the address range of 0.0.0.0/32 is a problem or were you suggesting a larger subnet such as 0/8. I think this is a lot worse solution than 127/8. Curtis > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > > -----Original Message----- > > From: Eric Rosen [mailto:erosen@cisco.com] > > Sent: Monday, December 09, 2002 11:37 AM > > To: Gray, Eric > > Cc: 'curtis@fictitious.org'; mpls@UU.NET > > Subject: Re: Last call on LSP Ping > > > > > > EricG> If there is another reason for using this address range, it > > either > > EricG> has not been stated, or I missed it. > > > > Well, what should the tunnel ingress put into the IP destination field > > of > > the "LSP Ping" UDP packet? We want the packet to be consumed by the > > egress > > even if the egress isn't who the ingress thinks it is. (That's how we > > get > > the error response indicating that the tunneled packets have > > been > > misrouted.) Thus we need to put in a "well known" address which will > > be > > interpreted by the tunnel egress as meaning "for me". > > > > Use of one of the loopback addresses (127.x.y.z) seems to achieve this > > goal. > > I think it's kind of a nifty hack ;-) > > > > As Curtis has pointed out, there is ample precedent for having a > > tunneled > > packet carry addressing information which is to be interpreted in > > the > > context of the egress. > > From owner-mpls@UU.NET Mon Dec 9 13:54: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 NAA24733 for ; Mon, 9 Dec 2002 13:54: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 QQnsnj19259 for ; Mon, 9 Dec 2002 18:57: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 QQnsnj15774; Mon, 9 Dec 2002 18:55:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsnj17602 for mpls-outgoing; Mon, 9 Dec 2002 18:55:11 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 QQnsnj17588 for ; Mon, 9 Dec 2002 18:55:06 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 QQnsnj01730 for ; Mon, 9 Dec 2002 18:54:20 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 QQnsnj14830 for ; Mon, 9 Dec 2002 18:54:20 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQnsnj14823 for ; Mon, 9 Dec 2002 18:54:19 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Dec 2002 13:54:19 -0500 Message-ID: <1117F7D44159934FB116E36F4ABF221B0267ED5B@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'curtis@fictitious.org'" Cc: "'erosen@cisco.com'" , mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Mon, 9 Dec 2002 13:54:17 -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 am suggesting that attempting to use any address range as a mechanism for testing ECMP routes is a mistake. I am also suggesting that a single address is sufficient to satisfy the need Eric Rosen points out. Finally, if you were suggesting that 127.0.0.1 should be specified (as opposed to 127.0.0.0/8) for the same purpose, then I agree with you. Any address based approach to trying to test ECMP load sharing paths implies prior knowledge of all ECMP algorithms in use and is therefore broken. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: Monday, December 09, 2002 1:46 PM > To: Gray, Eric > Cc: 'erosen@cisco.com'; 'curtis@fictitious.org'; mpls@UU.NET > Subject: Re: Last call on LSP Ping > > > In message <1117F7D44159934FB116E36F4ABF221B0267ED59@celox-ma1- > ems1.celoxnetwor > ks.com>, "Gray, Eric" writes: > > Eric, > > > > Hmmm, how about 0.0.0.0? > > And the advantages are... ? > > For ECMP the address range of 0.0.0.0/32 is a problem or were you > suggesting a larger subnet such as 0/8. I think this is a lot worse > solution than 127/8. > > Curtis > > > > Eric W. Gray > > Systems Architect > > Celox Networks, Inc. > > egray@celoxnetworks.com > > 508 305 7214 > > > > > > > -----Original Message----- > > > From: Eric Rosen [mailto:erosen@cisco.com] > > > Sent: Monday, December 09, 2002 11:37 AM > > > To: Gray, Eric > > > Cc: 'curtis@fictitious.org'; mpls@UU.NET > > > Subject: Re: Last call on LSP Ping > > > > > > > > > EricG> If there is another reason for using this address range, it > > > either > > > EricG> has not been stated, or I missed it. > > > > > > Well, what should the tunnel ingress put into the IP destination > field > > > of > > > the "LSP Ping" UDP packet? We want the packet to be consumed by the > > > egress > > > even if the egress isn't who the ingress thinks it is. (That's how > we > > > get > > > the error response indicating that the tunneled packets have > > > been > > > misrouted.) Thus we need to put in a "well known" address which > will > > > be > > > interpreted by the tunnel egress as meaning "for me". > > > > > > Use of one of the loopback addresses (127.x.y.z) seems to achieve this > > > goal. > > > I think it's kind of a nifty hack ;-) > > > > > > As Curtis has pointed out, there is ample precedent for having a > > > tunneled > > > packet carry addressing information which is to be interpreted > in > > > the > > > context of the egress. > > > > From owner-mpls@UU.NET Mon Dec 9 14:01:56 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 OAA25180 for ; Mon, 9 Dec 2002 14:01:56 -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 QQnsnk19619 for ; Mon, 9 Dec 2002 19:04: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 QQnsnk16025; Mon, 9 Dec 2002 19:02:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsnk25044 for mpls-outgoing; Mon, 9 Dec 2002 19:02:11 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 QQnsnk24936 for ; Mon, 9 Dec 2002 19:02:10 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 QQnsnk22269 for ; Mon, 9 Dec 2002 19:01:59 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 QQnsnk25548 for ; Mon, 9 Dec 2002 19:01:59 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 QQnsnk25520 for ; Mon, 9 Dec 2002 19:01:58 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9J2Qbk014479 for ; Mon, 9 Dec 2002 14:02:27 -0500 (EST) 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 OAA14595 for ; Mon, 9 Dec 2002 14:01:56 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9J1ux03232 for mpls@uu.net; Mon, 9 Dec 2002 14:01:56 -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 QQnsnk21287 for ; Mon, 9 Dec 2002 19:00:28 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 QQnsnj11646 for ; Mon, 9 Dec 2002 18:59: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 QQnsnj13609 for ; Mon, 9 Dec 2002 18:59: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 QQnsnj13602 for ; Mon, 9 Dec 2002 18:59: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 NAA36364; Mon, 9 Dec 2002 13:57:44 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212091857.NAA36364@workhorse.fictitious.org> To: Shahram Davari cc: "'curtis@fictitious.org'" , David Allan , neil.2.harrison@bt.com, swallow@cisco.com, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Mon, 09 Dec 2002 10:34:32 PST." <4B6D09F3B826D411A67300D0B706EFDEB03B65@nt-exch-yow.pmc-sierra.bc.ca> Date: Mon, 09 Dec 2002 13:57:44 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4B6D09F3B826D411A67300D0B706EFDEB03B65@nt-exch-yow.pmc-sierra.bc.ca >, Shahram Davari writes: > > You have not cited any technical reason for avoiding 127/8. You have > > cited documents and tried to manipulate the interpretation to claim > > that any use of 127/8 is forbidden. > > Isn't compliance to RFCs a legitimate technical reason? You don't have a leg to stand on with this one. I've already stated why use of 127/8 to deliver packets to the loopback is the intended purpose of 127/8 and therefore no RFC is in violation. > > What alternate did you propose that would have the characteristics of > > never being routeable and therefore never have to potential to be > > delivered by IP rather than the intended MPLS LSP(s)? I must have > > missed that proposal. > > First of all I did propose using the egress IP address and setting the > TTL=1 in the IP header. This makes sure that the LSP-ping packet will > not get forwarded after the MPLS labels are poped. Glad to see this change to a technical discussion. Took a while. This proposal has two flaws, 1) when the label gets POPed and the egress isn't the router you thought it should be the response is an ICMP TTL expired, 2) no way to handle ECMP is proposed. Please indicate how you would handle ECMP. > Secondly, it is > not my draft, those who have written it should find alternate methods. They have proposed something that will work. You have now made a counterproposal. You need to justify on technical grounds why not to use their proposal, why yours will work, and why yours is better. > Ok., let me make it clear: I want LSP-ping to be improved. Great. So drop the RFC1700 nonsense and lets move on. Curtis From owner-mpls@UU.NET Mon Dec 9 14:17:43 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 OAA26266 for ; Mon, 9 Dec 2002 14:17:43 -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 QQnsnl14312 for ; Mon, 9 Dec 2002 19:20: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 QQnsnk02903; Mon, 9 Dec 2002 19:14:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsnk08250 for mpls-outgoing; Mon, 9 Dec 2002 19:14:13 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 QQnsnk08243 for ; Mon, 9 Dec 2002 19:14:13 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 QQnsnk29216 for ; Mon, 9 Dec 2002 19:13:10 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 QQnsnk04294 for ; Mon, 9 Dec 2002 19:13:10 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 QQnsnk04286 for ; Mon, 9 Dec 2002 19:13:09 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9JDbRu017726 for ; Mon, 9 Dec 2002 14:13:37 -0500 (EST) 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 OAA15639 for ; Mon, 9 Dec 2002 14:13:07 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9JD7W07016 for mpls@uu.net; Mon, 9 Dec 2002 14:13:07 -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 QQnsnk07832 for ; Mon, 9 Dec 2002 19:11:11 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 QQnsnk19237 for ; Mon, 9 Dec 2002 19: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 QQnsnk02389 for ; Mon, 9 Dec 2002 19:10:06 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 QQnsnk02376 for ; Mon, 9 Dec 2002 19:10: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 OAA36521; Mon, 9 Dec 2002 14:05:08 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212091905.OAA36521@workhorse.fictitious.org> To: "Gray, Eric" cc: "'curtis@fictitious.org'" , erosen@cisco.com, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Mon, 09 Dec 2002 13:42:29 EST." <1117F7D44159934FB116E36F4ABF221B0267ED5A@celox-ma1-ems1.celoxnetworks.com> Date: Mon, 09 Dec 2002 14:05:08 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <1117F7D44159934FB116E36F4ABF221B0267ED5A@celox-ma1-ems1.celoxnetwor ks.com>, "Gray, Eric" writes: > I also would think this better if it specifically said > use 127.0.0.1 as opposed to what it currently says. What's the solution for ECMP then? Note that even below, if a second branch point is hit, then you need a set of addresses that falls into the first hash but are spread out among the second hash. Like I said a few messages back, I don't know that enough thought has been put into ECMP. Curtis > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > Sent: Monday, December 09, 2002 1:33 PM > > To: erosen@cisco.com > > Cc: Gray, Eric; 'curtis@fictitious.org'; mpls@UU.NET > > Subject: Re: Last call on LSP Ping > > > > > > In message <200212091636.gB9GavFp025626@sj-msg-core-1.cisco.com>, Eric > > Rosen wr > > ites: > > > > > > EricG> If there is another reason for using this address range, it > > either > > > EricG> has not been stated, or I missed it. > > > > > > Well, what should the tunnel ingress put into the IP destination > > field of > > > the "LSP Ping" UDP packet? We want the packet to be consumed by the > > egress > > > even if the egress isn't who the ingress thinks it is. (That's how we > > get > > > the error response indicating that the tunneled packets have > > been > > > misrouted.) Thus we need to put in a "well known" address which > > will be > > > interpreted by the tunnel egress as meaning "for me". > > > > > > Use of one of the loopback addresses (127.x.y.z) seems to achieve this > > goal. > > > I think it's kind of a nifty hack ;-) > > > > > > As Curtis has pointed out, there is ample precedent for having a > > tunneled > > > packet carry addressing information which is to be interpreted in > > the > > > context of the egress. > > > > > > > > Eric, > > > > I think the use of 127.0.0.1 is a good idea, however, I don't think > > the use of 127.x.y.z to test ECMP is a good idea. I am not objecting > > to use of 127/8, just the way ECMP is proposed to be handled. > > > > In the simple case, the ingress puts on one label or a small label > > stack. That ingress may take traffic and spread it over more than one > > LSP, but then the label stack is different. Even though ECMP is used, > > the ingress has more than one LSP to test. > > > > If you step TTL in increments of one, at each MPLS LSP hop TTL will > > expire if TTL is being decremented. That LSR can then provide its > > mapping and LSP-ping need the ability for that midpoint LSR to provide > > more than one mapping if ECMP is used. > > > > The ingress then needs to know how many mappings there are and how to > > get packets into each of the available mappings. There are two types > > of possible mappings at a point that does ECMP, label stack based, and > > IP header based. > > > > For label stack based mappings, there will only be one mapping for a > > given label stack (although for a given LSP there may be multiple > > paths used for different lower labels). The point is that for a label > > stack based ECMP, only one label mapping is returned, the one for the > > exact label stack used. If you want to know all mappings, don't > > include a lower label. > > > > For a TE tunnel, there is no branching at midpoints for an LSP. > > Therefore there is only one mapping. The hashing and ECMP occurs > > only at the ingress. > > > > The remaining case is an LDP tunnel that uses IP header based ECMP at > > midpoint. To do this an LSR has to be snooping the traffic for IP > > headers and consistently seeing them. Please lets not go into a > > tangient over whether this is a good idea, simply accept that it > > happens and MPLS-ping has to deal with it. In this case, TTL expires > > and the midpoint has to return more than one mapping. If the spliting > > algorithm is proprietary or uses a seeded hash, then the simplest way > > to indicate how to get into any one path is for the midpoint to > > provide a address within some range, that the ingress can use to get > > there. Even this is problematic since some implementations > > periodically reseed the hash with a random number. To be general, the > > ingress would need to provide an acceptable range (such as 127/24 or > > 127/8) and the midpoint would need to provide an address and a time > > duration for which that address will work (indication of when the seed > > will be changed). > > > > The only case where a traffic split occurs in a TE midpoint is > > proprietary link bundlings which use either label stack or IP header > > methods of splitting. In this case, the bundling is better exposed > > for diagnostic capability and the same issues as above hold. > > > > A very minor points I don't know about you but I can ping 127.0.0.1 > > but not 127.0.0.2 on my BSD boxes (no big deal, just a change). > > > > So I'm still in favor of using 127/8 but think that ECMP could be done > > better. > > > > Curtis > From owner-mpls@UU.NET Mon Dec 9 14:20: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 OAA26388 for ; Mon, 9 Dec 2002 14:20:33 -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 QQnsnl08470 for ; Mon, 9 Dec 2002 19:23: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 QQnsnl04989; Mon, 9 Dec 2002 19:21:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsnl09172 for mpls-outgoing; Mon, 9 Dec 2002 19:21:06 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 QQnsnl09157 for ; Mon, 9 Dec 2002 19:20:57 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 QQnsnl06037 for ; Mon, 9 Dec 2002 19:20: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 QQnsnl10260 for ; Mon, 9 Dec 2002 19:20:38 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 QQnsnl10255 for ; Mon, 9 Dec 2002 19:20:37 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9JL6ox019788 for ; Mon, 9 Dec 2002 14:21:06 -0500 (EST) 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 OAA16302 for ; Mon, 9 Dec 2002 14:20:36 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9JKag08558 for mpls@uu.net; Mon, 9 Dec 2002 14:20:36 -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 QQnsnl08931 for ; Mon, 9 Dec 2002 19:18:29 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 QQnsnl23663 for ; Mon, 9 Dec 2002 19:16:56 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 QQnsnl07107 for ; Mon, 9 Dec 2002 19:16:55 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 QQnsnl07093 for ; Mon, 9 Dec 2002 19:16:54 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 OAA36556; Mon, 9 Dec 2002 14:13:07 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212091913.OAA36556@workhorse.fictitious.org> To: "Gray, Eric" cc: "'curtis@fictitious.org'" , "'erosen@cisco.com'" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Mon, 09 Dec 2002 13:54:17 EST." <1117F7D44159934FB116E36F4ABF221B0267ED5B@celox-ma1-ems1.celoxnetworks.com> Date: Mon, 09 Dec 2002 14:13:07 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <1117F7D44159934FB116E36F4ABF221B0267ED5B@celox-ma1-ems1.celoxnetwor ks.com>, "Gray, Eric" writes: > Curtis, > > I am suggesting that attempting to use any address range > as a mechanism for testing ECMP routes is a mistake. I am also > suggesting that a single address is sufficient to satisfy the > need Eric Rosen points out. Finally, if you were suggesting > that 127.0.0.1 should be specified (as opposed to 127.0.0.0/8) > for the same purpose, then I agree with you. > > Any address based approach to trying to test ECMP load > sharing paths implies prior knowledge of all ECMP algorithms > in use and is therefore broken. > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 If you have ideas to address the prior message I sent on ECMP and in particular the problem of multiple branch points, I'd like to hear your solution. One thing that came to mind was the midpoint enumerating the possible paths with indices and the ingress providing the index in subsequent messages. To do this, the ingress may have to bundle the better part of an MPLS-ping message inside another so the top POP exposes an IP packet and ECMP index to use and the packet inside is injected into the stream. If we go with this, then 127.0.0.1 would be fine. This has the disadvantage of not actually exercising the forwarding, just the control plane. The 127.0.0.1 address has a small advantage in that if the egress comes out in some unexpected place, then it is delivered to that router which can respond more intellegently than sending an ICMP TTL expired. Curtis From owner-mpls@UU.NET Mon Dec 9 14:36: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 OAA27285 for ; Mon, 9 Dec 2002 14:36: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 QQnsnm07974 for ; Mon, 9 Dec 2002 19:39:20 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 QQnsnm27434; Mon, 9 Dec 2002 19:33:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsnm10352 for mpls-outgoing; Mon, 9 Dec 2002 19:33:04 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 QQnsnm10338 for ; Mon, 9 Dec 2002 19:32:50 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 QQnsnm00943 for ; Mon, 9 Dec 2002 19:32: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 QQnsnm18901 for ; Mon, 9 Dec 2002 19:32:09 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 QQnsnm18893 for ; Mon, 9 Dec 2002 19:32:08 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9JWbXe022480 for ; Mon, 9 Dec 2002 14:32:37 -0500 (EST) 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 OAA17454 for ; Mon, 9 Dec 2002 14:32:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9JW6D13432 for mpls@uu.net; Mon, 9 Dec 2002 14:32:06 -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 QQnsnm10199 for ; Mon, 9 Dec 2002 19:30:46 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 QQnsnl04190 for ; Mon, 9 Dec 2002 19:29: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 QQnsnl17039 for ; Mon, 9 Dec 2002 19:29:26 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 QQnsnl17025 for ; Mon, 9 Dec 2002 19:29:25 GMT Received: (qmail 14459 invoked by uid 104); 9 Dec 2002 19:29:24 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4236. . Clean. Processed in 1.028774 secs); 09 Dec 2002 19:29:24 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 9 Dec 2002 19:29:23 -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 gB9JTMQ20750; Mon, 9 Dec 2002 11:29:23 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Mon, 9 Dec 2002 11:29:22 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B67@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'curtis@fictitious.org'" Cc: David Allan , neil.2.harrison@bt.com, swallow@cisco.com, mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Mon, 9 Dec 2002 11:29:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > > First of all I did propose using the egress IP address and > setting the > > TTL=1 in the IP header. This makes sure that the LSP-ping > packet will > > not get forwarded after the MPLS labels are poped. > > Glad to see this change to a technical discussion. Took a while. > > This proposal has two flaws, 1) when the label gets POPed and the > egress isn't the router you thought it should be the response is an > ICMP TTL expired, 2) no way to handle ECMP is proposed. > > Please indicate how you would handle ECMP. 1)Yes the ICMP TTL expire will be generated and the packet will be delivered to control plane. The control-plane will check and see the packet being OAM packet and will respond accordingly. So the ingress may see an additional TTL expire, which is not harmful at all. 2)MY proposal handles the ECMP, if the ECMP algorithm is only based on MPLS stack. In case the ECMP algorithm is also based on IP Dest Address, then you are correct, my proposal will not be able to exercise the ECMP paths. But: The current proposal may not be able to exercise the ECMP paths either, because the hashing algorithm may not necessarily be based on the first 7 bits of the IP address. And also you need to scan through 16 million addresses in order to make sure you exercise all the ECMP paths. > > > Secondly, it is > > not my draft, those who have written it should find > alternate methods. > > They have proposed something that will work. You have now made a > counterproposal. You need to justify on technical grounds why not to > use their proposal, why yours will work, and why yours is better. Here is the justification: My proposal works fine at the intended or unintended egress. My proposal does not support ECMP, but the current proposal, does not support ECMP in all implementations either. My proposal, does not require any configuration of the IP filters in all LSRs, which is required by current proposal. My proposal does not force us to justify the SHOULD NOT part of standard RFCs. -Shahram > > > Ok., let me make it clear: I want LSP-ping to be improved. > > Great. So drop the RFC1700 nonsense and lets move on. > > Curtis > From owner-mpls@UU.NET Mon Dec 9 14:49:12 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 OAA27916 for ; Mon, 9 Dec 2002 14:49: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 QQnsnn25582 for ; Mon, 9 Dec 2002 19:51:40 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 QQnsnn16955; Mon, 9 Dec 2002 19:46:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsnn12176 for mpls-outgoing; Mon, 9 Dec 2002 19:46:27 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 QQnsnn12167 for ; Mon, 9 Dec 2002 19:46:24 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 QQnsnn19529 for ; Mon, 9 Dec 2002 19:46:16 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 QQnsnn00851 for ; Mon, 9 Dec 2002 19:46:16 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 QQnsnn00835 for ; Mon, 9 Dec 2002 19:46:15 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9JkioB026294 for ; Mon, 9 Dec 2002 14:46:44 -0500 (EST) 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 OAA18657 for ; Mon, 9 Dec 2002 14:46:14 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9JkDh17539 for mpls@uu.net; Mon, 9 Dec 2002 14:46:13 -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 QQnsnm11633 for ; Mon, 9 Dec 2002 19:44:56 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 QQnsnm25021 for ; Mon, 9 Dec 2002 19:44: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 QQnsnm29661 for ; Mon, 9 Dec 2002 19:44:46 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 QQnsnm29644 for ; Mon, 9 Dec 2002 19:44:45 GMT Received: (qmail 25827 invoked by uid 104); 9 Dec 2002 19:44:45 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4236. . Clean. Processed in 0.468552 secs); 09 Dec 2002 19:44:45 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 9 Dec 2002 19:44:44 -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 gB9JiYQ00088; Mon, 9 Dec 2002 11:44:34 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Mon, 9 Dec 2002 11:44:33 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B69@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'curtis@fictitious.org'" , "Gray, Eric" Cc: "'erosen@cisco.com'" , mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Mon, 9 Dec 2002 11:44:32 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Curtis, Apart from this draft what is the current behavior of a router that receives any of the 127/8 addresses from an external interface? discard, send to control-plane, or loopback? -Shahram From owner-mpls@UU.NET Mon Dec 9 15:23: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 PAA29476 for ; Mon, 9 Dec 2002 15:23:21 -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 QQnsnp04154 for ; Mon, 9 Dec 2002 20:25: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 QQnsnp00086; Mon, 9 Dec 2002 20:23:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsnp04276 for mpls-outgoing; Mon, 9 Dec 2002 20:23:03 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 QQnsnp04269 for ; Mon, 9 Dec 2002 20:22:48 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 QQnsnp24841 for ; Mon, 9 Dec 2002 20:22:09 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 QQnsnp03195 for ; Mon, 9 Dec 2002 20:22:09 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 QQnsnp03179 for ; Mon, 9 Dec 2002 20:22:09 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9KMb0c005661 for ; Mon, 9 Dec 2002 15:22:38 -0500 (EST) 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 PAA22000 for ; Mon, 9 Dec 2002 15:22:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9KM5m25745 for mpls@uu.net; Mon, 9 Dec 2002 15:22: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 QQnsnp04145 for ; Mon, 9 Dec 2002 20:20:45 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 QQnsnp28969 for ; Mon, 9 Dec 2002 20:16: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 QQnsnp25844 for ; Mon, 9 Dec 2002 20:16:40 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 QQnsnp25830 for ; Mon, 9 Dec 2002 20:16:39 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 PAA37058; Mon, 9 Dec 2002 15:14:36 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212092014.PAA37058@workhorse.fictitious.org> To: Shahram Davari cc: "'curtis@fictitious.org'" , David Allan , neil.2.harrison@bt.com, swallow@cisco.com, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Mon, 09 Dec 2002 11:29:21 PST." <4B6D09F3B826D411A67300D0B706EFDEB03B67@nt-exch-yow.pmc-sierra.bc.ca> Date: Mon, 09 Dec 2002 15:14:36 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4B6D09F3B826D411A67300D0B706EFDEB03B67@nt-exch-yow.pmc-sierra.bc.ca >, Shahram Davari writes: > > > First of all I did propose using the egress IP address and > > setting the > > > TTL=1 in the IP header. This makes sure that the LSP-ping > > packet will > > > not get forwarded after the MPLS labels are poped. > > > > Glad to see this change to a technical discussion. Took a while. > > > > This proposal has two flaws, 1) when the label gets POPed and the > > egress isn't the router you thought it should be the response is an > > ICMP TTL expired, 2) no way to handle ECMP is proposed. > > > > Please indicate how you would handle ECMP. > > > 1)Yes the ICMP TTL expire will be generated and the packet will be delivered > to control plane. The control-plane will check and see the packet being OAM p > acket > and will respond accordingly. So the ingress may see an additional TTL expire > , > which is not harmful at all. Normal delivery of a packet with TTL=1 is to do TTL processing and then drop the packet. The payload of the packet is not examined to see if it is a service that is recognized for which additional diagnostics could be sent. Therefore, only a ICMP TTL expired is sent. Plus if the control plane is not IP, a case that some people insisted had to be supported, then that ICMP packet goes nowhere. > 2)MY proposal handles the ECMP, if the ECMP algorithm is only based on MPLS > stack. In case the ECMP algorithm is also based on IP Dest Address, > then you are correct, my proposal will not be able to exercise the > ECMP paths. But: I was talking about reality where both MPLS based and IP header based load spliting occurs. You have to handle both. > The current proposal may not be able to exercise the ECMP paths either, > because the hashing algorithm may not necessarily be based on the first 7 bit > s of the IP address. And also you need to scan through 16 million addresses i > n order > to make sure you exercise all the ECMP paths. Hash exercises all bits. Limiting the addressing to one host address makes matters worse. Randomly trying addresses is not a good way to check for multiple paths. I sent three message on deficiencies in ECMP handling. One enumerated some cases. A second noted the multiple branch points problem. A third suggested a way around it but noted that this didn't exercise the forwarding plane, only the control plane. > > > Secondly, it is > > > not my draft, those who have written it should find > > alternate methods. > > > > They have proposed something that will work. You have now made a > > counterproposal. You need to justify on technical grounds why not to > > use their proposal, why yours will work, and why yours is better. > > Here is the justification: > > My proposal works fine at the intended or unintended egress. No it doesn't see above. > My proposal does not support ECMP, but the current proposal, does not > support ECMP in all implementations either. If it turns out that we need an address range to exercise IP src/dst based hash, then your proposal is unacceptable. > My proposal, does not require any configuration of the IP filters in all > LSRs, which is required by current proposal. Justifying this on the basis that a configuration entry on *some* routers might have to be changed is a very weak justification. > My proposal does not force us to justify the SHOULD NOT part of standard RFCs RFC1812 explicitly states that 127/8 can't be forwarded except to the loopback device. Therefore the exception is already in place in a standard RFC. So give up on this already. > -Shahram Lets see if there is support for your proposal. Curtis From owner-mpls@UU.NET Mon Dec 9 15:33: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 PAA29885 for ; Mon, 9 Dec 2002 15:33:12 -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 QQnsnq15198 for ; Mon, 9 Dec 2002 20:36:04 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 QQnsnq12977; Mon, 9 Dec 2002 20:35:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsnq05478 for mpls-outgoing; Mon, 9 Dec 2002 20:34: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 QQnsnq05472 for ; Mon, 9 Dec 2002 20:34:31 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 QQnsnq28392 for ; Mon, 9 Dec 2002 20:34: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 QQnsnq09681 for ; Mon, 9 Dec 2002 20:34:23 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 QQnsnq09669 for ; Mon, 9 Dec 2002 20:34:23 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Dec 2002 15:34:22 -0500 Message-ID: <1117F7D44159934FB116E36F4ABF221B0267ED5F@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'curtis@fictitious.org'" , "Gray, Eric" Cc: "'erosen@cisco.com'" , mpls@UU.NET Subject: RE: Last call on LSP Ping - ECMP thread (continued) Date: Mon, 9 Dec 2002 15:34:12 -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, For the specific case where the destination IP address is chosen at random from a large space and is actually independent of the route followed by any path, a destination IP address based hash algorithm results in a fairly random distribution across all paths. As you probably know, this is not the case for destination IP addresses in general - i.e. - the DIPA is not at all independent of the routes followed by all equal cost paths. Consequently, even assuming the implementation does the deep dive and looks at the IP header for its ECMP hashing algorithm, it will most likely not rely on the DIPA exclusively for deriving the ECMP hash. If it did, there is likely to be insufficient entropy in the derived hash values - resulting in an undesirable distribution among the equal cost paths. This proposal will indirectly have the effect of requiring that any ECMP hash algorithm used in those implementations that use the IP header must include a part of the least significant bytes of the destination IP address in the key. This in spite of the fact that this is not actually helpful to the hash algorithm in general. Moreover, this may be interpreted by users as justification for pressuring implementers to use the IP header in their ECMP hash algorithm even though this is clearly not going to scale in some LSR implementations. My point is that the usefulness of this address range depends on an assumption that ECMP hash algorithms will include some part of the least significant bytes of the destination IP address. This is a grave restriction on the use of ECMP algorithms and should not be encouraged. If you cannot make this assumption, then the existence of this address range would not be useful and would in fact be misleading. If you cannot make this assumption, and the use of this address range is not useful, then I fail to see why it is necessary to propose something equally useless to replace this suggestion. :-) However, if you proposed a more straight-forward approach - requiring an ECMP origination point to (some day) support the ability to recognize a Ping packet and (presumably on it's own initiative) produce its own Ping packets for all equal cost paths - that approach does seem useful and we should think about it some more. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: Monday, December 09, 2002 2:13 PM > To: Gray, Eric > Cc: 'curtis@fictitious.org'; 'erosen@cisco.com'; mpls@UU.NET > Subject: Re: Last call on LSP Ping > > > In message <1117F7D44159934FB116E36F4ABF221B0267ED5B@celox-ma1- > ems1.celoxnetwor > ks.com>, "Gray, Eric" writes: > > Curtis, > > > > I am suggesting that attempting to use any address range > > as a mechanism for testing ECMP routes is a mistake. I am also > > suggesting that a single address is sufficient to satisfy the > > need Eric Rosen points out. Finally, if you were suggesting > > that 127.0.0.1 should be specified (as opposed to 127.0.0.0/8) > > for the same purpose, then I agree with you. > > > > Any address based approach to trying to test ECMP load > > sharing paths implies prior knowledge of all ECMP algorithms > > in use and is therefore broken. > > > > Eric W. Gray > > Systems Architect > > Celox Networks, Inc. > > egray@celoxnetworks.com > > 508 305 7214 > > > If you have ideas to address the prior message I sent on ECMP and in > particular the problem of multiple branch points, I'd like to hear > your solution. > > One thing that came to mind was the midpoint enumerating the possible > paths with indices and the ingress providing the index in subsequent > messages. To do this, the ingress may have to bundle the better part > of an MPLS-ping message inside another so the top POP exposes an IP > packet and ECMP index to use and the packet inside is injected into > the stream. If we go with this, then 127.0.0.1 would be fine. This > has the disadvantage of not actually exercising the forwarding, just > the control plane. > > The 127.0.0.1 address has a small advantage in that if the egress > comes out in some unexpected place, then it is delivered to that > router which can respond more intellegently than sending an ICMP TTL > expired. > > Curtis From owner-mpls@UU.NET Mon Dec 9 16:24:26 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 QAA02825 for ; Mon, 9 Dec 2002 16:24:26 -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 QQnsnt29781 for ; Mon, 9 Dec 2002 21:26:58 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 QQnsnt24025; Mon, 9 Dec 2002 21:23:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsnt28512 for mpls-outgoing; Mon, 9 Dec 2002 21:23:32 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 QQnsnt28498 for ; Mon, 9 Dec 2002 21:23: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 QQnsnt04209 for ; Mon, 9 Dec 2002 21:23: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 QQnsnt22436 for ; Mon, 9 Dec 2002 21:23:08 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 QQnsnt22426 for ; Mon, 9 Dec 2002 21:23:08 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9LNafR016382 for ; Mon, 9 Dec 2002 16:23:37 -0500 (EST) 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 QAA27474 for ; Mon, 9 Dec 2002 16:23:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9LN6e03786 for mpls@uu.net; Mon, 9 Dec 2002 16:23:06 -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 QQnsnt28346 for ; Mon, 9 Dec 2002 21:22:03 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 QQnsnt03965 for ; Mon, 9 Dec 2002 21:21: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 QQnsnt18686 for ; Mon, 9 Dec 2002 21:21:52 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 QQnsnt18654 for ; Mon, 9 Dec 2002 21:21:51 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 QAA37676; Mon, 9 Dec 2002 16:19:53 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212092119.QAA37676@workhorse.fictitious.org> To: Shahram Davari cc: "'curtis@fictitious.org'" , "Gray, Eric" , "'erosen@cisco.com'" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Mon, 09 Dec 2002 11:44:32 PST." <4B6D09F3B826D411A67300D0B706EFDEB03B69@nt-exch-yow.pmc-sierra.bc.ca> Date: Mon, 09 Dec 2002 16:19:53 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4B6D09F3B826D411A67300D0B706EFDEB03B69@nt-exch-yow.pmc-sierra.bc.ca >, Shahram Davari writes: > Curtis, > > Apart from this draft what is the current behavior of a router that > receives any of the 127/8 addresses from an external interface? discard, send > to control-plane, or loopback? > > -Shahram It is hard to say empirically with my copy of ping since ping -I only takes multicast addresses. -I interface Source multicast packets with the given interface address. This flag only applies if the ping destination is a multicast address. I suppose I could use the source and change this to run the test. I think what you'll find is: 1. If it arrives in a tunnel, such as GRE, or L2TP, or PPP over SSH or whatever, the router responds, even if there is a filter on 127/8. 2. If it arrives with source router, the router responds, unless a filter has been configured on 127/8. 3. If it arrived on an interface, such as when PHP is used without explicit NULL label, the router responds, unless a filter has been configured on 127/8. Without PHP, MPLS-ping would be like case 1. With PHP and without a explicit null label MPLS-ping would be like case 3. Editing the router config to remove the filter is a trivial matter. Someone who has actually written the client side of mpls-ping can respond with their experiences. Traceroute -g on one host with source routing disabled returns an ICMP message indicating source routing failed (!S in traceroute), on another it blackholed it. With source routing enabled, traceroute -g with destination 127.0.0.1 replied on both of them. I have to go through a few hosts acting as routers (which don't allow source routing) to get to real Cisco, Juniper and Avici routers so its easier for me to try this on a few local hosts. If you insist I'll number a loopback to 127.0.0.1 and try it on the loopback of a router. Maybe you don't understand what the loopback interface is. It *is* the control plane of the router. Go on a BSD machine and type "man lo". This is what is meant by delivery to a loopback in RFC1812. Cisco documentation has a similar definition. Curtis ps - maybe some readers don't have a BSD machine: LO(4) FreeBSD Kernel Interfaces Manual LO(4) NAME lo - software loopback network interface SYNOPSIS pseudo-device loop DESCRIPTION The loop interface is a software loopback mechanism which may be used for performance analysis, software testing, and/or local communication. As with other network interfaces, the loopback interface must have network addresses assigned for each address family with which it is to be used. These addresses may be set or changed with the SIOCSIFADDR ioctl(2). The loopback interface should be the last interface configured, as protocols may use the order of configuration as an indication of priority. The loopback should never be configured first unless no hardware interfaces exist. DIAGNOSTICS lo%d: can't handle af%d. The interface was handed a message with ad- dresses formatted in an unsuitable address family; the packet was dropped. SEE ALSO inet(4), intro(4) HISTORY The lo device appeared in 4.2BSD. BUGS Previous versions of the system enabled the loopback interface automati- cally, using a nonstandard Internet address (127.1). Use of that address is now discouraged; a reserved host address for the local network should be used instead. 4.2 Berkeley Distribution June 5, 1993 1 From owner-mpls@UU.NET Mon Dec 9 16:49:45 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 QAA04122 for ; Mon, 9 Dec 2002 16:49:44 -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 QQnsnv14178 for ; Mon, 9 Dec 2002 21:52: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 QQnsnv11651; Mon, 9 Dec 2002 21:51:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsnv00895 for mpls-outgoing; Mon, 9 Dec 2002 21:50: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 QQnsnv00886 for ; Mon, 9 Dec 2002 21:50:24 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 QQnsnv20030 for ; Mon, 9 Dec 2002 21:49:07 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 QQnsnv10310 for ; Mon, 9 Dec 2002 21:49:06 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 QQnsnv10302 for ; Mon, 9 Dec 2002 21:49:06 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9LnZJw020315 for ; Mon, 9 Dec 2002 16:49:35 -0500 (EST) 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 QAA29768 for ; Mon, 9 Dec 2002 16:49:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9Ln5P07304 for mpls@uu.net; Mon, 9 Dec 2002 16:49:05 -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 QQnsnv00777 for ; Mon, 9 Dec 2002 21:47:48 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 QQnsnv02171 for ; Mon, 9 Dec 2002 21:47: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 QQnsnv18943 for ; Mon, 9 Dec 2002 21:47:03 GMT Received: from father.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQnsnv18919 for ; Mon, 9 Dec 2002 21:47:02 GMT Received: (qmail 22968 invoked by uid 104); 9 Dec 2002 21:47:02 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4236. . Clean. Processed in 0.5206 secs); 09 Dec 2002 21:47:02 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 9 Dec 2002 21:47:01 -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 gB9LkpQ17912; Mon, 9 Dec 2002 13:46:56 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Mon, 9 Dec 2002 13:46:50 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B6C@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'curtis@fictitious.org'" Cc: David Allan , neil.2.harrison@bt.com, swallow@cisco.com, mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Mon, 9 Dec 2002 13:46:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Curtis, > > 1)Yes the ICMP TTL expire will be generated and the packet > will be delivered > > to control plane. The control-plane will check and see the > packet being OAM p > > acket > > and will respond accordingly. So the ingress may see an > additional TTL expire > > , > > which is not harmful at all. > > Normal delivery of a packet with TTL=1 is to do TTL processing and > then drop the packet. The payload of the packet is not examined to > see if it is a service that is recognized for which additional > diagnostics could be sent. Therefore, only a ICMP TTL expired is > sent. This is what RFC1812 says: A router MUST NOT discard a datagram just because it was received with TTL equal to zero or one; if it is to the router and otherwise valid, the router MUST attempt to receive it. I agree that if LSP-pings ends up in a router that it was not intended it will get discarded. However, I am wondering what is the required behavior in LSP-ping draft? Is it to get a reply even from an egress LSR that is not the correct egress? If so then how can that egress use the RSVP return path to respond? I think not receiving a reply from a wrong egress should be fine, because it gives you an LSP-ping failure. And then you could run trace-route, to figure out the exact path. >Plus if the control plane is not IP, a case that some people > insisted had to be supported, then that ICMP packet goes nowhere. I didn't know that LSP-ping works without IP in the control plane. Besides I am not using ICMP to detect ping failure, just not receiving ping reply, would indicate the LSP failure. > > > 2)MY proposal handles the ECMP, if the ECMP algorithm is > only based on MPLS > > stack. In case the ECMP algorithm is also based on IP Dest Address, > > then you are correct, my proposal will not be able to exercise the > > ECMP paths. But: > > I was talking about reality where both MPLS based and IP header based > load spliting occurs. You have to handle both. > > > The current proposal may not be able to exercise the ECMP > paths either, > > because the hashing algorithm may not necessarily be based > on the first 7 bit > > s of the IP address. And also you need to scan through 16 > million addresses i > > n order > > to make sure you exercise all the ECMP paths. > > Hash exercises all bits. Limiting the addressing to one host address > makes matters worse. Randomly trying addresses is not a good way to > check for multiple paths. But isn't this what the draft currently proposes: "the destination IP address is a (randomly chosen) address from 127/8" ? -Shahram > > I sent three message on deficiencies in ECMP handling. One enumerated > some cases. A second noted the multiple branch points problem. A > third suggested a way around it but noted that this didn't exercise > the forwarding plane, only the control plane. > > > > > Secondly, it is > > > > not my draft, those who have written it should find > > > alternate methods. > > > > > > They have proposed something that will work. You have now made a > > > counterproposal. You need to justify on technical > grounds why not to > > > use their proposal, why yours will work, and why yours is better. > > > > Here is the justification: > > > > My proposal works fine at the intended or unintended egress. > > No it doesn't see above. > > > My proposal does not support ECMP, but the current > proposal, does not > > support ECMP in all implementations either. > > If it turns out that we need an address range to exercise IP src/dst > based hash, then your proposal is unacceptable. > > > My proposal, does not require any configuration of the IP > filters in all > > LSRs, which is required by current proposal. > > Justifying this on the basis that a configuration entry on *some* > routers might have to be changed is a very weak justification. > > > My proposal does not force us to justify the SHOULD NOT > part of standard RFCs > > RFC1812 explicitly states that 127/8 can't be forwarded except to the > loopback device. Therefore the exception is already in place in a > standard RFC. So give up on this already. > > > -Shahram > > Lets see if there is support for your proposal. > > Curtis > From owner-mpls@UU.NET Mon Dec 9 16:57:10 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 QAA04532 for ; Mon, 9 Dec 2002 16:57:10 -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 QQnsnv25757 for ; Mon, 9 Dec 2002 21:59:57 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 QQnsnv21948; Mon, 9 Dec 2002 21:57:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsnv01793 for mpls-outgoing; Mon, 9 Dec 2002 21:57: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 QQnsnv01772 for ; Mon, 9 Dec 2002 21:57: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 QQnsnv10909 for ; Mon, 9 Dec 2002 21:56:00 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 QQnsnv19816 for ; Mon, 9 Dec 2002 21:55:58 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 QQnsnv19427 for ; Mon, 9 Dec 2002 21:55:45 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9LuCr5021261 for ; Mon, 9 Dec 2002 16:56:12 -0500 (EST) 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 QAA00335 for ; Mon, 9 Dec 2002 16:55:42 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9Ltgv08421 for mpls@uu.net; Mon, 9 Dec 2002 16:55:42 -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 QQnsnv01323 for ; Mon, 9 Dec 2002 21:54:17 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 QQnsnv29329 for ; Mon, 9 Dec 2002 21:52:15 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 QQnsnv09258 for ; Mon, 9 Dec 2002 21:52:15 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 QQnsnv09240 for ; Mon, 9 Dec 2002 21:52:13 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 QAA37793; Mon, 9 Dec 2002 16:50:13 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212092150.QAA37793@workhorse.fictitious.org> To: "Gray, Eric" cc: "'curtis@fictitious.org'" , "'erosen@cisco.com'" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping - ECMP thread (continued) In-reply-to: Your message of "Mon, 09 Dec 2002 15:34:12 EST." <1117F7D44159934FB116E36F4ABF221B0267ED5F@celox-ma1-ems1.celoxnetworks.com> Date: Mon, 09 Dec 2002 16:50:13 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <1117F7D44159934FB116E36F4ABF221B0267ED5F@celox-ma1-ems1.celoxnetwor ks.com>, "Gray, Eric" writes: > Curtis, > > For the specific case where the destination IP > address is chosen at random from a large space and is > actually independent of the route followed by any path, > a destination IP address based hash algorithm results > in a fairly random distribution across all paths. As > you probably know, this is not the case for destination > IP addresses in general - i.e. - the DIPA is not at all > independent of the routes followed by all equal cost > paths. Consequently, even assuming the implementation > does the deep dive and looks at the IP header for its > ECMP hashing algorithm, it will most likely not rely > on the DIPA exclusively for deriving the ECMP hash. If > it did, there is likely to be insufficient entropy in > the derived hash values - resulting in an undesirable > distribution among the equal cost paths. Actually src/dst addresses are used and the hash is over those 64 bits. Some implementations use (or used) the port numbers as well. The idea was to split up the traffic but make sure no IP microflow was reordered. > This proposal will indirectly have the effect of > requiring that any ECMP hash algorithm used in those > implementations that use the IP header must include a > part of the least significant bytes of the destination > IP address in the key. This in spite of the fact that > this is not actually helpful to the hash algorithm in > general. Moreover, this may be interpreted by users as > justification for pressuring implementers to use the IP > header in their ECMP hash algorithm even though this is > clearly not going to scale in some LSR implementations. The normal HASH is over a 64 bit quantity. If the MPLS-ping has a fixed source address, and indicates that it can use 127/8, then if possible an address from 127/8 has to be returned for the source to use. I mentioned that two branch points presents a problem because after the first branch point a subset of addresses is available, of which onl one is known. > My point is that the usefulness of this address > range depends on an assumption that ECMP hash algorithms > will include some part of the least significant bytes of > the destination IP address. This is a grave restriction > on the use of ECMP algorithms and should not be encouraged. > If you cannot make this assumption, then the existence of > this address range would not be useful and would in fact > be misleading. This is a safe assumption, but if not, then rather than a 127/8 address, the midpoint must return some indication that no address in the range will allow the diagnostic. The indication could be 0.0.0.0. > If you cannot make this assumption, and the use of > this address range is not useful, then I fail to see why > it is necessary to propose something equally useless to > replace this suggestion. :-) If there is a router that does ECMP and uses an IP hash that doesn't include the lower 24 bits, I'd be really surprised. I don't think such a thing exists or that there is any good reason to build such a thing and therefore your objection has no merit. The problem of multiple ECMP branch points remains a problem which nothing proposed so far addressed adequately (unless you count spraying over the whole 127/8 range as addressing this). > However, if you proposed a more straight-forward > approach - requiring an ECMP origination point to (some > day) support the ability to recognize a Ping packet and > (presumably on it's own initiative) produce its own Ping > packets for all equal cost paths - that approach does > seem useful and we should think about it some more. I thought I just did propose something (not in the attached message but in a prior message) that unlike what you state above requires no change to forwarding. It requires only a change in MPLS TTL expired processing if the payload is MPLS-ping (which is already required). It is really spread over three messages. Do I need to resend it in one message? > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 Curtis > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > Sent: Monday, December 09, 2002 2:13 PM > > To: Gray, Eric > > Cc: 'curtis@fictitious.org'; 'erosen@cisco.com'; mpls@UU.NET > > Subject: Re: Last call on LSP Ping > > > > > > In message <1117F7D44159934FB116E36F4ABF221B0267ED5B@celox-ma1- > > ems1.celoxnetwor > > ks.com>, "Gray, Eric" writes: > > > Curtis, > > > > > > I am suggesting that attempting to use any address range > > > as a mechanism for testing ECMP routes is a mistake. I am also > > > suggesting that a single address is sufficient to satisfy the > > > need Eric Rosen points out. Finally, if you were suggesting > > > that 127.0.0.1 should be specified (as opposed to 127.0.0.0/8) > > > for the same purpose, then I agree with you. > > > > > > Any address based approach to trying to test ECMP load > > > sharing paths implies prior knowledge of all ECMP algorithms > > > in use and is therefore broken. > > > > > > Eric W. Gray > > > Systems Architect > > > Celox Networks, Inc. > > > egray@celoxnetworks.com > > > 508 305 7214 > > > > > > If you have ideas to address the prior message I sent on ECMP and in > > particular the problem of multiple branch points, I'd like to hear > > your solution. > > > > One thing that came to mind was the midpoint enumerating the possible > > paths with indices and the ingress providing the index in subsequent > > messages. To do this, the ingress may have to bundle the better part > > of an MPLS-ping message inside another so the top POP exposes an IP > > packet and ECMP index to use and the packet inside is injected into > > the stream. If we go with this, then 127.0.0.1 would be fine. This > > has the disadvantage of not actually exercising the forwarding, just > > the control plane. > > > > The 127.0.0.1 address has a small advantage in that if the egress > > comes out in some unexpected place, then it is delivered to that > > router which can respond more intellegently than sending an ICMP TTL > > expired. > > > > Curtis From owner-mpls@UU.NET Mon Dec 9 17:18: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 RAA05377 for ; Mon, 9 Dec 2002 17:18:34 -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 QQnsnx06024 for ; Mon, 9 Dec 2002 22:21:20 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 QQnsnx02963; Mon, 9 Dec 2002 22:19:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsnx22255 for mpls-outgoing; Mon, 9 Dec 2002 22:19: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 QQnsnx22241 for ; Mon, 9 Dec 2002 22:18: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 QQnsnx09193 for ; Mon, 9 Dec 2002 22:18:24 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 QQnsnx16235 for ; Mon, 9 Dec 2002 22:18:23 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 QQnsnx16225 for ; Mon, 9 Dec 2002 22:18:23 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9MIpAK024610 for ; Mon, 9 Dec 2002 17:18:52 -0500 (EST) 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 RAA02105 for ; Mon, 9 Dec 2002 17:18:21 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9MILu13637 for mpls@uu.net; Mon, 9 Dec 2002 17:18:21 -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 QQnsnx22134 for ; Mon, 9 Dec 2002 22:17: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 QQnsnx04889 for ; Mon, 9 Dec 2002 22:17: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 QQnsnx15294 for ; Mon, 9 Dec 2002 22:17:08 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 QQnsnx15247 for ; Mon, 9 Dec 2002 22:17:06 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 RAA37875; Mon, 9 Dec 2002 17:14:57 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212092214.RAA37875@workhorse.fictitious.org> To: Shahram Davari cc: "'curtis@fictitious.org'" , David Allan , neil.2.harrison@bt.com, swallow@cisco.com, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Mon, 09 Dec 2002 12:34:51 PST." <4B6D09F3B826D411A67300D0B706EFDEB03B6B@nt-exch-yow.pmc-sierra.bc.ca> Date: Mon, 09 Dec 2002 17:14:56 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4B6D09F3B826D411A67300D0B706EFDEB03B6B@nt-exch-yow.pmc-sierra.bc.ca >, Shahram Davari writes: > Curtis, > > Could you please enlighten us on how one can test all the ECMP paths without > needing to send 16 million LSP-pings? > > -Shahram Yes. Look at the message below (at the very bottom). I suggested that the midpoint be capable of returning more than one mapping, one mapping for each ECMP path and an address that can be used for each. In a later message I pointed out that this doesn't work well for multiple branch points. In a third message I suggested a way to handle multiple ECMP branch points but it does not fully exercise the forwarding plane, only the control plane. Curtis > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > Sent: Monday, December 09, 2002 3:15 PM > > To: Shahram Davari > > Cc: 'curtis@fictitious.org'; David Allan; neil.2.harrison@bt.com; > > swallow@cisco.com; mpls@UU.NET > > Subject: Re: Last call on LSP Ping > > > > > > > > In message > > <4B6D09F3B826D411A67300D0B706EFDEB03B67@nt-exch-yow.pmc-sierra.bc.ca > > >, Shahram Davari writes: > > > > > First of all I did propose using the egress IP address and > > > > setting the > > > > > TTL=1 in the IP header. This makes sure that the LSP-ping > > > > packet will > > > > > not get forwarded after the MPLS labels are poped. > > > > > > > > Glad to see this change to a technical discussion. Took a while. > > > > > > > > This proposal has two flaws, 1) when the label gets POPed and the > > > > egress isn't the router you thought it should be the > > response is an > > > > ICMP TTL expired, 2) no way to handle ECMP is proposed. > > > > > > > > Please indicate how you would handle ECMP. > > > > > > > > > 1)Yes the ICMP TTL expire will be generated and the packet > > will be delivered > > > to control plane. The control-plane will check and see the > > packet being OAM p > > > acket > > > and will respond accordingly. So the ingress may see an > > additional TTL expire > > > , > > > which is not harmful at all. > > > > Normal delivery of a packet with TTL=1 is to do TTL processing and > > then drop the packet. The payload of the packet is not examined to > > see if it is a service that is recognized for which additional > > diagnostics could be sent. Therefore, only a ICMP TTL expired is > > sent. Plus if the control plane is not IP, a case that some people > > insisted had to be supported, then that ICMP packet goes nowhere. > > > > > 2)MY proposal handles the ECMP, if the ECMP algorithm is > > only based on MPLS > > > stack. In case the ECMP algorithm is also based on IP Dest Address, > > > then you are correct, my proposal will not be able to exercise the > > > ECMP paths. But: > > > > I was talking about reality where both MPLS based and IP header based > > load spliting occurs. You have to handle both. > > > > > The current proposal may not be able to exercise the ECMP > > paths either, > > > because the hashing algorithm may not necessarily be based > > on the first 7 bit > > > s of the IP address. And also you need to scan through 16 > > million addresses i > > > n order > > > to make sure you exercise all the ECMP paths. > > > > Hash exercises all bits. Limiting the addressing to one host address > > makes matters worse. Randomly trying addresses is not a good way to > > check for multiple paths. > > > > I sent three message on deficiencies in ECMP handling. One enumerated > > some cases. A second noted the multiple branch points problem. A > > third suggested a way around it but noted that this didn't exercise > > the forwarding plane, only the control plane. > > > > > > > Secondly, it is > > > > > not my draft, those who have written it should find > > > > alternate methods. > > > > > > > > They have proposed something that will work. You have now made a > > > > counterproposal. You need to justify on technical > > grounds why not to > > > > use their proposal, why yours will work, and why yours is better. > > > > > > Here is the justification: > > > > > > My proposal works fine at the intended or unintended egress. > > > > No it doesn't see above. > > > > > My proposal does not support ECMP, but the current > > proposal, does not > > > support ECMP in all implementations either. > > > > If it turns out that we need an address range to exercise IP src/dst > > based hash, then your proposal is unacceptable. > > > > > My proposal, does not require any configuration of the IP > > filters in all > > > LSRs, which is required by current proposal. > > > > Justifying this on the basis that a configuration entry on *some* > > routers might have to be changed is a very weak justification. > > > > > My proposal does not force us to justify the SHOULD NOT > > part of standard RFCs > > > > RFC1812 explicitly states that 127/8 can't be forwarded except to the > > loopback device. Therefore the exception is already in place in a > > standard RFC. So give up on this already. > > > > > -Shahram > > > > Lets see if there is support for your proposal. > > > > Curtis Date: Mon, 09 Dec 2002 13:32:34 EST To: erosen@cisco.com cc: "Gray, Eric" , "'curtis@fictitious.org'" , mpls@UU.NET From: Curtis Villamizar Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Mon, 09 Dec 2002 11:36:56 EST." <200212091636.gB9GavFp025626@sj-msg-core-1.cisco.com> In message <200212091636.gB9GavFp025626@sj-msg-core-1.cisco.com>, Eric Rosen wr ites: > > EricG> If there is another reason for using this address range, it either > EricG> has not been stated, or I missed it. > > Well, what should the tunnel ingress put into the IP destination field of > the "LSP Ping" UDP packet? We want the packet to be consumed by the egress > even if the egress isn't who the ingress thinks it is. (That's how we get > the error response indicating that the tunneled packets have been > misrouted.) Thus we need to put in a "well known" address which will be > interpreted by the tunnel egress as meaning "for me". > > Use of one of the loopback addresses (127.x.y.z) seems to achieve this goal. > I think it's kind of a nifty hack ;-) > > As Curtis has pointed out, there is ample precedent for having a tunneled > packet carry addressing information which is to be interpreted in the > context of the egress. Eric, I think the use of 127.0.0.1 is a good idea, however, I don't think the use of 127.x.y.z to test ECMP is a good idea. I am not objecting to use of 127/8, just the way ECMP is proposed to be handled. In the simple case, the ingress puts on one label or a small label stack. That ingress may take traffic and spread it over more than one LSP, but then the label stack is different. Even though ECMP is used, the ingress has more than one LSP to test. If you step TTL in increments of one, at each MPLS LSP hop TTL will expire if TTL is being decremented. That LSR can then provide its mapping and LSP-ping need the ability for that midpoint LSR to provide more than one mapping if ECMP is used. The ingress then needs to know how many mappings there are and how to get packets into each of the available mappings. There are two types of possible mappings at a point that does ECMP, label stack based, and IP header based. For label stack based mappings, there will only be one mapping for a given label stack (although for a given LSP there may be multiple paths used for different lower labels). The point is that for a label stack based ECMP, only one label mapping is returned, the one for the exact label stack used. If you want to know all mappings, don't include a lower label. For a TE tunnel, there is no branching at midpoints for an LSP. Therefore there is only one mapping. The hashing and ECMP occurs only at the ingress. The remaining case is an LDP tunnel that uses IP header based ECMP at midpoint. To do this an LSR has to be snooping the traffic for IP headers and consistently seeing them. Please lets not go into a tangient over whether this is a good idea, simply accept that it happens and MPLS-ping has to deal with it. In this case, TTL expires and the midpoint has to return more than one mapping. If the spliting algorithm is proprietary or uses a seeded hash, then the simplest way to indicate how to get into any one path is for the midpoint to provide a address within some range, that the ingress can use to get there. Even this is problematic since some implementations periodically reseed the hash with a random number. To be general, the ingress would need to provide an acceptable range (such as 127/24 or 127/8) and the midpoint would need to provide an address and a time duration for which that address will work (indication of when the seed will be changed). The only case where a traffic split occurs in a TE midpoint is proprietary link bundlings which use either label stack or IP header methods of splitting. In this case, the bundling is better exposed for diagnostic capability and the same issues as above hold. A very minor points I don't know about you but I can ping 127.0.0.1 but not 127.0.0.2 on my BSD boxes (no big deal, just a change). So I'm still in favor of using 127/8 but think that ECMP could be done better. Curtis From owner-mpls@UU.NET Mon Dec 9 17:32:23 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 RAA05890 for ; Mon, 9 Dec 2002 17:32:23 -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 QQnsny22954 for ; Mon, 9 Dec 2002 22:35: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 QQnsny19832; Mon, 9 Dec 2002 22:33:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsny23652 for mpls-outgoing; Mon, 9 Dec 2002 22:33: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 QQnsny23640 for ; Mon, 9 Dec 2002 22:33:07 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 QQnsny25326 for ; Mon, 9 Dec 2002 22: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 QQnsny03657 for ; Mon, 9 Dec 2002 22:32:38 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 QQnsny03647 for ; Mon, 9 Dec 2002 22:32:38 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Dec 2002 17:32:38 -0500 Message-ID: <1117F7D44159934FB116E36F4ABF221B0267ED64@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'curtis@fictitious.org'" , "Gray, Eric" Cc: "'erosen@cisco.com'" , mpls@UU.NET Subject: RE: Last call on LSP Ping - ECMP thread (continued) Date: Mon, 9 Dec 2002 17:32:36 -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, > Actually src/dst addresses are used and the hash is over those 64 > bits. Some implementations use (or used) the port numbers as well. > The idea was to split up the traffic but make sure no IP microflow was > reordered. This is an unjustified assertion about implementations in general. You are not in a position to make assertions about how all implementations do this. > The normal HASH is over a 64 bit quantity. ... Again, this is an assertion though how anyone might determine what the "normal" hash algorithms might include is beyond me. > > My point is that the usefulness of this address > > range depends on an assumption that ECMP hash algorithms > > will include some part of the least significant bytes of > > the destination IP address. This is a grave restriction > > on the use of ECMP algorithms and should not be encouraged. > > If you cannot make this assumption, then the existence of > > this address range would not be useful and would in fact > > be misleading. > > This is a safe assumption, but if not, then rather than a 127/8 > address, the midpoint must return some indication that no address in > the range will allow the diagnostic. The indication could be 0.0.0.0. This might make sense. > If there is a router that does ECMP and uses an IP hash that doesn't > include the lower 24 bits, I'd be really surprised. I don't think > such a thing exists or that there is any good reason to build such a > thing and therefore your objection has no merit. Then you should be prepared to be surprised. In general, it is sufficient to group flows using either a source or a destination IP address based hash. Further, it is of some importance to use a range of algorithms, or (non-exclusive) a variation of key sources/patterns so that it is possible for the same source and destination to map to a different has key at different places in the network. Finally, it is very important to keep the hash algorithms simple. Consequently, it is possible that you may discover that some schemes use only a small-ish set of bits from either the source or destination IP address, depending on the location of the device, and the direction of packet flow, relative to the network core. Even if the entire 64 bits of source and destination IP address is injected into some algorithms, it is possible that steps in the algorithms themselves may ignore some of those bits. If you believe that my objection still has no merit, then we are unlikely to find common ground for further discussion - at least with respect to this issue. > The problem of multiple ECMP branch points remains a problem which > nothing proposed so far addressed adequately (unless you count > spraying over the whole 127/8 range as addressing this). Address spraying would not adequately address this either. > > > However, if you proposed a more straight-forward > > approach - requiring an ECMP origination point to (some > > day) support the ability to recognize a Ping packet and > > (presumably on it's own initiative) produce its own Ping > > packets for all equal cost paths - that approach does > > seem useful and we should think about it some more. > > I thought I just did propose something (not in the attached message > but in a prior message) that unlike what you state above requires no > change to forwarding. It requires only a change in MPLS TTL expired > processing if the payload is MPLS-ping (which is already required). > It is really spread over three messages. Do I need to resend it in > one message? Either that, or point out which three messages. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 > > > Eric W. Gray > > Systems Architect > > Celox Networks, Inc. > > egray@celoxnetworks.com > > 508 305 7214 > > Curtis > > > > > -----Original Message----- > > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > > Sent: Monday, December 09, 2002 2:13 PM > > > To: Gray, Eric > > > Cc: 'curtis@fictitious.org'; 'erosen@cisco.com'; mpls@UU.NET > > > Subject: Re: Last call on LSP Ping > > > > > > > > > In message <1117F7D44159934FB116E36F4ABF221B0267ED5B@celox-ma1- > > > ems1.celoxnetwor > > > ks.com>, "Gray, Eric" writes: > > > > Curtis, > > > > > > > > I am suggesting that attempting to use any address range > > > > as a mechanism for testing ECMP routes is a mistake. I am also > > > > suggesting that a single address is sufficient to satisfy the > > > > need Eric Rosen points out. Finally, if you were suggesting > > > > that 127.0.0.1 should be specified (as opposed to 127.0.0.0/8) > > > > for the same purpose, then I agree with you. > > > > > > > > Any address based approach to trying to test ECMP load > > > > sharing paths implies prior knowledge of all ECMP algorithms > > > > in use and is therefore broken. > > > > > > > > Eric W. Gray > > > > Systems Architect > > > > Celox Networks, Inc. > > > > egray@celoxnetworks.com > > > > 508 305 7214 > > > > > > > > > If you have ideas to address the prior message I sent on ECMP and in > > > particular the problem of multiple branch points, I'd like to hear > > > your solution. > > > > > > One thing that came to mind was the midpoint enumerating the possible > > > paths with indices and the ingress providing the index in subsequent > > > messages. To do this, the ingress may have to bundle the better part > > > of an MPLS-ping message inside another so the top POP exposes an IP > > > packet and ECMP index to use and the packet inside is injected into > > > the stream. If we go with this, then 127.0.0.1 would be fine. This > > > has the disadvantage of not actually exercising the forwarding, just > > > the control plane. > > > > > > The 127.0.0.1 address has a small advantage in that if the egress > > > comes out in some unexpected place, then it is delivered to that > > > router which can respond more intellegently than sending an ICMP TTL > > > expired. > > > > > > Curtis From owner-mpls@UU.NET Mon Dec 9 17:50:03 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 RAA06509 for ; Mon, 9 Dec 2002 17:50:02 -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 QQnsnz14605 for ; Mon, 9 Dec 2002 22:52: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 QQnsnz10840; Mon, 9 Dec 2002 22:50:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsnz25402 for mpls-outgoing; Mon, 9 Dec 2002 22:50: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 QQnsnz25394 for ; Mon, 9 Dec 2002 22:50:14 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 QQnsnz21412 for ; Mon, 9 Dec 2002 22:49: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 QQnsnz04681 for ; Mon, 9 Dec 2002 22:49:07 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 QQnsnz04659 for ; Mon, 9 Dec 2002 22:49:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9MnZSW028496 for ; Mon, 9 Dec 2002 17:49:36 -0500 (EST) 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 RAA04271 for ; Mon, 9 Dec 2002 17:49:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9Mn5S18743 for mpls@uu.net; Mon, 9 Dec 2002 17:49: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 QQnsnz25219 for ; Mon, 9 Dec 2002 22:47:30 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 QQnsnz09866 for ; Mon, 9 Dec 2002 22:46:30 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 QQnsnz02475 for ; Mon, 9 Dec 2002 22:46:30 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 QQnsnz02459 for ; Mon, 9 Dec 2002 22:46:28 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 RAA38095; Mon, 9 Dec 2002 17:43:27 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212092243.RAA38095@workhorse.fictitious.org> To: Shahram Davari cc: "'curtis@fictitious.org'" , David Allan , neil.2.harrison@bt.com, swallow@cisco.com, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Mon, 09 Dec 2002 13:46:49 PST." <4B6D09F3B826D411A67300D0B706EFDEB03B6C@nt-exch-yow.pmc-sierra.bc.ca> Date: Mon, 09 Dec 2002 17:43:27 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4B6D09F3B826D411A67300D0B706EFDEB03B6C@nt-exch-yow.pmc-sierra.bc.ca >, Shahram Davari writes: > Curtis, > > > 1)Yes the ICMP TTL expire will be generated and the packet > > will be delivered > > > to control plane. The control-plane will check and see the > > packet being OAM p > > > acket > > > and will respond accordingly. So the ingress may see an > > additional TTL expire > > > , > > > which is not harmful at all. > > > > Normal delivery of a packet with TTL=1 is to do TTL processing and > > then drop the packet. The payload of the packet is not examined to > > see if it is a service that is recognized for which additional > > diagnostics could be sent. Therefore, only a ICMP TTL expired is > > sent. > > > This is what RFC1812 says: > > A router MUST NOT discard a datagram just because it was received > with TTL equal to zero or one; if it is to the router and otherwise > valid, the router MUST attempt to receive it. > > I agree that if LSP-pings ends up in a router that it was not intended > it will get discarded. However, I am wondering what is the required behavior > in LSP-ping draft? Is it to get a reply even from an egress LSR that is not > the correct egress? If so then how can that egress use the RSVP return path > to respond? That is the case 1 I had listed as a deficiency to your suggestion. So you agree case 1 is valid. If packets were misdirected, then there has to be an RSVP return path for a TE tunnel and LDP requires that their be IP routes. If there are no IP routes then normal TTL ICMP goes nowhere. > I think not receiving a reply from a wrong egress should be fine, because > it gives you an LSP-ping failure. And then you could run trace-route, to figu > re out > the exact path. As you increment TTL on the outer label, for LDP you don't know the loopback address (or any address) of the routers. There would be no way to get information from these intermediate routers. > >Plus if the control plane is not IP, a case that some people > > insisted had to be supported, then that ICMP packet goes nowhere. > > I didn't know that LSP-ping works without IP in the control plane. Besides I > am not using ICMP to detect ping failure, just not receiving ping reply, woul > d indicate the LSP failure. I thought that was the purpose of delivery through the RSVP return path for the case where essentially static TE tunnels were used (configured by the NMS) or IP is not trusted. I don't like this but somehow I thought that was the purpose. [...] An MPLS echo request would normally have "Reply via an IPv4 UDP packet"; if the normal IPv4 return path is deemed unreliable, one may use "Reply via an IPv4 UDP packet with Router Alert" (note that this requires that all intermediate routers understand and know how to forward MPLS echo replies) or "Reply via the control plane" (this is currently only defined for control plane that uses RSVP). > > > 2)MY proposal handles the ECMP, if the ECMP algorithm is > > only based on MPLS > > > stack. In case the ECMP algorithm is also based on IP Dest Address, > > > then you are correct, my proposal will not be able to exercise the > > > ECMP paths. But: > > > > I was talking about reality where both MPLS based and IP header based > > load spliting occurs. You have to handle both. > > > > > The current proposal may not be able to exercise the ECMP > > paths either, > > > because the hashing algorithm may not necessarily be based > > on the first 7 bit > > > s of the IP address. And also you need to scan through 16 > > million addresses i > > > n order > > > to make sure you exercise all the ECMP paths. > > > > Hash exercises all bits. Limiting the addressing to one host address > > makes matters worse. Randomly trying addresses is not a good way to > > check for multiple paths. > > But isn't this what the draft currently proposes: "the destination IP address > is a (randomly chosen) address from 127/8" ? > > -Shahram And if you were paying attention you would have noted that I have repeatedly stated that the means to handle ECMP is deficient. I haven't come up with a complete solution but at least I've managed more than a one sentence "proposal" that won't support ECMP at all. Curtis > > I sent three message on deficiencies in ECMP handling. One enumerated > > some cases. A second noted the multiple branch points problem. A > > third suggested a way around it but noted that this didn't exercise > > the forwarding plane, only the control plane. > > > > > > > Secondly, it is > > > > > not my draft, those who have written it should find > > > > alternate methods. > > > > > > > > They have proposed something that will work. You have now made a > > > > counterproposal. You need to justify on technical > > grounds why not to > > > > use their proposal, why yours will work, and why yours is better. > > > > > > Here is the justification: > > > > > > My proposal works fine at the intended or unintended egress. > > > > No it doesn't see above. > > > > > My proposal does not support ECMP, but the current > > proposal, does not > > > support ECMP in all implementations either. > > > > If it turns out that we need an address range to exercise IP src/dst > > based hash, then your proposal is unacceptable. > > > > > My proposal, does not require any configuration of the IP > > filters in all > > > LSRs, which is required by current proposal. > > > > Justifying this on the basis that a configuration entry on *some* > > routers might have to be changed is a very weak justification. > > > > > My proposal does not force us to justify the SHOULD NOT > > part of standard RFCs > > > > RFC1812 explicitly states that 127/8 can't be forwarded except to the > > loopback device. Therefore the exception is already in place in a > > standard RFC. So give up on this already. > > > > > -Shahram > > > > Lets see if there is support for your proposal. > > > > Curtis > > > From owner-mpls@UU.NET Mon Dec 9 18:11: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 SAA07421 for ; Mon, 9 Dec 2002 18:11:02 -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 QQnsoa05052 for ; Mon, 9 Dec 2002 23:13: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 QQnsoa02299; Mon, 9 Dec 2002 23:12:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsoa15773 for mpls-outgoing; Mon, 9 Dec 2002 23:12:08 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 QQnsoa15757 for ; Mon, 9 Dec 2002 23:12:05 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 QQnsoa29130 for ; Mon, 9 Dec 2002 23:11:40 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 QQnsoa08314 for ; Mon, 9 Dec 2002 23:11:39 GMT Received: from maile.telia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: maile.telia.com [194.22.190.16]) id QQnsoa08288 for ; Mon, 9 Dec 2002 23:11:38 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by maile.telia.com (8.12.5/8.12.5) with ESMTP id gB9NBbfo017502 for ; Tue, 10 Dec 2002 00:11:37 +0100 (CET) X-Original-Recipient: Received: from pi.se (h70n2fls31o888.telia.com [213.64.120.70]) by d1o888.telia.com (8.10.2/8.10.1) with ESMTP id gB9NBb212451 for ; Tue, 10 Dec 2002 00:11:37 +0100 (CET) Message-ID: <3DF52306.4020601@pi.se> Date: Tue, 10 Dec 2002 00:11:02 +0100 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: [Fwd: Reminder: Deadline for input on sub-ip discussion] 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, my reading of this is that Harald asks for a "show of hands", to be able to decide the rough consensus. /Loa -------- Original Message -------- Subject: Reminder: Deadline for input on sub-ip discussion Date: Mon, 09 Dec 2002 22:21:59 +0100 From: Harald Tveit Alvestrand To: ietf@ietf.org All, On Wed Dec 4th, we asked for input to help us decide on the future of the SUB-IP Area. See our posting at http://www.ietf.org/mail-archive/ietf/Current/msg18370.html We had a large majority of people at the SUBIP Area meeting in Atlanta expressing that they want the area to be long(er) lived. This will be part of our input. But we need/want to hear from the IETF community. So please express your opionion (and the reasoning behind it) asap on ietf@ietf.org, but certainly before Thursday Dec 12th 10am US Eastern time. As expressed in the above posting (with data points and discussion included), the 3 choices for the SUB-IP Area seem to be: 1/ move WGs (back) to permanent areas: migrate the SUB-IP working groups to other IETF areas sometime soon, likely before next summer and close the SUB-IP area. Also, reconstitute the SUB-IP (and/or other) directorates to ensure the continued coordination between the remaining WGs. 2/ establish a long-term area: decide that the SUB-IP area will be a long-term one, clearly define its charter, and ask the nomcom to select one or two people to be Area Directors 3/ status quo: continue the SUB-IP Area as a temporary, ad-hoc effort, much as it has been, with the IESG selecting two sitting ADs to continue the effort that Bert & Scott have been doing. But maybe give more responsibility to the working group's technical advisors, normally the AD from the area where the working group might otherwise live. The opinions expressed so far seem to show clearly that the community is divided on the issue, with perhaps some preference for the status quo (alternative 3). If you have a strong preference for one (or two) of these, and have not yet said so, please indicate your opinion (and your reasons) by mail to ietf@ietf.org before Thursday. Thank you! Harald Alvestrand, for the IESG (please repost this message where appropriate) -- Loa Andersson Mobile +46 739 81 21 64 Email loa@pi.se From owner-mpls@UU.NET Mon Dec 9 18:11: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 SAA07437 for ; Mon, 9 Dec 2002 18:11:11 -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 QQnsoa00061 for ; Mon, 9 Dec 2002 23:14: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 QQnsoa17715; Mon, 9 Dec 2002 23:06:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsoa14449 for mpls-outgoing; Mon, 9 Dec 2002 23:06:27 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 QQnsoa14439 for ; Mon, 9 Dec 2002 23:06:24 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 QQnsoa16522 for ; Mon, 9 Dec 2002 23:06:10 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 QQnsoa17208 for ; Mon, 9 Dec 2002 23:06:10 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 QQnsoa17194 for ; Mon, 9 Dec 2002 23:06:09 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9N6c6Z000464 for ; Mon, 9 Dec 2002 18:06:38 -0500 (EST) 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 SAA05369 for ; Mon, 9 Dec 2002 18:06:08 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9N68421779 for mpls@uu.net; Mon, 9 Dec 2002 18:06:08 -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 QQnsoa13590 for ; Mon, 9 Dec 2002 23:04: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 QQnsoa11561 for ; Mon, 9 Dec 2002 23:04: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 QQnsoa01900 for ; Mon, 9 Dec 2002 23:04:20 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 QQnsoa01877 for ; Mon, 9 Dec 2002 23:04:19 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 SAA38276; Mon, 9 Dec 2002 18:02:24 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212092302.SAA38276@workhorse.fictitious.org> To: "Gray, Eric" cc: "'curtis@fictitious.org'" , "'erosen@cisco.com'" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping - ECMP thread (continued) In-reply-to: Your message of "Mon, 09 Dec 2002 17:32:36 EST." <1117F7D44159934FB116E36F4ABF221B0267ED64@celox-ma1-ems1.celoxnetworks.com> Date: Mon, 09 Dec 2002 18:02:24 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <1117F7D44159934FB116E36F4ABF221B0267ED64@celox-ma1-ems1.celoxnetwor ks.com>, "Gray, Eric" writes: > Curtis, > > > Actually src/dst addresses are used and the hash is over those 64 > > bits. Some implementations use (or used) the port numbers as well. > > The idea was to split up the traffic but make sure no IP microflow was > > reordered. > > This is an unjustified assertion about implementations > in general. You are not in a position to make assertions about > how all implementations do this. > > > The normal HASH is over a 64 bit quantity. ... > > Again, this is an assertion though how anyone might > determine what the "normal" hash algorithms might include > is beyond me. It comes from a bit over a decade working in Internet operations and in IP protocol development and experience with a large number of routers. Plus it is documented in RFC 2992. 2992 Analysis of an Equal-Cost Multi-Path Algorithm. C. Hopps. November 2000. (Format: TXT=17524 bytes) (Status: INFORMATIONAL) I think that justifies the assertion. > > > My point is that the usefulness of this address > > > range depends on an assumption that ECMP hash algorithms > > > will include some part of the least significant bytes of > > > the destination IP address. This is a grave restriction > > > on the use of ECMP algorithms and should not be encouraged. > > > If you cannot make this assumption, then the existence of > > > this address range would not be useful and would in fact > > > be misleading. > > > > This is a safe assumption, but if not, then rather than a 127/8 > > address, the midpoint must return some indication that no address in > > the range will allow the diagnostic. The indication could be 0.0.0.0. > > This might make sense. OK. > > If there is a router that does ECMP and uses an IP hash that doesn't > > include the lower 24 bits, I'd be really surprised. I don't think > > such a thing exists or that there is any good reason to build such a > > thing and therefore your objection has no merit. > > Then you should be prepared to be surprised. In > general, it is sufficient to group flows using either a > source or a destination IP address based hash. Further, > it is of some importance to use a range of algorithms, or > (non-exclusive) a variation of key sources/patterns so > that it is possible for the same source and destination > to map to a different has key at different places in the > network. Finally, it is very important to keep the hash > algorithms simple. That is the purpose of the random key to the hash, periodically updated (very long interval). > Consequently, it is possible that you may discover > that some schemes use only a small-ish set of bits from > either the source or destination IP address, depending > on the location of the device, and the direction of packet > flow, relative to the network core. Even if the entire > 64 bits of source and destination IP address is injected > into some algorithms, it is possible that steps in the > algorithms themselves may ignore some of those bits. A good hash does not ignore any of the bits. > If you believe that my objection still has no merit, > then we are unlikely to find common ground for further > discussion - at least with respect to this issue. Can you please name such a router. I know it is not Cisco, Juniper, or Avici. Nor the old Bay routers, or Ironbridge, or Pluris or the former Argon. Some of the newer edge boxes may have done this. If so, can you please name one? > > The problem of multiple ECMP branch points remains a problem which > > nothing proposed so far addressed adequately (unless you count > > spraying over the whole 127/8 range as addressing this). > > Address spraying would not adequately address this > either. Such a router would be quite broken not because MPLS-ping wouldn't work but the oad split wouldn't be very good. If making a purchasing decision, I'd hand the maker a copy of RFC2992 and wait for them to fix the routers or go elsewhere. > > > However, if you proposed a more straight-forward > > > approach - requiring an ECMP origination point to (some > > > day) support the ability to recognize a Ping packet and > > > (presumably on it's own initiative) produce its own Ping > > > packets for all equal cost paths - that approach does > > > seem useful and we should think about it some more. > > > > I thought I just did propose something (not in the attached message > > but in a prior message) that unlike what you state above requires no > > change to forwarding. It requires only a change in MPLS TTL expired > > processing if the payload is MPLS-ping (which is already required). > > It is really spread over three messages. Do I need to resend it in > > one message? > > Either that, or point out which three messages. I'll just resend them as one. Curtis > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 From owner-mpls@UU.NET Mon Dec 9 18:29: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 SAA08036 for ; Mon, 9 Dec 2002 18:29:52 -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 QQnsoc23348 for ; Mon, 9 Dec 2002 23:32: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 QQnsoc20771; Mon, 9 Dec 2002 23:31:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsoc17621 for mpls-outgoing; Mon, 9 Dec 2002 23:31: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 QQnsoc17616 for ; Mon, 9 Dec 2002 23:31:18 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 QQnsoc21130 for ; Mon, 9 Dec 2002 23:30:54 GMT From: neil.2.harrison@bt.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 QQnsoc12326 for ; Mon, 9 Dec 2002 23:30:53 GMT Received: from mbibipnt08.HC.BT.COM by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQnsoc12300 for ; Mon, 9 Dec 2002 23:30:53 GMT Received: by mbibipnt08.nat.bt.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Dec 2002 23:31:05 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A35389014CFCD7@i2km07-ukbr.domain1.systemhost.net> To: curtis@fictitious.org, Shahram_Davari@pmc-sierra.com Cc: dallan@nortelnetworks.com, swallow@cisco.com, mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Mon, 9 Dec 2002 23:30:47 -0000 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 Curtis, Please see below. regards, Neil Curtis Villamizar wrote 09 December 2002 22:43 > > This is what RFC1812 says: > > > > A router MUST NOT discard a datagram just because it was received > > with TTL equal to zero or one; if it is to the router > and otherwise > > valid, the router MUST attempt to receive it. > > > > I agree that if LSP-pings ends up in a router that it was > not intended > > it will get discarded. However, I am wondering what is the > required behavior > > in LSP-ping draft? Is it to get a reply even from an egress > LSR that is not > > the correct egress? If so then how can that egress use the > RSVP return path > > to respond? > > That is the case 1 I had listed as a deficiency to your suggestion. > So you agree case 1 is valid. > > If packets were misdirected, then there has to be an RSVP return path > for a TE tunnel and LDP requires that their be IP routes. NH=> I refer to the RSVP bit. If a pkt gets misdirected and is requesting a return by the RSVP control-plane, then of course as you rightly observe there has to be such a return control-plane path available. But how is it possible that a pkt which is misdirected to some arbitrary egress point will have a RSVP return path back to some fixed source point? This appears not to be a sensible thing to assume. So this option (ie using RSVP) does not appear to cater for the needs of identifying where misdirected traffic ends up. From owner-mpls@UU.NET Mon Dec 9 18:52:58 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 SAA08696 for ; Mon, 9 Dec 2002 18:52:57 -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 QQnsod20388 for ; Mon, 9 Dec 2002 23:55: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 QQnsod11954; Mon, 9 Dec 2002 23:50:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsod19311 for mpls-outgoing; Mon, 9 Dec 2002 23:50: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 QQnsod19305 for ; Mon, 9 Dec 2002 23:50:24 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 QQnsod24793 for ; Mon, 9 Dec 2002 23:50: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 QQnsod07871 for ; Mon, 9 Dec 2002 23:50:08 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 QQnsod07864 for ; Mon, 9 Dec 2002 23:50:08 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9NoaUl004877 for ; Mon, 9 Dec 2002 18:50:36 -0500 (EST) 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 SAA07787 for ; Mon, 9 Dec 2002 18:50:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9No6r27732 for mpls@uu.net; Mon, 9 Dec 2002 18:50:06 -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 QQnsod19233 for ; Mon, 9 Dec 2002 23:49: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 QQnsod26574 for ; Mon, 9 Dec 2002 23:48:09 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 QQnsod09518 for ; Mon, 9 Dec 2002 23:48:09 GMT Received: from web14508.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web14508.mail.yahoo.com [216.136.224.71]) id QQnsod09511 for ; Mon, 9 Dec 2002 23:48:08 GMT Message-ID: <20021209234807.1413.qmail@web14508.mail.yahoo.com> Received: from [130.65.88.101] by web14508.mail.yahoo.com via HTTP; Mon, 09 Dec 2002 15:48:07 PST Date: Mon, 9 Dec 2002 15:48:07 -0800 (PST) From: nitin p Subject: Re: [MPLS-OPS]: Jitter and MPLS To: alok , GAlmaalouf@aol.com, eosborne@cisco.com, jshen@cad.zju.edu.cn Cc: rameshbabu_j@infosys.com, mpls-ops@mplsrc.com, mpls@UU.NET In-Reply-To: <021001c29f91$d4de2dc0$81c802c0@alok> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Alok, > hi Nitin, > > just curious... > your IP result says "0.023" end to end.. > can u share "IP across what was your ingress LER" > IP across your Egress LER > and IP across your core too for a given packet? In my measuremnts these delays are at a hop. --H--e0[NODE]e1---H-- | | +---[SNIFFER]---+ H: Hub Node:LSR/LER/L3 router I am calculating delays at e0 and e1 and difference will give the hop delay. Someone please correct me if there is some problem in my measuring technique. So end-to-end delay will be : n*(perhop-delay), in case of IP, assuming link speed is fast enough. Thanks, Nitin > > -rgds > alok > ----- Original Message ----- > From: nitin p > To: ; ; > > Cc: ; > ; > Sent: Monday, December 09, 2002 7:54 PM > Subject: Re: [MPLS-OPS]: Jitter and MPLS > > > > Hi George, > > I have posted my results in of the mails, but here > > they are again: > > > > Ingress: 3.665 milli seconds > > Egress: 0.035 milliseconds > > core: 0.018 milliseconds > > > > IP: 0.023 milliseconds. > > > > For my measurements I have attached a sniffer at > both > > incomming and outgoing interface (same sniffer for > > both so no clocking issue). I did the same thing > for > > boths LSR and LERs. Question of number of LSRs > should > > not affect the results, considering my measuring > > technique. > > Jing said He is also getting similar results, I am > not > > sure how he has done his measurement. > > > > Thanks, > > Nitin > > > > > > > > --- GAlmaalouf@aol.com wrote: > > > Nitin- > > > > > > It would be much helpful if you can specify the > > > delay in a quantitative > > > manner. This way we can really understand what > are > > > you talking about in term > > > of delays. Also, the specific number of Hops or > LPS > > > router, how many egress > > > and ingress steps involved in the calculation. A > > > general observation would > > > not be very accurate, since the implementation > > > would be very different from > > > one application versus the other, and from one > type > > > of services versus > > > another. > > > > > > Thanks- > > > > > > George > > > > > > > > > > > > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Mail Plus - Powerful. Affordable. Sign up > now. > > http://mailplus.yahoo.com > > > > ------- > > The MPLS-OPS Mailing List > > Subscribe/Unsubscribe: > http://www.mplsrc.com/mplsops.shtml > > Archive: > http://www.mplsrc.com/mpls-ops_archive.shtml > > > __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From owner-mpls@UU.NET Mon Dec 9 19:09:48 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 TAA09585 for ; Mon, 9 Dec 2002 19:09:48 -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 QQnsoe14426 for ; Tue, 10 Dec 2002 00:12:37 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 QQnsoe01471; Tue, 10 Dec 2002 00:05:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsoe08026 for mpls-outgoing; Tue, 10 Dec 2002 00:04:56 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 QQnsoe08016 for ; Tue, 10 Dec 2002 00:04:52 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 QQnsoe04130 for ; Tue, 10 Dec 2002 00:03:07 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 QQnsoe17582 for ; Tue, 10 Dec 2002 00:03:07 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 QQnsoe17577 for ; Tue, 10 Dec 2002 00:03:06 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBA03ZAt006005 for ; Mon, 9 Dec 2002 19:03:36 -0500 (EST) 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 TAA08449 for ; Mon, 9 Dec 2002 19:03:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBA035o00207 for mpls@uu.net; Mon, 9 Dec 2002 19:03: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 QQnsoe00446 for ; Tue, 10 Dec 2002 00:01:45 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 QQnsoe10262 for ; Tue, 10 Dec 2002 00:01: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 QQnsoe16556 for ; Tue, 10 Dec 2002 00:01:36 GMT Received: from web14509.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web14509.mail.yahoo.com [216.136.224.168]) id QQnsoe16552 for ; Tue, 10 Dec 2002 00:01:35 GMT Message-ID: <20021210000125.20179.qmail@web14509.mail.yahoo.com> Received: from [130.65.88.101] by web14509.mail.yahoo.com via HTTP; Mon, 09 Dec 2002 16:01:25 PST Date: Mon, 9 Dec 2002 16:01:25 -0800 (PST) From: nitin p Subject: Re: [MPLS-OPS]: Jitter and MPLS To: Anish Verma Cc: mpls@UU.NET In-Reply-To: <01e201c29f9a$d6293540$0c0aa8c0@ANISH> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Anish, Here is my topology [TG]---[Ing]----[LSR1]--- [LSR2]----[Egr]----[Rec] As you can see destination and Egress are not same. In my last mail I have posted the mechanism I used to measure these delays. Your comments are most welcome. Thanks, Nitin --- Anish Verma wrote: > hi nitin, > Could you plz show the topology that u r using? > I mean whether destination and egress node in ur > topology r same. > if egress node and destination r same, then at > the egress the IP lookup > will not be > there as packet is destined for the node itself. > That make dealy at egress much lesser than the > ingress. > > correct me if i am wrong > anish > > > ----- Original Message ----- > From: "nitin p" > To: "Eric Osborne" ; "Jing Shen" > > Cc: "Eric Osborne" ; "J.C.Ramesh > Babu" > ; ; > > Sent: Sunday, December 08, 2002 3:25 AM > Subject: Re: [MPLS-OPS]: Jitter and MPLS > > > > Hi, > > Sorry for interrupting the discussion between Eric > and > > Jing. > > > > Recently I have also measured the hop delay in the > > mpls-linux implementation of sourceforge.net. > > > > My results shows that delay at core (LSR) is less > than > > that is observed in IP. > > Delay at egress(LER) delay in MPLS is slightly > more > > than that in IP. > > But, delay at ingress(LER) is much more than tha > in > > IP. > > > > With my results I can infer that in a network of > > 1000s(may be 100s) hops overall delay in MPLS will > be > > less that that in IP, but for samaller networks > MPLS > > results much more delay.I am not claiming that my > > results are applicable to commercial > implementations, > > which might have good hardware support unlike my > test > > where I have used PC. > > It makes sense that LERs will take more time than > > LSRs,but what I coudn't understand is the > performance > > difference between Ingress and Egress. > > > > Any comments on this are most welcome. > > Thanks, > > Nitin > > > > > > --- Eric Osborne wrote: > > > On Sat, Dec 07, 2002 at 09:14:19PM +0800, Jing > Shen > > > wrote: > > > > Thanks for Eric's comment. And, read my > comment in > > > line please. > > > > > > > > > > > > > > 1) TCP throughput of MPLS is a little > > > smaller than IP when path MTU is > > > > > > the same. > > > > > > and difference increases when path > MTU > > > decreases. > > > > > > > > > > MPLS packets are 4 bytes (or more) bigger > than > > > IP packets. If you do > > > > > not allow for this in your link MTU, then > you > > > have smaller effective > > > > > bandwidth inside TCP. Allow for that in > your > > > link MTU (as any > > > > > reasonable implementation should) and you > don't > > > have this problem. > > > > > > > > Yes. We notice that at the first stage of our > > > implementation and then we > > > > modify the engine to allow for such situation. > Our > > > implementation allows > > > > for a label stack with depth of 8, and we use > only > > > one. But, that do has > > > > effect on TCP throughput if the same path is > taken > > > by IP and MPLS. > > > > > > > > > > Have you been able to determine what made this > > > impact? If your TCP > > > segments can open up to the same size under both > > > MPLS and IP, then all > > > you add is another 4 bytes of transmission > delay, > > > which should be so > > > close to zero it's inconsequential. And if > > > everything has this small > > > additional delay, then that should in no way > create > > > jitter in the > > > network. > > > > > > > > > > > > So this is a test of your forwarding > equipment. > > > Equipment which takes > > > > > zero or negligible time to perform this > > > encap/decap will not have this > > > > > problem. > > > > > > > > As I know some of manufacturers announce that > > > their router/switch > > > > could operate at line speed, and the latency > in a > > > switch is > > > > negeligible. But, what about situation of > heavy > > > load? The ability > > > > of a linux based forwarding engine is surely > not > > > at the same level > > > > of any hardware based product, but to my > personal > > > opinion any > > > > comparation should be taken at the same > situation > > > ( hardware, > > > > software etc). > > > > > > A switch that operates at line rate can still do > so > > > under heavy load. > > > There are well-known mechanisms (DiffServ) for > > > controlling performance > > > under heavy load. Theoretically, there should > be no > > > difference in the > > > performance of DiffServ whether applied to IP, > MPLS, > > > or for that > > > matter, Appletalk, IPX, or any other switched > packet > > > technology. If > > > you have found a platform-independent issue > inherent > > > to MPLS that > > > causes jitter, I am very interested in seeing > it. > > > > > > > Another reason is that we try to find out how > > > MPLS compares with IP > > > > when realtime multimedia content is loaded. > The > > > bandwidth > > > > requirement of realtime distributed virtual > > > reality system is at the > > > > level of Gbps, and that value may increase > when > > > number of people > > > > participating increases. So, we want to > measure > > > the situation that > > > > accumulated dec/enc time is not negligible. > > > > > > OK, that's a fair thing to want to measure. But > > > again, you're testing > > > a specific implementation, and it's not > reasonable > > > to extend that > > > comparison to any broader scope. > > > > > > > > > > > Well, if R12000 is as cheap as 2511 that's not > a > > > question at all :-) > > > > > > > > > > OK, if you want to talk specific router models, > let > > > me speak to the > > > ones I know best. :) A 12k and a 2500[*] are > === message truncated === __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From owner-mpls@UU.NET Mon Dec 9 20:12:50 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 UAA12160 for ; Mon, 9 Dec 2002 20:12:50 -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 QQnsoj06162 for ; Tue, 10 Dec 2002 01:15: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 QQnsoi02758; Tue, 10 Dec 2002 01:13:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsoi03404 for mpls-outgoing; Tue, 10 Dec 2002 01:13: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 QQnsoi03382 for ; Tue, 10 Dec 2002 01:12: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 QQnsoi18261 for ; Tue, 10 Dec 2002 01:12: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 QQnsoi02012 for ; Tue, 10 Dec 2002 01:12:16 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 QQnsoi02005 for ; Tue, 10 Dec 2002 01:12:16 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBA1CiA4011599 for ; Mon, 9 Dec 2002 20:12:45 -0500 (EST) 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 UAA11488 for ; Mon, 9 Dec 2002 20:12:14 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBA1CEO06334 for mpls@uu.net; Mon, 9 Dec 2002 20:12:14 -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 QQnsnq05743 for ; Mon, 9 Dec 2002 20:36: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 QQnsnq07070 for ; Mon, 9 Dec 2002 20:34:59 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 QQnsnq15561 for ; Mon, 9 Dec 2002 20:34:58 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 QQnsnq15516 for ; Mon, 9 Dec 2002 20:34:57 GMT Received: (qmail 27458 invoked by uid 104); 9 Dec 2002 20:34:56 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4236. . Clean. Processed in 0.560241 secs); 09 Dec 2002 20:34:56 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 9 Dec 2002 20:34:55 -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 gB9KYsQ00352; Mon, 9 Dec 2002 12:34:55 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Mon, 9 Dec 2002 12:34:54 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B6B@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'curtis@fictitious.org'" Cc: David Allan , neil.2.harrison@bt.com, swallow@cisco.com, mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Mon, 9 Dec 2002 12:34:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Curtis, Could you please enlighten us on how one can test all the ECMP paths without needing to send 16 million LSP-pings? -Shahram > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: Monday, December 09, 2002 3:15 PM > To: Shahram Davari > Cc: 'curtis@fictitious.org'; David Allan; neil.2.harrison@bt.com; > swallow@cisco.com; mpls@UU.NET > Subject: Re: Last call on LSP Ping > > > > In message > <4B6D09F3B826D411A67300D0B706EFDEB03B67@nt-exch-yow.pmc-sierra.bc.ca > >, Shahram Davari writes: > > > > First of all I did propose using the egress IP address and > > > setting the > > > > TTL=1 in the IP header. This makes sure that the LSP-ping > > > packet will > > > > not get forwarded after the MPLS labels are poped. > > > > > > Glad to see this change to a technical discussion. Took a while. > > > > > > This proposal has two flaws, 1) when the label gets POPed and the > > > egress isn't the router you thought it should be the > response is an > > > ICMP TTL expired, 2) no way to handle ECMP is proposed. > > > > > > Please indicate how you would handle ECMP. > > > > > > 1)Yes the ICMP TTL expire will be generated and the packet > will be delivered > > to control plane. The control-plane will check and see the > packet being OAM p > > acket > > and will respond accordingly. So the ingress may see an > additional TTL expire > > , > > which is not harmful at all. > > Normal delivery of a packet with TTL=1 is to do TTL processing and > then drop the packet. The payload of the packet is not examined to > see if it is a service that is recognized for which additional > diagnostics could be sent. Therefore, only a ICMP TTL expired is > sent. Plus if the control plane is not IP, a case that some people > insisted had to be supported, then that ICMP packet goes nowhere. > > > 2)MY proposal handles the ECMP, if the ECMP algorithm is > only based on MPLS > > stack. In case the ECMP algorithm is also based on IP Dest Address, > > then you are correct, my proposal will not be able to exercise the > > ECMP paths. But: > > I was talking about reality where both MPLS based and IP header based > load spliting occurs. You have to handle both. > > > The current proposal may not be able to exercise the ECMP > paths either, > > because the hashing algorithm may not necessarily be based > on the first 7 bit > > s of the IP address. And also you need to scan through 16 > million addresses i > > n order > > to make sure you exercise all the ECMP paths. > > Hash exercises all bits. Limiting the addressing to one host address > makes matters worse. Randomly trying addresses is not a good way to > check for multiple paths. > > I sent three message on deficiencies in ECMP handling. One enumerated > some cases. A second noted the multiple branch points problem. A > third suggested a way around it but noted that this didn't exercise > the forwarding plane, only the control plane. > > > > > Secondly, it is > > > > not my draft, those who have written it should find > > > alternate methods. > > > > > > They have proposed something that will work. You have now made a > > > counterproposal. You need to justify on technical > grounds why not to > > > use their proposal, why yours will work, and why yours is better. > > > > Here is the justification: > > > > My proposal works fine at the intended or unintended egress. > > No it doesn't see above. > > > My proposal does not support ECMP, but the current > proposal, does not > > support ECMP in all implementations either. > > If it turns out that we need an address range to exercise IP src/dst > based hash, then your proposal is unacceptable. > > > My proposal, does not require any configuration of the IP > filters in all > > LSRs, which is required by current proposal. > > Justifying this on the basis that a configuration entry on *some* > routers might have to be changed is a very weak justification. > > > My proposal does not force us to justify the SHOULD NOT > part of standard RFCs > > RFC1812 explicitly states that 127/8 can't be forwarded except to the > loopback device. Therefore the exception is already in place in a > standard RFC. So give up on this already. > > > -Shahram > > Lets see if there is support for your proposal. > > Curtis > From owner-mpls@UU.NET Mon Dec 9 21:04: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 VAA13363 for ; Mon, 9 Dec 2002 21:04: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 QQnsom13942 for ; Tue, 10 Dec 2002 02:07: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 QQnsom11423; Tue, 10 Dec 2002 02:05:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsom25414 for mpls-outgoing; Tue, 10 Dec 2002 02:05:40 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 QQnsom25399 for ; Tue, 10 Dec 2002 02:05: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 QQnsom15003 for ; Tue, 10 Dec 2002 02:05: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 QQnsom09756 for ; Tue, 10 Dec 2002 02:05:07 GMT Received: from mtiwmhc11.worldnet.att.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mtiwmhc11.worldnet.att.net [204.127.131.115]) id QQnsom09745 for ; Tue, 10 Dec 2002 02:05:07 GMT Received: from 6640bbc3r131 ([12.81.7.80]) by mtiwmhc11.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with SMTP id <20021210020505.QOCA9286.mtiwmhc11.worldnet.att.net@6640bbc3r131>; Tue, 10 Dec 2002 02:05:05 +0000 Message-ID: <017a01c29ff0$676a91c0$3d06510c@6640bbc3r131> From: "Brijesh Kumar" To: "nitin p" , , , Cc: , , References: <20021209142401.24278.qmail@web14509.mail.yahoo.com> Subject: Re: [MPLS-OPS]: Jitter and MPLS Date: Mon, 9 Dec 2002 18:02:28 -0800 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 Nitin: You need to analyse your packet forwarding code and the system configuration with regards to: 1. What kind of L3 route look up is implemented? Is there any significant difference in the routing table size at the ingress and the egress node? In any case, measure time for route look up at ingress. 2. Make sure you add a specific route to destination instead of forwarding using a default route. This is to make sure you get average rather than worst case performance from whatever loop up algorithm you are running. 3. Also, have you set up any IP packet classification or access control policies at ingress? Check that the code does not do some default packet classification or apply any default access control policies when you have configured none? Both of these activities are very compute intensive and can substantially impact the performance. If that is the case, add suitable instrumentation code to your packet forwarding code. If you do the above, you are more likely to get the cause of long processing time at Ingress. It looks to me that you are unlikely to get similar results if you were to use some other implementations of the forwarding code. Try some other systems/implementation and see how it compares with your current results. Cheers, --brijesh ----- Original Message ----- From: "nitin p" To: ; ; Cc: ; ; Sent: Monday, December 09, 2002 6:24 AM Subject: Re: [MPLS-OPS]: Jitter and MPLS > Hi George, > I have posted my results in of the mails, but here > they are again: > > Ingress: 3.665 milli seconds > Egress: 0.035 milliseconds > core: 0.018 milliseconds > > IP: 0.023 milliseconds. > > For my measurements I have attached a sniffer at both > incomming and outgoing interface (same sniffer for > both so no clocking issue). I did the same thing for > boths LSR and LERs. Question of number of LSRs should > not affect the results, considering my measuring > technique. > Jing said He is also getting similar results, I am not > sure how he has done his measurement. > > Thanks, > Nitin > > > > --- GAlmaalouf@aol.com wrote: > > Nitin- > > > > It would be much helpful if you can specify the > > delay in a quantitative > > manner. This way we can really understand what are > > you talking about in term > > of delays. Also, the specific number of Hops or LPS > > router, how many egress > > and ingress steps involved in the calculation. A > > general observation would > > not be very accurate, since the implementation > > would be very different from > > one application versus the other, and from one type > > of services versus > > another. > > > > Thanks- > > > > George > > > > > > > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > > From owner-mpls@UU.NET Mon Dec 9 22:05:26 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 WAA14682 for ; Mon, 9 Dec 2002 22:05:26 -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 QQnsoq05461 for ; Tue, 10 Dec 2002 03:08:00 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 QQnsoq00672; Tue, 10 Dec 2002 03:05:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsoq19022 for mpls-outgoing; Tue, 10 Dec 2002 03:04: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 QQnsoq18997 for ; Tue, 10 Dec 2002 03:04:28 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 QQnsoq04034 for ; Tue, 10 Dec 2002 03:04: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 QQnsoq27967 for ; Tue, 10 Dec 2002 03:04:13 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 QQnsoq27960 for ; Tue, 10 Dec 2002 03:04:13 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBA34f7j019061 for ; Mon, 9 Dec 2002 22:04:42 -0500 (EST) 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 WAA15865 for ; Mon, 9 Dec 2002 22:04:11 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBA34BT16937 for mpls@uu.net; Mon, 9 Dec 2002 22:04:11 -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 QQnsnj17911 for ; Mon, 9 Dec 2002 18:56:49 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 QQnsnj02891 for ; Mon, 9 Dec 2002 18:56:20 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 QQnsnj17491 for ; Mon, 9 Dec 2002 18:56:10 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 QQnsnj17416 for ; Mon, 9 Dec 2002 18:56:08 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 NAA36286; Mon, 9 Dec 2002 13:42:54 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212091842.NAA36286@workhorse.fictitious.org> To: Shahram Davari cc: "'curtis@fictitious.org'" , David Allan , neil.2.harrison@bt.com, swallow@cisco.com, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Mon, 09 Dec 2002 10:05:32 PST." <4B6D09F3B826D411A67300D0B706EFDEB03B64@nt-exch-yow.pmc-sierra.bc.ca> Date: Mon, 09 Dec 2002 13:42:54 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4B6D09F3B826D411A67300D0B706EFDEB03B64@nt-exch-yow.pmc-sierra.bc.ca >, Shahram Davari writes: > I think you are just imagining things that are not true. > > -Shahram I'll admit that any alternate proposal to using 127/8 made by you was purely imagined on my part. Or were you referring to something else? :-) Curtis > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > Sent: Monday, December 09, 2002 12:23 PM > > To: Shahram Davari > > Cc: 'curtis@fictitious.org'; David Allan; neil.2.harrison@bt.com; > > swallow@cisco.com; mpls@UU.NET > > Subject: Re: Last call on LSP Ping > > > > > > > > In message > > <4B6D09F3B826D411A67300D0B706EFDEB03B5E@nt-exch-yow.pmc-sierra.bc.ca > > >, Shahram Davari writes: > > > Curtis, > > > > > > > Dave, > > > > > > > > Since you asked, yes I do think the comments by two or more > > > > individuals are more obstructionist than constructive, > > but it seems > > > > particularly clear in this issue. > > > > > > > > > > I am disturbed by this statement. Would you please point > > out which of my > > > ignored comments are obstructive rather than constructive? As far as > > > I can see many of my comments were even echoed by Eric > > rosen (unless you beli > > > eve > > > that he intends to obstruct his own company's proposal). > > > > > > Regarding the 127/8 issue, many others have the same > > concern. Besides, > > > this is not an obstructive comment, because there are many > > other ways around > > > it. > > > Obstructive means the draft will fall apart without it. > > > > > > -Shahram > > > > > > You have not cited any technical reason for avoiding 127/8. You have > > cited documents and tried to manipulate the interpretation to claim > > that any use of 127/8 is forbidden. > > > > What alternate did you propose that would have the characteristics of > > never being routeable and therefore never have to potential to be > > delivered by IP rather than the intended MPLS LSP(s)? I must have > > missed that proposal. > > > > Obstruction means getting in the way (of some sort of progress) for no > > other reason than to get in the way. > > > > If you are making a point to steer us toward a better solution, that > > certainly hasn't been clear. If you think some entirely alternate > > solution (Y.1711) is a better solution, then you should work on that > > solution and stay out of this discussion. It is like disrupting the > > ISIS WG with a constant "OSPF is better" mantra or insisting that ISIS > > do everything the OSPF way (or doing the same in the OSPF WG). > > > > Curtis > > > From owner-mpls@UU.NET Mon Dec 9 22:39:17 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 WAA15460 for ; Mon, 9 Dec 2002 22:39:17 -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 QQnsos14294 for ; Tue, 10 Dec 2002 03:42: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 QQnsos05841; Tue, 10 Dec 2002 03:37:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsos22851 for mpls-outgoing; Tue, 10 Dec 2002 03:37:25 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 QQnsos22839 for ; Tue, 10 Dec 2002 03:37: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 QQnsos13296 for ; Tue, 10 Dec 2002 03:37: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 QQnsos20441 for ; Tue, 10 Dec 2002 03:37:08 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 QQnsos20433 for ; Tue, 10 Dec 2002 03:37:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBA3baSn020980 for ; Mon, 9 Dec 2002 22:37:36 -0500 (EST) 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 WAA17057 for ; Mon, 9 Dec 2002 22:37:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBA3b6q21992 for mpls@uu.net; Mon, 9 Dec 2002 22:37:06 -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 QQnsos22711 for ; Tue, 10 Dec 2002 03:36:07 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 QQnsos01116 for ; Tue, 10 Dec 2002 03:34: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 QQnsos03537 for ; Tue, 10 Dec 2002 03:34:57 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 QQnsos03524 for ; Tue, 10 Dec 2002 03:34:56 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 WAA39149; Mon, 9 Dec 2002 22:32:44 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212100332.WAA39149@workhorse.fictitious.org> To: neil.2.harrison@bt.com cc: curtis@fictitious.org, Shahram_Davari@pmc-sierra.com, dallan@nortelnetworks.com, swallow@cisco.com, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Mon, 09 Dec 2002 23:30:47 GMT." <0536FC9B908BEC4597EE721BE6A35389014CFCD7@i2km07-ukbr.domain1.systemhost.net> Date: Mon, 09 Dec 2002 22:32:44 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <0536FC9B908BEC4597EE721BE6A35389014CFCD7@i2km07-ukbr.domain1.system host.net>, neil.2.harrison@bt.com writes: > Curtis, > > Please see below. regards, Neil > > Curtis Villamizar wrote 09 December 2002 22:43 > > > > > This is what RFC1812 says: > > > > > > A router MUST NOT discard a datagram just because it was received > > > with TTL equal to zero or one; if it is to the router > > and otherwise > > > valid, the router MUST attempt to receive it. > > > > > > I agree that if LSP-pings ends up in a router that it was > > not intended > > > it will get discarded. However, I am wondering what is the > > required behavior > > > in LSP-ping draft? Is it to get a reply even from an egress > > LSR that is not > > > the correct egress? If so then how can that egress use the > > RSVP return path > > > to respond? > > > > That is the case 1 I had listed as a deficiency to your suggestion. > > So you agree case 1 is valid. > > > > If packets were misdirected, then there has to be an RSVP return path > > for a TE tunnel and LDP requires that their be IP routes. > NH=> I refer to the RSVP bit. If a pkt gets misdirected and is requesting a > return by the RSVP control-plane, then of course as you rightly observe > there has to be such a return control-plane path available. But how is it > possible that a pkt which is misdirected to some arbitrary egress point will > have a RSVP return path back to some fixed source point? This appears not > to be a sensible thing to assume. So this option (ie using RSVP) does not > appear to cater for the needs of identifying where misdirected traffic ends > up. > I looked at this again and it appears I had this wrong. If the "Downstream Mapping" was used to form a RESV, then this would be fine, but it is not the case. In order to have *any* MPLS/TE LSP going to an adjacent router, there must be an RSVP adjacency. The route up to the point where the path went wrong is in the MPLS-ping packet payload if the "Downstream Mapping" is present so the router could in principle send the packet back hop by hop in RSVP. I was assuming that the "Downstream Mapping" could be inverted but I see that the intent is to simply add the LSP_ECHO in the normal RESV for the LSP. As is it is just a continuity test. It seems that error indication on misdirected traffic is only possible if IP routing is used to deliver the reply. Even so, if the packet is misdirected, at some hop the packet arrives at the wrong router. In traceroute mode you can determine when this occurs and which router the traffic is being misdirected towards (if IP can be used to return the packet). Use of 127/8 directs the request to "whoever gets this". If the expected router-id is used as the address then the request times out. A timeout cannot be distinguished from a MPLS-ping incapable router. For LDP there is no way to determine the router-id of the router one hop beyond an MPLS-ping incapable router, so 127/8 must be used and TTL incremented. Curtis From owner-mpls@UU.NET Mon Dec 9 22:45: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 WAA15697 for ; Mon, 9 Dec 2002 22:45:03 -0500 (EST) 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 QQnsmu12937; Mon, 9 Dec 2002 15:02:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsmt12689 for mpls-outgoing; Mon, 9 Dec 2002 14:58:54 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 QQnsmt12564 for ; Mon, 9 Dec 2002 14:57:50 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 QQnsmt03281 for ; Mon, 9 Dec 2002 14:57: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 QQnsmt28082 for ; Mon, 9 Dec 2002 14:57:18 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 QQnsmt28078 for ; Mon, 9 Dec 2002 14:57:17 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB9EvkHQ028345 for ; Mon, 9 Dec 2002 09:57:46 -0500 (EST) 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 JAA24981 for ; Mon, 9 Dec 2002 09:57:15 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gB9EvFs13598 for mpls@uu.net; Mon, 9 Dec 2002 09:57:15 -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 QQnsmm13159 for ; Mon, 9 Dec 2002 13:09:25 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 QQnsmm18582 for ; Mon, 9 Dec 2002 13:09:13 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 QQnsmm27597 for ; Mon, 9 Dec 2002 13:09:13 GMT Received: from www.apara.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.106.140.220]) id QQnsmm27584 for ; Mon, 9 Dec 2002 13:09:12 GMT Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id gB9DOOM02440 for ; Mon, 9 Dec 2002 18:54:24 +0530 Received: from alok ([203.124.140.100]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id gB9DOLT02428; Mon, 9 Dec 2002 18:54:21 +0530 Message-ID: <049901c29f85$5bda5fe0$81c802c0@alok> From: "alok" To: , , References: <085301c29d34$503954f0$a4c7fe87@ad.infosys.com> <20021206110156.O28607@eosborne-u10.cisco.com> <3DF1659A.978EE288@cad.zju.edu.cn> <20021207003312.U28607@eosborne-u10.cisco.com> <3DF1F42B.9513CCA0@cad.zju.edu.cn> <007f01c29e07$a1cb2540$81c802c0@alok> <3DF493E1.EC248723@cad.zju.edu.cn> Subject: Re: [MPLS-OPS]: Jitter and MPLS Date: Mon, 9 Dec 2002 18:47:29 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, > alok, > > > > > > > I cant figure this point > > > > are you comparing ethernet--MPLS--IP--TCP frame with ethernet--IP--TCP > > frame? well then your frame size is larger....thats about the only > > difference i see. > > That's the reason. The reason why we take that is, we do not consider > MPLS as mechanism carrying TCP packet, and MPLS is to add new mechanism > to IP networks, so the overhead is considered to be the one affecting > throughput. If we want o compare payload of MPLS with payload of IP, > I can't find any acceptable parameters to be compared. > yes, but that way you can still come to a "final value" of MTU and make sure the core always has that MTU..which fits the maximum payload size "as of date". ...which i guess would be IPSEC in a way....(commericially most common)..just a guess... changing the MTU size is not going to be a big problem in the core as long as you can freeze on the "final value" that doesnt mess up the TCP/RWIN stuff and doesnt cause SAR... thats what i feels, im sure gurus on the list will give u better perspectives... (unless u have no end to number of encapsulations/labels/label in label and so on we are gonna get stuck i guess.....) so in you experimental network, simply increase average MTU to present +1 label size and the results will reflect more of what the final scenario will be.... i think. -rgds Alok From owner-mpls@UU.NET Tue Dec 10 03:11:38 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 DAA01329 for ; Tue, 10 Dec 2002 03:11:38 -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 QQnspk12508 for ; Tue, 10 Dec 2002 08:14: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 QQnspk07344; Tue, 10 Dec 2002 08:11:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQnspk15831 for mpls-outgoing; Tue, 10 Dec 2002 08:11:27 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 QQnspk15821 for ; Tue, 10 Dec 2002 08:11:24 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 QQnspk17777 for ; Tue, 10 Dec 2002 08:10: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 QQnspk12538 for ; Tue, 10 Dec 2002 08:10:44 GMT Received: from localhost.localdomain by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.129.237.108]) id QQnspk12505 for ; Tue, 10 Dec 2002 08:10:41 GMT Received: from mail.itpl (vajra.itpl [192.168.4.6]) by localhost.localdomain (8.11.6/8.11.2) with ESMTP id gBA8AeC01276 for ; Tue, 10 Dec 2002 13:40:40 +0530 Received: from test10 ([192.168.4.73]) by mail.itpl with Microsoft SMTPSVC(5.0.2195.4905); Tue, 10 Dec 2002 13:40:39 +0530 From: "sachin laddha" To: Subject: Multi-Area TE Protocol Extensions Date: Tue, 10 Dec 2002 13:53:36 +0530 Message-ID: <000d01c2a025$6fe04cc0$2d3fa8c0@itpl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 10 Dec 2002 08:10:39.0779 (UTC) FILETIME=[A08E8730:01C2A023] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, 'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as "Initial requirements are given here for protocol support of the multi-area TE methods, which include needs to support * path-computation-server (PCS) functionality [kompella, lee, vasseur, te-qos-routing], * query functionality [query, vasseur], * crankback functionality [crankback], and, optionally, * TE feedback functionality [feedback], and * summary-LSA functionality [summary_lsa]." . I want to know whether cisco/juniper routers (standard ones) supports all of the above extension. or if not,how many.......or Whether router is supposed to support how many ... Regards, ---Sachin From owner-mpls@UU.NET Tue Dec 10 05:56: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 FAA03571 for ; Tue, 10 Dec 2002 05:56:40 -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 QQnspv17990 for ; Tue, 10 Dec 2002 10:59:29 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 QQnspv15673; Tue, 10 Dec 2002 10:58:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQnspv04859 for mpls-outgoing; Tue, 10 Dec 2002 10:57:50 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 QQnspv04854 for ; Tue, 10 Dec 2002 10:57:48 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 QQnspv26746 for ; Tue, 10 Dec 2002 10:57: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 QQnspv02233 for ; Tue, 10 Dec 2002 10:57:06 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 QQnspv02229 for ; Tue, 10 Dec 2002 10:57:06 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBAAvZCL017042 for ; Tue, 10 Dec 2002 05:57:35 -0500 (EST) 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 FAA07480 for ; Tue, 10 Dec 2002 05:57:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBAAv5n19685 for mpls@uu.net; Tue, 10 Dec 2002 05:57:05 -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 QQnspv04668 for ; Tue, 10 Dec 2002 10:56: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 QQnspv18838 for ; Tue, 10 Dec 2002 10:55:26 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 QQnspv14182 for ; Tue, 10 Dec 2002 10:55:25 GMT Received: from india-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: india-msg-core-1.cisco.com [64.104.129.221]) id QQnspv14174 for ; Tue, 10 Dec 2002 10:55:24 GMT Received: from cbin3-mira-01.cisco.com (localhost [127.0.0.1]) by india-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBAGO5u3029619; Tue, 10 Dec 2002 16:24:06 GMT Received: from cisco.com (absaxena-lnx.cisco.com [64.104.136.61]) by cbin3-mira-01.cisco.com (Mirapoint) with ESMTP id ADT43381; Tue, 10 Dec 2002 16:19:21 +0530 (IST) Message-ID: <3DF5C8F3.6060100@cisco.com> Date: Tue, 10 Dec 2002 16:28:59 +0530 From: Abhishek Saxena User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202 X-Accept-Language: en-us, en MIME-Version: 1.0 To: George Swallow CC: mpls@UU.NET Subject: Re: Last call on LSP Ping References: <200212032251.RAA01985@bifocal.cisco.com> In-Reply-To: <200212032251.RAA01985@bifocal.cisco.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 Hi, I was wondering why an IP header is required in the LSP ping packet. The information that we need to get the packet across to the egress LSR is simply the mpls label. The source IP address of this LSR is needed by the egress LSR to return the packet back. This is already there in the TLV. We can therefore have a UDPoMPLS kind of a setup in this case, with no IP header in the packet therefore preventing any IP routing at all for this packet. Does this make sense? Regards, - Abhishek George Swallow wrote: > This message begins a workgroup last call on: > > Detecting MPLS Data Plane Liveness > > draft-ietf-mpls-lsp-ping-01.txt > > The last call ends on Dec 16, 2002 2400H GMT. > > George & Loa > > ====================================================================== > George Swallow Cisco Systems (978) 497-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > > > > From owner-mpls@UU.NET Tue Dec 10 06:47: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 GAA04224 for ; Tue, 10 Dec 2002 06:47:03 -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 QQnspz26805 for ; Tue, 10 Dec 2002 11:49: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 QQnspz22874; Tue, 10 Dec 2002 11:47:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQnspz27177 for mpls-outgoing; Tue, 10 Dec 2002 11:47:10 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 QQnspz27168 for ; Tue, 10 Dec 2002 11:47: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 QQnspz21741 for ; Tue, 10 Dec 2002 11:46: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 QQnspz08615 for ; Tue, 10 Dec 2002 11:46: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 QQnspz08601 for ; Tue, 10 Dec 2002 11:46:06 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBABkZBM019645 for ; Tue, 10 Dec 2002 06:46:35 -0500 (EST) 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 GAA09286 for ; Tue, 10 Dec 2002 06:46:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBABk5623754 for mpls@uu.net; Tue, 10 Dec 2002 06:46:05 -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 QQnspz26900 for ; Tue, 10 Dec 2002 11:45:05 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 QQnspy15511 for ; Tue, 10 Dec 2002 11:44: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 QQnspy21490 for ; Tue, 10 Dec 2002 11:44:46 GMT Received: from sj-msg-core-4.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-4.cisco.com [171.71.163.54]) id QQnspy21478 for ; Tue, 10 Dec 2002 11:44:46 GMT Received: from asimha-u10.cisco.com (asimha-u10.cisco.com [64.102.48.65]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gBABijKv028050 for ; Tue, 10 Dec 2002 03:44:45 -0800 (PST) Received: (asimha@localhost) by asimha-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA01788 for mpls@UU.NET; Tue, 10 Dec 2002 06:44:45 -0500 (EST) Date: Tue, 10 Dec 2002 06:44:44 -0500 From: Ajay Simha To: mpls@UU.NET Subject: Record Object in LSP Ping Message-ID: <20021210114444.GL677@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-mpls@UU.NET Precedence: bulk Hi, Since the LSP Ping is meant for fault detection, does anyone see any value in adding a record route/label TLV to this? Each node can add (if requested) the label that the packet came in with, the label that this node imposed/swapped and it's LSR-ID. Thanks, -ajay From owner-mpls@UU.NET Tue Dec 10 08:44: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 IAA06167 for ; Tue, 10 Dec 2002 08:44: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 QQnsqh10666 for ; Tue, 10 Dec 2002 13:47:10 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 QQnsqh06387; Tue, 10 Dec 2002 13:45:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsqg12833 for mpls-outgoing; Tue, 10 Dec 2002 13:44: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 QQnsqg12828 for ; Tue, 10 Dec 2002 13:44: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 QQnsqg28283 for ; Tue, 10 Dec 2002 13:44:16 GMT From: neil.2.harrison@bt.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 QQnsqg05632 for ; Tue, 10 Dec 2002 13:44:16 GMT Received: from cbibipnt05.hc.bt.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQnsqg05605 for ; Tue, 10 Dec 2002 13:44:15 GMT Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Tue, 10 Dec 2002 13:43:46 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A35389014CFCE9@i2km07-ukbr.domain1.systemhost.net> To: curtis@fictitious.org Cc: Shahram_Davari@pmc-sierra.com, dallan@nortelnetworks.com, swallow@cisco.com, mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Tue, 10 Dec 2002 13:43:24 -0000 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 Thanks Curtis, please see below. regards, Neil Curtis Villamizar wrote 10 December 2002 03:33 > > NH=> I refer to the RSVP bit. If a pkt gets misdirected > and is requesting a > > return by the RSVP control-plane, then of course as you > rightly observe > > there has to be such a return control-plane path available. > But how is it > > possible that a pkt which is misdirected to some arbitrary > egress point will > > have a RSVP return path back to some fixed source point? > This appears not > > to be a sensible thing to assume. So this option (ie using > RSVP) does not > > appear to cater for the needs of identifying where > misdirected traffic ends > > up. > > I looked at this again and it appears I had this wrong. NH=> Yes, I agree it's not immediately obvious. And if you are having problems understanding all this think about how others must be finding it. > If the > "Downstream Mapping" was used to form a RESV, then this would be fine, > but it is not the case. > > In order to have *any* MPLS/TE LSP going to an adjacent router, there > must be an RSVP adjacency. The route up to the point where the path > went wrong is in the MPLS-ping packet payload if the "Downstream > Mapping" is present so the router could in principle send the packet > back hop by hop in RSVP. I was assuming that the "Downstream Mapping" > could be inverted but I see that the intent is to simply add the > LSP_ECHO in the normal RESV for the LSP. As is it is just a > continuity test. NH=> Agreed....that was precisely my point, ie this can only be used to detect breaks. My understanding of the intention of this mode was to resolve the break to either 'go' or 'return' directions (on the assumption that using an RSVP return path for comms is reliable since it indicates itself whether up/down). > > It seems that error indication on misdirected traffic is only possible > if IP routing is used to deliver the reply. NH=> Agreed, this was what I was driving at in my 2nd set of questions that I posed 5 Dec, and specifically Q6 therein. I am still waiting a response on all my postings.....to repeat that specific question: "6 In the same section......why is there an option to reply by the RSVP control-plane? What scenario is this addressing that the above (NH=> ie using IP only) doesn't? Further, some guidance on when to select which option would be useful." > > Even so, if the packet is misdirected, at some hop the packet arrives > at the wrong router. In traceroute mode you can determine when this > occurs and which router the traffic is being misdirected towards (if > IP can be used to return the packet). NH=> Yes. But you don't want to be running trace route continually IMO. Trace route should be available to run *after* a mismerging defect is detected as an ad hoc diagnostics tool. RSVP return option fails here as we have noted....hence I ask why bother with it? However, I am still unclear what happens wrt to setting the router alert option (to attempt to avoid LSP return paths?), esp in the case where the network is just LSPs and no IP (return) fowarding is possible (see Note). I also asked about this in my earlier 2nd posting in Q5....still no response, so here it is again: "5 In the same section.....can you please explain in a little more detail why there are 2 IPv4/UDP (and no v6??) reply modes, one without router alert set and one with router alert set? The text seems to indicate the latter is more reliable than the former." Note - IMO it's not architecturally correct to be asking a client (or server) layer network technology (any) or a signalling protocol (any, and should include the case of *none*, ie static provisioned) to be taking a critical role in the data-plane fault management of a layer network....here MPLS, though this principle is general to any layer network. However, I can't easily/simply see how we are going to crack the problems of merging in a co forwarding mode (ie mp2p) without breaking the architecture in some way. But let's try and keep the 'nifty hacks' to the minimum please and try and respect the layered architecture as far as possible. Let's also try and keep it simple. It would have helped if we had had some agreed requirements up front that we were shooting at. This was done for the p2p case in Y.1710 and then with the solutions in Y.1711....not only do these respect layered architectures but they are both very powerful and very simple. But they won't jive with the fault-management complexities mp2p throws up though, so we must keep working on this. From owner-mpls@UU.NET Tue Dec 10 09:01:33 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 JAA06451 for ; Tue, 10 Dec 2002 09:01:32 -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 QQnsqi05054 for ; Tue, 10 Dec 2002 14:04: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 QQnsqh25591; Tue, 10 Dec 2002 13:59:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsqh14126 for mpls-outgoing; Tue, 10 Dec 2002 13:59:11 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 QQnsqh14107 for ; Tue, 10 Dec 2002 13:59:09 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 QQnsqh14092 for ; Tue, 10 Dec 2002 13:57:33 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 QQnsqh21803 for ; Tue, 10 Dec 2002 13:57:32 GMT Received: from mail.cad.zju.edu.cn by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: cad.zju.edu.cn [210.32.131.2]) id QQnsqh21786 for ; Tue, 10 Dec 2002 13:57:31 GMT Received: (qmail 13150 invoked from network); 10 Dec 2002 14:03:33 -0000 Received: from unknown (HELO ultra1) (210.32.131.97) by 210.32.131.2 with SMTP; 10 Dec 2002 14:03:33 -0000 Received: from cad.zju.edu.cn (ultra1 [210.32.131.97]) by ultra1 (8.12.6/8.12.6) with ESMTP id gBADw2p1018831; Tue, 10 Dec 2002 21:58:07 +0800 (CST) Message-ID: <3DF5F2E9.8BE4DF71@cad.zju.edu.cn> Date: Tue, 10 Dec 2002 21:58:02 +0800 From: Jing Shen Reply-To: jshen@cad.zju.edu.cn Organization: State Key Lab of CAD&CG X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Eric Osborne CC: "Naidu, Venkata" , "J.C.Ramesh Babu" , mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: [MPLS-OPS]: Jitter and MPLS References: <39469E08BD83D411A3D900204840EC55763471@VIE-MSGUSR-01> <3DF48F65.840949E1@cad.zju.edu.cn> <20021209084638.D4090@eosborne-u10.cisco.com> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit We consider this with the following assumption: 1. it's nearly impossible for any user to negotiate a e2e bandwidth reservation for his/her accessing to some other site. The most possible solution is to set up e2e LSPs which service a group of people( this is to the situation of VPN or DiffServ-aware-TE ). Within the LSP, sessions share bandwidth reserved in a best-effort manner. 2. The network is increasing, and MPLS and IP will be the most possible technology used to carry content. 3. The underlying technology is the same (DWDM or the like), and the available physical bandwidth is the same. 4. Real-time multimedia application will be the main stream application. This means most of applications require high bandwidth. So, our experiments are set up to find out what's the essential part of MPLS networks if it's implemented on the same hardware platform. ( like that of upgrading IOS version). In order to focus on switch routing itself, we don't invoke techniques like TE in the experiments. And, we do the experiments between IP and MPLS with the same queueing mechanism, and the same packet classification mechanism. The experiment results shows, no matter how network is loaded, if e2e bandwidth reservation is done packets transferring LSP show smaller IPDV and a little higher e2e delay. As the testbed is very small, we take the reason as: MPLS decap/encap smooth packet's entering procedure into queue of outgoing interface. On the other hand, if no bandwidth reservation is done: if network is lightly loaded there is nearly no difference in e2e delay between IP routing and MPLS switching, while MPLS shows bettter in IPDV; if network is heavy loaded MPLS behaves worse in both aspects than IP does. As we know, the way to control jitter is smoothing packet transfer by controling queueing behavior, and we find the overhead of IP routing and MPLS switching is nearly the same. This means in our testbed MPLS's encap/decap introduces something good to jitter control. We extend the result to a path consisting multi-hop because middle-LSP could be considered a tunnel connecting LERs, and also it directly applies to LSPs consisting LERs. So, if e2e qos for individual connection is considered in MPLS network, it should take the LSP which pass a path as highly loaded as possible. From the discussion above, I come to know that implementation details do have effect on e2e performance, and commerical implementation of MPLS may introduce negelectable overhead in encap/decap overhead. But it exists and accumulated result will come up when network is heavy loaded. And, also delay/IPDV is affected by fluctuation in network, we consider we extend the instant we observe. Some other people says that we could smooth any problem by overprovisioning. But, a phenomenon of current network is: sometimes when a part of network is heavy loaded the adjacent part idles. Why shoudn't we make use of those idled resource ? regards > > On Mon, Dec 09, 2002 at 08:41:09PM +0800, Jing Shen wrote: > > It's main conclusion of our experiments that policy based routing must > > be used with MPLS if e2e QoS is considered carefully. > > Why? > > eric > -- Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, Z.J. 310027 P.R.China Tel: +86-571-87932423 Mobile: (0)13516813753 Email: jshen@cad.zju.edu.cn ********************************************************************** * The SunShine of life is made up of very little beams which is * * bright all the time * ********************************************************************** From owner-mpls@UU.NET Tue Dec 10 09:08: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 JAA06615 for ; Tue, 10 Dec 2002 09:08:16 -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 QQnsqi07622 for ; Tue, 10 Dec 2002 14:11: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 QQnsqi05734; Tue, 10 Dec 2002 14:10:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsqi02771 for mpls-outgoing; Tue, 10 Dec 2002 14:09:51 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 QQnsqi02759 for ; Tue, 10 Dec 2002 14:09:46 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 QQnsqi16523 for ; Tue, 10 Dec 2002 14:09:30 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 QQnsqi03608 for ; Tue, 10 Dec 2002 14:09:29 GMT Received: from mail.cad.zju.edu.cn by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: cad.zju.edu.cn [210.32.131.2]) id QQnsqi03593 for ; Tue, 10 Dec 2002 14:09:28 GMT Received: (qmail 13335 invoked from network); 10 Dec 2002 14:15:27 -0000 Received: from unknown (HELO ultra1) (210.32.131.97) by 210.32.131.2 with SMTP; 10 Dec 2002 14:15:27 -0000 Received: from cad.zju.edu.cn (ultra1 [210.32.131.97]) by ultra1 (8.12.6/8.12.6) with ESMTP id gBAE9tp1018839; Tue, 10 Dec 2002 22:10:00 +0800 (CST) Message-ID: <3DF5F5B3.BEBD41D4@cad.zju.edu.cn> Date: Tue, 10 Dec 2002 22:09:55 +0800 From: Jing Shen Reply-To: jshen@cad.zju.edu.cn Organization: State Key Lab of CAD&CG X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: curtis@fictitious.org CC: "Naidu, Venkata" , Eric Osborne , "J.C.Ramesh Babu" , mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: [MPLS-OPS]: Jitter and MPLS References: <200212091635.LAA35389@workhorse.fictitious.org> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis, > > In message <3DF48F65.840949E1@cad.zju.edu.cn>, Jing Shen writes: > > > > OMP gives a good start on traffic engineering but its traffic division > > policy is too simple for self-similar internet traffic. > > I don't see any basis for this assertion. > > The IP src/dst hash is used almost universally in ECMP for OSPF, ISIS, > LDP (after payload snooping consistently indicates that payload is > IP), and MPLS/TE implementations (when L3PID indicates IP traffic), as > well as in proprietary link bundling (for example: Avici Composite > Links (tm) and others). It works very well with Internet traffic. > First of all, I take OMP is very good start in trying to make use of idled network resource. And it shows good performance in simulation and the academic testbed you mentioned. We take multipath routing is the way to make full use of network resource and traffic dispersion should be done according to the state of network but not the the src/dst hash function. The reason is, network load is not symetricly distributed and LRD is the built-in properties. So, even there exists multiple equal cost path between any src-dst pair hash based traffic division will not lead to a balanced network usage as well as guaranteeing e2e qos. > > I have another question, is OMP implemented in some commerical products? > > if not, why? > > There have been a few research implementations that have come to my > attention, mostly grad student projects. > > Implementing in a commercial router is a much larger undertaking due > to added complexity (forwarding cards are separate from router > processors, more is done in hardware or microcode, 100s or 1000s of > interfaces pose greater scaling challenges, etc) and the software > quality requirements. Without a customer expressing strong interest > this hasn't happenned. > Thanks for the verification. I think this is for the same reason that the network is usually overprovisioned, so people take it enough. if there is something wrong correct me please. -- Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, Z.J. 310027 P.R.China ********************************************************************** * The SunShine of life is made up of very little beams which is * * bright all the time * ********************************************************************** From owner-mpls@UU.NET Tue Dec 10 09:14: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 JAA06744 for ; Tue, 10 Dec 2002 09:14:17 -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 QQnsqj19499 for ; Tue, 10 Dec 2002 14:17:06 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 QQnsqj15459; Tue, 10 Dec 2002 14:15:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsqi03902 for mpls-outgoing; Tue, 10 Dec 2002 14:14: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 QQnsqi03871 for ; Tue, 10 Dec 2002 14:14:23 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 QQnsqi27262 for ; Tue, 10 Dec 2002 14:13: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 QQnsqi12767 for ; Tue, 10 Dec 2002 14:13:35 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 QQnsqi12254 for ; Tue, 10 Dec 2002 14:13:21 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBAEDaJo001913 for ; Tue, 10 Dec 2002 09:13:37 -0500 (EST) 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 JAA15906 for ; Tue, 10 Dec 2002 09:13:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBAED6H04048 for mpls@uu.net; Tue, 10 Dec 2002 09:13:06 -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 QQnsqi03496 for ; Tue, 10 Dec 2002 14:11:34 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 QQnsqi20475 for ; Tue, 10 Dec 2002 14:11:01 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 QQnsqi04977 for ; Tue, 10 Dec 2002 14:11:00 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 QQnsqi04956 for ; Tue, 10 Dec 2002 14:10:59 GMT Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBAE9QFY022337; Tue, 10 Dec 2002 15:09:26 +0100 (MET) Received: from JVASSEUR-W2K.cisco.com (sjc-vpn2-571.cisco.com [10.21.114.59]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id PAA17397; Tue, 10 Dec 2002 15:10:47 +0100 (MET) Message-Id: <4.3.2.7.2.20021210090846.06284110@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 10 Dec 2002 09:10:45 -0500 To: "sachin laddha" From: Jean Philippe Vasseur Subject: Re: Multi-Area TE Protocol Extensions Cc: In-Reply-To: <000d01c2a025$6fe04cc0$2d3fa8c0@itpl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, At 13:53 10/12/2002 +0530, sachin laddha wrote: >Hi, >'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as >"Initial requirements are given here for protocol support of the multi-area >TE methods, which include needs to support > >* path-computation-server (PCS) functionality [kompella, lee, vasseur, >te-qos-routing], >* query functionality [query, vasseur], >* crankback functionality [crankback], > >and, optionally, > >* TE feedback functionality [feedback], and >* summary-LSA functionality [summary_lsa]." >. >I want to know whether cisco/juniper routers (standard ones) supports all of >the above extension. >or if not,how many.......or Whether router is supposed to support how many >... I do not think any vendor supports all the method mentioned above, but just a subset. If you are running a network, your feed-backs on your preferred method is very welcome. JP. >Regards, >---Sachin From owner-mpls@UU.NET Tue Dec 10 10:39:20 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 KAA10811 for ; Tue, 10 Dec 2002 10:39:20 -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 QQnsqo00223 for ; Tue, 10 Dec 2002 15:42: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 QQnsqo15016; Tue, 10 Dec 2002 15:35:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsqo29509 for mpls-outgoing; Tue, 10 Dec 2002 15:34: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 QQnsqo29500 for ; Tue, 10 Dec 2002 15:34:19 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 QQnsqo27991 for ; Tue, 10 Dec 2002 15:34:09 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 QQnsqo29938 for ; Tue, 10 Dec 2002 15:34:08 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 QQnsqo29934 for ; Tue, 10 Dec 2002 15:34:08 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBAFYa8U014282 for ; Tue, 10 Dec 2002 10:34:36 -0500 (EST) 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 KAA21902 for ; Tue, 10 Dec 2002 10:34:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBAFY6d10958 for mpls@uu.net; Tue, 10 Dec 2002 10:34:06 -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 QQnsqo29428 for ; Tue, 10 Dec 2002 15:33:02 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 QQnsqo27854 for ; Tue, 10 Dec 2002 15:32: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 QQnsqo28876 for ; Tue, 10 Dec 2002 15:32:56 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 QQnsqo28867 for ; Tue, 10 Dec 2002 15:32:56 GMT Received: (qmail 11726 invoked by uid 104); 10 Dec 2002 15:32:52 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4236. . Clean. Processed in 0.870398 secs); 10 Dec 2002 15:32:52 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 10 Dec 2002 15:32:50 -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 gBAFWiQ21240; Tue, 10 Dec 2002 07:32:45 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Tue, 10 Dec 2002 07:32:44 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B6F@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Abhishek Saxena'" , George Swallow Cc: mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Tue, 10 Dec 2002 07:32:42 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Since MPLS label has no protocol ID field, either an IP header (for IP carrying LSPs) or a reserved label (for non-IP carrying LSPs) is required to identify the protocol. -Shahram > -----Original Message----- > From: Abhishek Saxena [mailto:absaxena@cisco.com] > Sent: Tuesday, December 10, 2002 5:59 AM > To: George Swallow > Cc: mpls@UU.NET > Subject: Re: Last call on LSP Ping > > > Hi, > > I was wondering why an IP header is required in the LSP ping > packet. The > information that we need to get the packet across to the > egress LSR is > simply the mpls label. The source IP address of this LSR is needed by > the egress LSR to return the packet back. This is already > there in the > TLV. We can therefore have a UDPoMPLS kind of a setup in this > case, with > no IP header in the packet therefore preventing any IP routing at all > for this packet. > > Does this make sense? > > Regards, > - Abhishek > > George Swallow wrote: > > This message begins a workgroup last call on: > > > > Detecting MPLS Data Plane Liveness > > > > draft-ietf-mpls-lsp-ping-01.txt > > > > The last call ends on Dec 16, 2002 2400H GMT. > > > > George & Loa > > > > > ====================================================================== > > George Swallow Cisco Systems > (978) 497-8143 > > 250 Apollo Drive > > Chelmsford, Ma 01824 > > > > > > > > > > From owner-mpls@UU.NET Tue Dec 10 10:40:14 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 KAA10840 for ; Tue, 10 Dec 2002 10:40:14 -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 QQnsqo02426 for ; Tue, 10 Dec 2002 15:43: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 QQnsqo15002; Tue, 10 Dec 2002 15:35:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsqo29514 for mpls-outgoing; Tue, 10 Dec 2002 15:34: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 QQnsqo29502 for ; Tue, 10 Dec 2002 15:34:21 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 QQnsqo27046 for ; Tue, 10 Dec 2002 15:33:46 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 QQnsqo13626 for ; Tue, 10 Dec 2002 15:33:46 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 QQnsqo13618 for ; Tue, 10 Dec 2002 15:33:45 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Dec 2002 10:33:45 -0500 Message-ID: <1117F7D44159934FB116E36F4ABF221B0267ED69@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'curtis@fictitious.org'" Cc: mpls@UU.NET Subject: RE: Last call on LSP Ping - ECMP thread (continued) Date: Tue, 10 Dec 2002 10:33:41 -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, It seems I'm going have to make one more attempt to clarify this discussion, after which I may not bother to continue. Please do not make the assumption that a lack of response from me in the future is an indication of agreement. :-) Just to be perfectly clear, what you are saying is that - if you were making a purchase decision, you would hand the vendor in question a copy of a readily available Informational RFC entitled "Analysis of an Equal-Cost Multi-Path Algorithm" and tell them to implement that? You should note a few things about this RFC: o it uses "... an ..." in the title (implying acknowlgement that other approaches exist and are not included in the analysis); o it does not specify a particular hash function (author's choice to use the word specify, not mine); o it makes a comparison between the general idea of using a hash key and such time honored ECMP approaches as "Round Robin" and "Random Choice" (rather than comparing various choices of hash functions); o it lists some specific ways that one might use to establish hash thresholds (no one of which is used to the exclusion of all others today); o it seems to lead the reader to conclude that the general idea of using a hash key based on packet header fields that identify a flow is a good one; o it informs the reader of engineering trade-offs involved. Entirely aside from the fact this very useful information is obvious to people who implement routers, it does not require anything that is not included in what I suggested. Nor is the fact you hand an implementer that RFC going to change choices they have already made based on considerations very similar (if not identical) to the engineering trade-offs the RFC describes. Those choices may have been driven by a number of factors, but it is certainly late in the process for them to change their choices once they have completed an implementation. Presumably, there are customer-related considerations to be taken into account beyond a value judgment as to what constitutes a "good hash" or what is easy in some implementations. Finally, the use of IP header fields in LSP-based ECMP is far from an established practice. Based on your own earlier assertions with respect to when it would be appropriate (after determining that an individual flow is in fact an IP flow), the approach is not scalable. Therefore, an IP destination based approach to ping-ing equal cost paths is (as I said earlier) misleading and most likely not useful. The LSP Ping draft should define a specific address to be used as the default IP destination address, rather than a range. As I now understand it (you still have not, AFAIK, sent the message that contains all the parts of your suggestion), your suggestion to provide a mechanism to allow an intermediate node to suggest addresses that would test all equal cost paths would work. I would not have a problem with picking those addresses from the 127/8 range, as long as a single address (127.0.0.1) is stated as the default in lieu of a suggested address. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 > [...] > > > > > The normal HASH is over a 64 bit quantity. ... > > > > Again, this is an assertion though how anyone might > > determine what the "normal" hash algorithms might include > > is beyond me. > > It comes from a bit over a decade working in Internet operations and > in IP protocol development and experience with a large number of > routers. Plus it is documented in RFC 2992. > > 2992 Analysis of an Equal-Cost Multi-Path Algorithm. C. Hopps. > November 2000. (Format: TXT=17524 bytes) (Status: INFORMATIONAL) > > I think that justifies the assertion. > > ... > > > > If there is a router that does ECMP and uses an IP hash that doesn't > > > include the lower 24 bits, I'd be really surprised. I don't think > > > such a thing exists or that there is any good reason to build such a > > > thing and therefore your objection has no merit. > > > > Then you should be prepared to be surprised. In > > general, it is sufficient to group flows using either a > > source or a destination IP address based hash. Further, > > it is of some importance to use a range of algorithms, or > > (non-exclusive) a variation of key sources/patterns so > > that it is possible for the same source and destination > > to map to a different has key at different places in the > > network. Finally, it is very important to keep the hash > > algorithms simple. > > That is the purpose of the random key to the hash, periodically > updated (very long interval). > > > Consequently, it is possible that you may discover > > that some schemes use only a small-ish set of bits from > > either the source or destination IP address, depending > > on the location of the device, and the direction of packet > > flow, relative to the network core. Even if the entire > > 64 bits of source and destination IP address is injected > > into some algorithms, it is possible that steps in the > > algorithms themselves may ignore some of those bits. > > A good hash does not ignore any of the bits. > > > If you believe that my objection still has no merit, > > then we are unlikely to find common ground for further > > discussion - at least with respect to this issue. > > Can you please name such a router. I know it is not Cisco, Juniper, > or Avici. Nor the old Bay routers, or Ironbridge, or Pluris or the > former Argon. Some of the newer edge boxes may have done this. If > so, can you please name one? > > ... > > Such a router would be quite broken not because MPLS-ping wouldn't > work but the oad split wouldn't be very good. If making a purchasing > decision, I'd hand the maker a copy of RFC2992 and wait for them to > fix the routers or go elsewhere. > > ... > > > > I thought I just did propose something (not in the attached message > > > but in a prior message) that unlike what you state above requires no > > > change to forwarding. It requires only a change in MPLS TTL expired > > > processing if the payload is MPLS-ping (which is already required). > > > It is really spread over three messages. Do I need to resend it in > > > one message? > > > > Either that, or point out which three messages. > > > I'll just resend them as one. > > Curtis > > > > Eric W. Gray > > Systems Architect > > Celox Networks, Inc. > > egray@celoxnetworks.com > > 508 305 7214 From owner-mpls@UU.NET Tue Dec 10 10:46: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 KAA11038 for ; Tue, 10 Dec 2002 10:46: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 QQnsqp19369 for ; Tue, 10 Dec 2002 15:49: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 QQnsqp15453; Tue, 10 Dec 2002 15:47:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsqp00749 for mpls-outgoing; Tue, 10 Dec 2002 15:46:40 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 QQnsqp00736 for ; Tue, 10 Dec 2002 15:46:31 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 QQnsqp06249 for ; Tue, 10 Dec 2002 15:45: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 QQnsqp13640 for ; Tue, 10 Dec 2002 15:45:38 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 QQnsqp13627 for ; Tue, 10 Dec 2002 15:45:38 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBAFk6MT016172 for ; Tue, 10 Dec 2002 10:46:07 -0500 (EST) 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 KAA22807 for ; Tue, 10 Dec 2002 10:45:36 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBAFjaP13137 for mpls@uu.net; Tue, 10 Dec 2002 10:45:36 -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 QQnsqo00248 for ; Tue, 10 Dec 2002 15:44: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 QQnsqo24122 for ; Tue, 10 Dec 2002 15:43: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 QQnsqo11612 for ; Tue, 10 Dec 2002 15:43:58 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 QQnsqo11598 for ; Tue, 10 Dec 2002 15:43:58 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBAFgU7D015613; Tue, 10 Dec 2002 10:42:34 -0500 (EST) Received: from eosborne-u10.cisco.com (eosborne-u10.cisco.com [161.44.134.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA22499; Tue, 10 Dec 2002 10:41:56 -0500 (EST) Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA06135; Tue, 10 Dec 2002 10:41:56 -0500 (EST) Date: Tue, 10 Dec 2002 10:41:56 -0500 From: Eric Osborne To: Jing Shen Cc: Eric Osborne , "Naidu, Venkata" , "J.C.Ramesh Babu" , mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: [MPLS-OPS]: Jitter and MPLS Message-ID: <20021210104155.B6118@eosborne-u10.cisco.com> References: <39469E08BD83D411A3D900204840EC55763471@VIE-MSGUSR-01> <3DF48F65.840949E1@cad.zju.edu.cn> <20021209084638.D4090@eosborne-u10.cisco.com> <3DF5F2E9.8BE4DF71@cad.zju.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3DF5F2E9.8BE4DF71@cad.zju.edu.cn>; from jshen@cad.zju.edu.cn on Tue, Dec 10, 2002 at 09:58:02PM +0800 X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk > So, our experiments are set up to find out what's the essential > part of MPLS networks if it's implemented on the same hardware > platform. ( like that of upgrading IOS version). In order to focus > on switch routing itself, we don't invoke techniques like TE in > the experiments. And, we do the experiments between IP and MPLS with > the same queueing mechanism, and the same packet classification > mechanism. > > The experiment results shows, no matter how network is loaded, > if e2e bandwidth reservation is done packets transferring LSP show > smaller IPDV and a little higher e2e delay. As the testbed is very > small, we take the reason as: MPLS decap/encap smooth packet's entering > procedure into queue of outgoing interface. ok. good. great. fine. but you're testing a specific implementation. it may be yours, it may be mine, it may be someone else's. but any ipdv and other such performance characteristics are not that of the mpls architecture, but of the implementation you're testing. I'm not sure if you agree with me or not, can you please confirm that you do or don't? > > On the other hand, if no bandwidth reservation is done: if network > is lightly loaded there is nearly no difference in e2e delay between > IP routing and MPLS switching, while MPLS shows bettter in IPDV; > if network is heavy loaded MPLS behaves worse in both aspects than > IP does. As we know, the way to control jitter is smoothing packet > transfer > by controling queueing behavior, and we find the overhead of IP routing > and MPLS switching is nearly the same. This means in our testbed MPLS's > encap/decap introduces something good to jitter control. > MPLS encap/decap changing delay/jitter characteristics for better or worse is a byproduct of the implementation. > We extend the result to a path consisting multi-hop because middle-LSP > could be considered a tunnel connecting LERs, and also it directly > applies to LSPs consisting LERs. So, if e2e qos for individual > connection > is considered in MPLS network, it should take the LSP which pass a path > as highly loaded as possible. > I don't get this. If you want qos, surely you want to strive for low-load paths? > >From the discussion above, I come to know that implementation details > do have effect on e2e performance, and commerical implementation > of MPLS may introduce negelectable overhead in encap/decap overhead. > But it exists and accumulated result will come up when network is heavy > loaded. > Yes, it exists, but it _depends on the implementation_. > And, also delay/IPDV is affected by fluctuation in network, we consider > we extend the instant we observe. > > Some other people says that we could smooth any problem by > overprovisioning. > But, a phenomenon of current network is: sometimes when a part of > network > is heavy loaded the adjacent part idles. Why shoudn't we make use of > those idled resource ? I agree. What does any of this have to do with policy routing, as you state below? Why do you give the impression that policy routing is only necessary for MPLS networks, and not IP? What, for that matter, is policy routing? I know what I think it is, but that's because we happen to implement a feature called "policy-based routing". I have no idea whether this is what you refer to or not. Also, if you continue to insist on confusing architecture with implementation, you may want to remember that a policy routing implementation will probably have adverse effects on delay/jitter, as there's generally more work involved in policy-routing a packet than in normal routing or switching or whatever of the same packet. eric > > regards > > > > > > > > On Mon, Dec 09, 2002 at 08:41:09PM +0800, Jing Shen wrote: > > > It's main conclusion of our experiments that policy based routing must > > > be used with MPLS if e2e QoS is considered carefully. > > > > Why? > > > > eric > > > > -- > Jing Shen > > State Key Lab of CAD&CG > ZheJiang University(YuQuan) > HangZhou, Z.J. 310027 > P.R.China > > Tel: +86-571-87932423 > Mobile: (0)13516813753 > Email: jshen@cad.zju.edu.cn > > ********************************************************************** > * The SunShine of life is made up of very little beams which is * > * bright all the time * > ********************************************************************** From owner-mpls@UU.NET Tue Dec 10 10:58: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 KAA11364 for ; Tue, 10 Dec 2002 10:58:38 -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 QQnsqq22077 for ; Tue, 10 Dec 2002 16:01:20 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 QQnsqp14825; Tue, 10 Dec 2002 15:57:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsqp01738 for mpls-outgoing; Tue, 10 Dec 2002 15:57: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 QQnsqp01724 for ; Tue, 10 Dec 2002 15:57:14 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 QQnsqp00597 for ; Tue, 10 Dec 2002 15:57: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 QQnsqp00121 for ; Tue, 10 Dec 2002 15:57:12 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 QQnsqp00117 for ; Tue, 10 Dec 2002 15:57:12 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBAFvejx018109 for ; Tue, 10 Dec 2002 10:57:41 -0500 (EST) 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 KAA23769 for ; Tue, 10 Dec 2002 10:57:10 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBAFvA115784 for mpls@uu.net; Tue, 10 Dec 2002 10:57:10 -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 QQnsqp01691 for ; Tue, 10 Dec 2002 15:56:41 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 QQnsqp08729 for ; Tue, 10 Dec 2002 15:55:38 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 QQnsqp21691 for ; Tue, 10 Dec 2002 15:55:37 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 QQnsqp21674 for ; Tue, 10 Dec 2002 15:55: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 KAA40637; Tue, 10 Dec 2002 10:52:05 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212101552.KAA40637@workhorse.fictitious.org> To: neil.2.harrison@bt.com cc: curtis@fictitious.org, Shahram_Davari@pmc-sierra.com, dallan@nortelnetworks.com, swallow@cisco.com, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Tue, 10 Dec 2002 13:43:24 GMT." <0536FC9B908BEC4597EE721BE6A35389014CFCE9@i2km07-ukbr.domain1.systemhost.net> Date: Tue, 10 Dec 2002 10:52:04 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <0536FC9B908BEC4597EE721BE6A35389014CFCE9@i2km07-ukbr.domain1.system host.net>, neil.2.harrison@bt.com writes: > > > > I looked at this again and it appears I had this wrong. > NH=> Yes, I agree it's not immediately obvious. And if you are having > problems understanding all this think about how others must be finding it. It was clearly written. I didn't bother to read this part carefully enough. Lets put the blame where it belongs. > > If the > > "Downstream Mapping" was used to form a RESV, then this would be fine, > > but it is not the case. > > > > In order to have *any* MPLS/TE LSP going to an adjacent router, there > > must be an RSVP adjacency. The route up to the point where the path > > went wrong is in the MPLS-ping packet payload if the "Downstream > > Mapping" is present so the router could in principle send the packet > > back hop by hop in RSVP. I was assuming that the "Downstream Mapping" > > could be inverted but I see that the intent is to simply add the > > LSP_ECHO in the normal RESV for the LSP. As is it is just a > > continuity test. > NH=> Agreed....that was precisely my point, ie this can only be used to > detect breaks. My understanding of the intention of this mode was to > resolve the break to either 'go' or 'return' directions (on the assumption > that using an RSVP return path for comms is reliable since it indicates > itself whether up/down). > > > > It seems that error indication on misdirected traffic is only possible > > if IP routing is used to deliver the reply. > NH=> Agreed, this was what I was driving at in my 2nd set of questions that > I posed 5 Dec, and specifically Q6 therein. I am still waiting a response > on all my postings.....to repeat that specific question: > "6 In the same section......why is there an option to reply by the RSVP > control-plane? What scenario is this addressing that the above (NH=> ie > using IP only) doesn't? Further, some guidance on when to select which > option would be useful." I wouldn't mind getting rid of this. C&W (for example) has talked about running a no-IP routing core with MPLS over it. I think this is a very bad idea. It is speculative on my part but I think someone is either directly driving this or it was added to head off any objections that might arise. I thought you were one that insisted on a means to decouple diagnostics from an IP control plane. Maybe I'm mistaken. > > Even so, if the packet is misdirected, at some hop the packet arrives > > at the wrong router. In traceroute mode you can determine when this > > occurs and which router the traffic is being misdirected towards (if > > IP can be used to return the packet). > NH=> Yes. But you don't want to be running trace route continually IMO. > Trace route should be available to run *after* a mismerging defect is > detected as an ad hoc diagnostics tool. RSVP return option fails here as we > have noted....hence I ask why bother with it? However, I am still unclear > what happens wrt to setting the router alert option (to attempt to avoid LSP > return paths?), esp in the case where the network is just LSPs and no IP > (return) fowarding is possible (see Note). I also asked about this in my > earlier 2nd posting in Q5....still no response, so here it is again: > "5 In the same section.....can you please explain in a little more > detail why there are 2 IPv4/UDP (and no v6??) reply modes, one without > router alert set and one with router alert set? The text seems to indicate > the latter is more reliable than the former." If the continuity test fails, it would make sense to run traceroute. If a fault has occurred that is not due to an error that is evident in the control plane, then this would point to where the error is. > Note - IMO it's not architecturally correct to be asking a client (or > server) layer network technology (any) or a signalling protocol (any, and > should include the case of *none*, ie static provisioned) to be taking a > critical role in the data-plane fault management of a layer network....here > MPLS, though this principle is general to any layer network. However, I > can't easily/simply see how we are going to crack the problems of merging in > a co forwarding mode (ie mp2p) without breaking the architecture in some > way. But let's try and keep the 'nifty hacks' to the minimum please and try > and respect the layered architecture as far as possible. Let's also try and > keep it simple. It would have helped if we had had some agreed requirements > up front that we were shooting at. This was done for the p2p case in Y.1710 > and then with the solutions in Y.1711....not only do these respect layered > architectures but they are both very powerful and very simple. But they > won't jive with the fault-management complexities mp2p throws up though, so > we must keep working on this. > Implementation is greatly simplified by putting most of the fault management smarts at the application layer. Lets just agree to disagree about what is a nifty hack. I'll be sending a mesage on ECMP shortly. Please feel free to comment then. Curtis From owner-mpls@UU.NET Tue Dec 10 11:24:56 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 LAA12340 for ; Tue, 10 Dec 2002 11:24:56 -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 QQnsqr04676 for ; Tue, 10 Dec 2002 16:27: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 QQnsqr00495; Tue, 10 Dec 2002 16:25:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsqr22542 for mpls-outgoing; Tue, 10 Dec 2002 16:24: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 QQnsqr22534 for ; Tue, 10 Dec 2002 16:24:56 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 QQnsqr03932 for ; Tue, 10 Dec 2002 16:24:24 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 QQnsqr29602 for ; Tue, 10 Dec 2002 16:24:24 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 QQnsqr29596 for ; Tue, 10 Dec 2002 16:24:24 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBAGOqI3022756 for ; Tue, 10 Dec 2002 11:24:53 -0500 (EST) 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 LAA26088 for ; Tue, 10 Dec 2002 11:24:22 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBAGOM418980 for mpls@uu.net; Tue, 10 Dec 2002 11:24:22 -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 QQnsqr22487 for ; Tue, 10 Dec 2002 16:23:04 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 QQnsqr16688 for ; Tue, 10 Dec 2002 16:22: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 QQnsqr15547 for ; Tue, 10 Dec 2002 16:22:26 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 QQnsqr15525 for ; Tue, 10 Dec 2002 16:22:24 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 LAA40715; Tue, 10 Dec 2002 11:20:24 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212101620.LAA40715@workhorse.fictitious.org> To: "Gray, Eric" cc: "'curtis@fictitious.org'" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping - ECMP thread (continued) In-reply-to: Your message of "Tue, 10 Dec 2002 10:33:41 EST." <1117F7D44159934FB116E36F4ABF221B0267ED69@celox-ma1-ems1.celoxnetworks.com> Date: Tue, 10 Dec 2002 11:20:24 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <1117F7D44159934FB116E36F4ABF221B0267ED69@celox-ma1-ems1.celoxnetwor ks.com>, "Gray, Eric" writes: > > It seems I'm going have to make one more attempt to clarify > this discussion, after which I may not bother to continue. Please > do not make the assumption that a lack of response from me in the > future is an indication of agreement. :-) This is noted. > Just to be perfectly clear, what you are saying is that - if > you were making a purchase decision, you would hand the vendor in > question a copy of a readily available Informational RFC entitled > "Analysis of an Equal-Cost Multi-Path Algorithm" and tell them to > implement that? You should note a few things about this RFC: > > o it uses "... an ..." in the title (implying acknowlgement > that other approaches exist and are not included in the > analysis); > o it does not specify a particular hash function (author's > choice to use the word specify, not mine); > o it makes a comparison between the general idea of using a > hash key and such time honored ECMP approaches as "Round > Robin" and "Random Choice" (rather than comparing various > choices of hash functions); > o it lists some specific ways that one might use to establish > hash thresholds (no one of which is used to the exclusion > of all others today); > o it seems to lead the reader to conclude that the general > idea of using a hash key based on packet header fields that > identify a flow is a good one; > o it informs the reader of engineering trade-offs involved. > > Entirely aside from the fact this very useful information > is obvious to people who implement routers, it does not require > anything that is not included in what I suggested. Nor is the > fact you hand an implementer that RFC going to change choices > they have already made based on considerations very similar (if > not identical) to the engineering trade-offs the RFC describes. > Those choices may have been driven by a number of factors, but > it is certainly late in the process for them to change their > choices once they have completed an implementation. This is informational and points to some requirements. It is not normative, but if a router doesn't meet the requirements the consequences (microflow reorder or poor load split) are clear and ample indication of how to avoid this is given. requirements: 1. Any multipath implementation must avoid reordering microflows. 2. Some algorithms split traffic better than others. Using the whole address rather than part of it still doesn't split microflows and balances load better. 3. Some algorithms produce a delay discontinuity for less microflows when a new member is added or deleted. The third criteria in RFC2991 is ignored by current practice. key points: 1. Per packet (send every other packet to a different interface) load split reorders the packets within microflows and is bad. [This also impacts L2VPN if reordering at egress is unsupported.] 2. The granularity of per IP perfix load split is too coarse and the resulting load split can be terrible. For example, all traffic to 18/8 (MIT) going to one interface might make for a very uneven load split on a Boston circuit. Current practice dates back to the late 1980s, possible earlier, when the PC-RT based T1-NSFNET routers did multipath by src/dst based hash. The method of hash and modulo or a specific hash designed to produce an even distribution over a number range has been used by numerous routers including current Cisco, Juniper, and Avici products, and I'm sure others. I mentioned before Bay, Pluris, Argon, Ironbridge, all used similar techniques. > Presumably, there are customer-related considerations to be > taken into account beyond a value judgment as to what constitutes > a "good hash" or what is easy in some implementations. Could you please give a criteria for a "good hash" that you feel might be applicable to real networks and might lead to a different decision on what algorithm to use. In other words what should the algorithm be doing differently. [You already indicated you may not respond.] > Finally, the use of IP header fields in LSP-based ECMP is > far from an established practice. Based on your own earlier > assertions with respect to when it would be appropriate (after > determining that an individual flow is in fact an IP flow), the > approach is not scalable. Therefore, an IP destination based > approach to ping-ing equal cost paths is (as I said earlier) > misleading and most likely not useful. This I will entirely agree on. I still owe you the concatenated response on multipath where I will very willingly acknowledge that multipath support varies. > The LSP Ping draft should define a specific address to be > used as the default IP destination address, rather than a range. > As I now understand it (you still have not, AFAIK, sent the message > that contains all the parts of your suggestion), your suggestion > to provide a mechanism to allow an intermediate node to suggest > addresses that would test all equal cost paths would work. I > would not have a problem with picking those addresses from the > 127/8 range, as long as a single address (127.0.0.1) is stated > as the default in lieu of a suggested address. Again. Details to follow shortly. The range is needed. > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 Curtis From owner-mpls@UU.NET Tue Dec 10 11:42: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 LAA12840 for ; Tue, 10 Dec 2002 11:42:04 -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 QQnsqs25372 for ; Tue, 10 Dec 2002 16:44: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 QQnsqs21505; Tue, 10 Dec 2002 16:43:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsqs24207 for mpls-outgoing; Tue, 10 Dec 2002 16:42: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 QQnsqs24194 for ; Tue, 10 Dec 2002 16:42: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 QQnsqs25851 for ; Tue, 10 Dec 2002 16:42:06 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 QQnsqs13900 for ; Tue, 10 Dec 2002 16:42:06 GMT Received: from mail.alcatel.be by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc250.alcatel.be [195.207.101.250]) id QQnsqs13891 for ; Tue, 10 Dec 2002 16:42:05 GMT Received: from bemail05.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id gBAGfjr24897; Tue, 10 Dec 2002 17:41:46 +0100 Received: from alcatel.be ([138.203.67.228]) by bemail05.net.alcatel.be (Lotus Domino Release 5.0.9a) with ESMTP id 2002121017414480:4896 ; Tue, 10 Dec 2002 17:41:44 +0100 Message-ID: <3DF61A35.7BE9B01E@alcatel.be> Date: Tue, 10 Dec 2002 17:45:41 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: Optical Network Architecture (NTA - Antwerpen) X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jean Philippe Vasseur Cc: sachin laddha , mpls@UU.NET Subject: Re: Multi-Area TE Protocol Extensions References: <4.3.2.7.2.20021210090846.06284110@paris.cisco.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.9a |January 7, 2002) at 12/10/2002 17:41:44, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.9a |January 7, 2002) at 12/10/2002 17:41:45, Serialize complete at 12/10/2002 17:41:45 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit jp, in fact the below list should simply be as follows for signalling-based methods: 1) constraint-passing 2) loose routing and 3) path query; and the for constraint-passing we have a several i-d's such as, http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclude-route-01.txt constraint passing may also be extended using the crank- back as listed below; the usage scenarios of these methods are described in the following: http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-03.txt now probably it is worth spending some time in considering input coming from the tewg wrt to this effort, most of the input that you see listed above has been produced over the past year (and more) i can't imagine stepping in the protocol details without a clear consensus on what do we want to cover within the ccamp wg & w/o taking into account the tewg rec's (probably better to discuss this on the ccamp mailing list) thanks, - dimitri. Jean Philippe Vasseur wrote: > > Hi, > > At 13:53 10/12/2002 +0530, sachin laddha wrote: > >Hi, > >'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as > >"Initial requirements are given here for protocol support of the multi-area > >TE methods, which include needs to support > > > >* path-computation-server (PCS) functionality [kompella, lee, vasseur, > >te-qos-routing], > >* query functionality [query, vasseur], > >* crankback functionality [crankback], > > > >and, optionally, > > > >* TE feedback functionality [feedback], and > >* summary-LSA functionality [summary_lsa]." > >. > >I want to know whether cisco/juniper routers (standard ones) supports all of > >the above extension. > >or if not,how many.......or Whether router is supposed to support how many > >... > > I do not think any vendor supports all the method mentioned above, but just > a subset. If you are running a network, your feed-backs on your preferred > method is very welcome. > > JP. > > >Regards, > >---Sachin -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : Work: +32 3 2408491 - Home: +32 2 3434361 From owner-mpls@UU.NET Tue Dec 10 12:21:32 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 MAA14497 for ; Tue, 10 Dec 2002 12:21:32 -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 QQnsqv07688 for ; Tue, 10 Dec 2002 17:24:24 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 QQnsqv02022; Tue, 10 Dec 2002 17:21:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsqv16122 for mpls-outgoing; Tue, 10 Dec 2002 17:20:40 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 QQnsqv16113 for ; Tue, 10 Dec 2002 17:20:35 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 QQnsqv04482 for ; Tue, 10 Dec 2002 17:20:28 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 QQnsqv25107 for ; Tue, 10 Dec 2002 17:20:28 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 QQnsqv25101 for ; Tue, 10 Dec 2002 17:20:27 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBAHKutM001135 for ; Tue, 10 Dec 2002 12:20:56 -0500 (EST) 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 MAA01014 for ; Tue, 10 Dec 2002 12:20:26 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBAHKQe25357 for mpls@uu.net; Tue, 10 Dec 2002 12:20:26 -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 QQnsqv16010 for ; Tue, 10 Dec 2002 17:19: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 QQnsqv00606 for ; Tue, 10 Dec 2002 17:18: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 QQnsqv23836 for ; Tue, 10 Dec 2002 17:18: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 QQnsqv23826 for ; Tue, 10 Dec 2002 17:18: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 MAA40823; Tue, 10 Dec 2002 12:16:47 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212101716.MAA40823@workhorse.fictitious.org> To: Abhishek Saxena cc: George Swallow , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Tue, 10 Dec 2002 16:28:59 +0530." <3DF5C8F3.6060100@cisco.com> Date: Tue, 10 Dec 2002 12:16:47 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3DF5C8F3.6060100@cisco.com>, Abhishek Saxena writes: > Hi, > > I was wondering why an IP header is required in the LSP ping packet. The > information that we need to get the packet across to the egress LSR is > simply the mpls label. The source IP address of this LSR is needed by > the egress LSR to return the packet back. This is already there in the > TLV. We can therefore have a UDPoMPLS kind of a setup in this case, with > no IP header in the packet therefore preventing any IP routing at all > for this packet. > > Does this make sense? > > Regards, > - Abhishek The LSR needs to know what to do with the packet after the last label is stripped off. There is already IP processing and TTL expire processing built into the router. The TTL expire processing needs minimal modification, the IP processing needs very minimal modification (in some cases just configuration of the loopback and filters). Multipath schemes which look into the packet at IP headers for known IP only LSPs can be exercised by varying the destination address within the 127/8 range. No router that I know of currently supports UDP over MPLS without IP. Curtis > George Swallow wrote: > > This message begins a workgroup last call on: > > > > Detecting MPLS Data Plane Liveness > > > > draft-ietf-mpls-lsp-ping-01.txt > > > > The last call ends on Dec 16, 2002 2400H GMT. > > > > George & Loa > > > > ====================================================================== > > George Swallow Cisco Systems (978) 497-8143 > > 250 Apollo Drive > > Chelmsford, Ma 01824 From owner-mpls@UU.NET Tue Dec 10 12:26: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 MAA14604 for ; Tue, 10 Dec 2002 12:26: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 QQnsqv25544 for ; Tue, 10 Dec 2002 17:29:00 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 QQnsqv17864; Tue, 10 Dec 2002 17:24:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsqv16482 for mpls-outgoing; Tue, 10 Dec 2002 17:24: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 QQnsqv16456 for ; Tue, 10 Dec 2002 17:24: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 QQnsqv06505 for ; Tue, 10 Dec 2002 17:23: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 QQnsqv27360 for ; Tue, 10 Dec 2002 17:23:39 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 QQnsqv27351 for ; Tue, 10 Dec 2002 17:23:39 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBAHO8ug001480 for ; Tue, 10 Dec 2002 12:24:08 -0500 (EST) 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 MAA01338 for ; Tue, 10 Dec 2002 12:23:38 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBAHNcr25771 for mpls@uu.net; Tue, 10 Dec 2002 12:23:38 -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 QQnsqv16193 for ; Tue, 10 Dec 2002 17:21:49 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 QQnsqv05247 for ; Tue, 10 Dec 2002 17:20: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 QQnsqv25299 for ; Tue, 10 Dec 2002 17:20:48 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 QQnsqv25293 for ; Tue, 10 Dec 2002 17:20:48 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 MAA40838; Tue, 10 Dec 2002 12:18:43 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212101718.MAA40838@workhorse.fictitious.org> To: Ajay Simha cc: mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Record Object in LSP Ping In-reply-to: Your message of "Tue, 10 Dec 2002 06:44:44 EST." <20021210114444.GL677@cisco.com> Date: Tue, 10 Dec 2002 12:18:43 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <20021210114444.GL677@cisco.com>, Ajay Simha writes: > Hi, > > Since the LSP Ping is meant for fault detection, does anyone see any value > in adding a record route/label TLV to this? This is infeasible without changing forwarding hardware so "no". > Each node can add (if requested) the label that the packet came in with, > the label that this node imposed/swapped and it's LSR-ID. All you need is new forwarding ASICs. > Thanks, > > -ajay Curtis From owner-mpls@UU.NET Tue Dec 10 12:40: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 MAA15128 for ; Tue, 10 Dec 2002 12:40: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 QQnsqw16760 for ; Tue, 10 Dec 2002 17:43:36 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 QQnsqw13267; Tue, 10 Dec 2002 17:41:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsqw18358 for mpls-outgoing; Tue, 10 Dec 2002 17:41: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 QQnsqw18318 for ; Tue, 10 Dec 2002 17:40:41 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 QQnsqw22763 for ; Tue, 10 Dec 2002 17:40: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 QQnsqw11906 for ; Tue, 10 Dec 2002 17:40:19 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 QQnsqw11827 for ; Tue, 10 Dec 2002 17:40:15 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBAHeiNl003838 for ; Tue, 10 Dec 2002 12:40:44 -0500 (EST) 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 MAA02669 for ; Tue, 10 Dec 2002 12:40:14 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBAHeEf00330 for mpls@uu.net; Tue, 10 Dec 2002 12:40:14 -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 QQnsqw18142 for ; Tue, 10 Dec 2002 17:38:25 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 QQnsqw15612 for ; Tue, 10 Dec 2002 17:37: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 QQnsqw05755 for ; Tue, 10 Dec 2002 17:37:14 GMT Received: from ams-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ams-msg-core-1.cisco.com [144.254.74.60]) id QQnsqw05745 for ; Tue, 10 Dec 2002 17:37:13 GMT Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBAHZ0cv009873; Tue, 10 Dec 2002 18:35:01 +0100 (MET) Received: from JVASSEUR-W2K.cisco.com (sjc-vpn2-571.cisco.com [10.21.114.59]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id SAA00523; Tue, 10 Dec 2002 18:36:17 +0100 (MET) Message-Id: <4.3.2.7.2.20021210123021.0382fe10@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 10 Dec 2002 12:36:10 -0500 To: Dimitri.Papadimitriou@alcatel.be From: Jean Philippe Vasseur Subject: Re: Multi-Area TE Protocol Extensions Cc: sachin laddha , mpls@UU.NET, ccamp@ops.ietf.org In-Reply-To: <3DF61A35.7BE9B01E@alcatel.be> References: <4.3.2.7.2.20021210090846.06284110@paris.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi Dimitri, cc'ing CCAMP - see in line, At 17:45 10/12/2002 +0100, Dimitri.Papadimitriou@alcatel.be wrote: >jp, > >in fact the below list should simply be as follows for >signalling-based methods: 1) constraint-passing 2) loose >routing and 3) path query; > >and the for constraint-passing we have a several i-d's >such as, > >http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclude-route-01.txt > this ID does not propose a mechanism to compute inter-area TE path >constraint passing may also be extended using the crank- >back as listed below; the usage scenarios of these methods >are described in the following: > >http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-03.txt > >now probably it is worth spending some time in considering >input coming from the tewg wrt to this effort, most of the >input that you see listed above has been produced over the >past year (and more) i can't imagine stepping in the protocol >details without a clear consensus on what do we want to cover >within the ccamp wg & w/o taking into account the tewg rec's >(probably better to discuss this on the ccamp mailing list) Fully agree with you. Hopefully multi-area TE should be soon part of the CCAMP charter. JP. >thanks, >- dimitri. > >Jean Philippe Vasseur wrote: > > > > Hi, > > > > At 13:53 10/12/2002 +0530, sachin laddha wrote: > > >Hi, > > >'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as > > >"Initial requirements are given here for protocol support of the > multi-area > > >TE methods, which include needs to support > > > > > >* path-computation-server (PCS) functionality [kompella, lee, > vasseur, > > >te-qos-routing], > > >* query functionality [query, vasseur], > > >* crankback functionality [crankback], > > > > > >and, optionally, > > > > > >* TE feedback functionality [feedback], and > > >* summary-LSA functionality [summary_lsa]." > > >. > > >I want to know whether cisco/juniper routers (standard ones) supports > all of > > >the above extension. > > >or if not,how many.......or Whether router is supposed to support how many > > >... > > > > I do not think any vendor supports all the method mentioned above, but just > > a subset. If you are running a network, your feed-backs on your preferred > > method is very welcome. > > > > JP. > > > > >Regards, > > >---Sachin > >-- >Papadimitriou Dimitri >E-mail : dimitri.papadimitriou@alcatel.be >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html >E-mail : dpapadimitriou@psg.com >Public : http://psg.com/~dpapadimitriou/ >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium >Phone : Work: +32 3 2408491 - Home: +32 2 3434361 From owner-mpls@UU.NET Tue Dec 10 12:43:16 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 MAA15280 for ; Tue, 10 Dec 2002 12:43: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 QQnsqx07939 for ; Tue, 10 Dec 2002 17:46: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 QQnsqw21091; Tue, 10 Dec 2002 17:36:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsqw18017 for mpls-outgoing; Tue, 10 Dec 2002 17:36: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 QQnsqw18012 for ; Tue, 10 Dec 2002 17:36:16 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 QQnsqw10335 for ; Tue, 10 Dec 2002 17:34:21 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 QQnsqw07297 for ; Tue, 10 Dec 2002 17:34:20 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 QQnsqw07293 for ; Tue, 10 Dec 2002 17:34:20 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBAHYnJb002903 for ; Tue, 10 Dec 2002 12:34:49 -0500 (EST) 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 MAA02176 for ; Tue, 10 Dec 2002 12:34:19 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBAHYJt29629 for mpls@uu.net; Tue, 10 Dec 2002 12:34:19 -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 QQnsqw17544 for ; Tue, 10 Dec 2002 17:33:01 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 QQnsqw05415 for ; Tue, 10 Dec 2002 17:32:50 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 QQnsqw02256 for ; Tue, 10 Dec 2002 17:32:50 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 QQnsqw02222 for ; Tue, 10 Dec 2002 17:32:48 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 MAA40986; Tue, 10 Dec 2002 12:30:49 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212101730.MAA40986@workhorse.fictitious.org> To: mpls@UU.NET cc: curtis@fictitious.org Reply-To: curtis@fictitious.org Subject: oops (was Re: Last call on LSP Ping) Date: Tue, 10 Dec 2002 12:30:49 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk Thought this was part of a separate private thread. Sorry. Curtis ------- Forwarded Message Return-Path: curtis@workhorse.fictitious.org Delivery-Date: Tue Dec 10 10:57:46 2002 Return-Path: Received: from localhost (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id KAA40659 for ; Tue, 10 Dec 2002 10:57:46 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Received: from gateway2.fictitious.org [209.150.1.252] by localhost with POP3 (fetchmail-5.5.1) for curtis@localhost (single-drop); Tue, 10 Dec 2002 10:57:46 -0500 (EST) Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by gateway2.fictitious.org (8.11.6/8.11.6) with ESMTP id gBAFvj860956 for ; Tue, 10 Dec 2002 10:57:45 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) 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 KAA40637; Tue, 10 Dec 2002 10:52:05 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212101552.KAA40637@workhorse.fictitious.org> To: neil.2.harrison@bt.com cc: curtis@fictitious.org, Shahram_Davari@pmc-sierra.com, dallan@nortelnetworks.com, swallow@cisco.com, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Tue, 10 Dec 2002 13:43:24 GMT." <0536FC9B908BEC4597EE721BE6A35389014CFCE9@i2km07-ukbr.domain1.systemhost.net> Date: Tue, 10 Dec 2002 10:52:04 -0500 From: Curtis Villamizar X-UIDL: p/a!!(*J!!U)O!!)(>!! In message <0536FC9B908BEC4597EE721BE6A35389014CFCE9@i2km07-ukbr.domain1.system host.net>, neil.2.harrison@bt.com writes: > > > > I looked at this again and it appears I had this wrong. > NH=> Yes, I agree it's not immediately obvious. And if you are having > problems understanding all this think about how others must be finding it. It was clearly written. I didn't bother to read this part carefully enough. Lets put the blame where it belongs. > > If the > > "Downstream Mapping" was used to form a RESV, then this would be fine, > > but it is not the case. > > > > In order to have *any* MPLS/TE LSP going to an adjacent router, there > > must be an RSVP adjacency. The route up to the point where the path > > went wrong is in the MPLS-ping packet payload if the "Downstream > > Mapping" is present so the router could in principle send the packet > > back hop by hop in RSVP. I was assuming that the "Downstream Mapping" > > could be inverted but I see that the intent is to simply add the > > LSP_ECHO in the normal RESV for the LSP. As is it is just a > > continuity test. > NH=> Agreed....that was precisely my point, ie this can only be used to > detect breaks. My understanding of the intention of this mode was to > resolve the break to either 'go' or 'return' directions (on the assumption > that using an RSVP return path for comms is reliable since it indicates > itself whether up/down). > > > > It seems that error indication on misdirected traffic is only possible > > if IP routing is used to deliver the reply. > NH=> Agreed, this was what I was driving at in my 2nd set of questions that > I posed 5 Dec, and specifically Q6 therein. I am still waiting a response > on all my postings.....to repeat that specific question: > "6 In the same section......why is there an option to reply by the RSVP > control-plane? What scenario is this addressing that the above (NH=> ie > using IP only) doesn't? Further, some guidance on when to select which > option would be useful." I wouldn't mind getting rid of this. C&W (for example) has talked about running a no-IP routing core with MPLS over it. I think this is a very bad idea. It is speculative on my part but I think someone is either directly driving this or it was added to head off any objections that might arise. I thought you were one that insisted on a means to decouple diagnostics from an IP control plane. Maybe I'm mistaken. > > Even so, if the packet is misdirected, at some hop the packet arrives > > at the wrong router. In traceroute mode you can determine when this > > occurs and which router the traffic is being misdirected towards (if > > IP can be used to return the packet). > NH=> Yes. But you don't want to be running trace route continually IMO. > Trace route should be available to run *after* a mismerging defect is > detected as an ad hoc diagnostics tool. RSVP return option fails here as we > have noted....hence I ask why bother with it? However, I am still unclear > what happens wrt to setting the router alert option (to attempt to avoid LSP > return paths?), esp in the case where the network is just LSPs and no IP > (return) fowarding is possible (see Note). I also asked about this in my > earlier 2nd posting in Q5....still no response, so here it is again: > "5 In the same section.....can you please explain in a little more > detail why there are 2 IPv4/UDP (and no v6??) reply modes, one without > router alert set and one with router alert set? The text seems to indicate > the latter is more reliable than the former." If the continuity test fails, it would make sense to run traceroute. If a fault has occurred that is not due to an error that is evident in the control plane, then this would point to where the error is. > Note - IMO it's not architecturally correct to be asking a client (or > server) layer network technology (any) or a signalling protocol (any, and > should include the case of *none*, ie static provisioned) to be taking a > critical role in the data-plane fault management of a layer network....here > MPLS, though this principle is general to any layer network. However, I > can't easily/simply see how we are going to crack the problems of merging in > a co forwarding mode (ie mp2p) without breaking the architecture in some > way. But let's try and keep the 'nifty hacks' to the minimum please and try > and respect the layered architecture as far as possible. Let's also try and > keep it simple. It would have helped if we had had some agreed requirements > up front that we were shooting at. This was done for the p2p case in Y.1710 > and then with the solutions in Y.1711....not only do these respect layered > architectures but they are both very powerful and very simple. But they > won't jive with the fault-management complexities mp2p throws up though, so > we must keep working on this. > Implementation is greatly simplified by putting most of the fault management smarts at the application layer. Lets just agree to disagree about what is a nifty hack. I'll be sending a mesage on ECMP shortly. Please feel free to comment then. Curtis ------- End of Forwarded Message From owner-mpls@UU.NET Tue Dec 10 13:07:22 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 NAA16226 for ; Tue, 10 Dec 2002 13:07:22 -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 QQnsqy10554 for ; Tue, 10 Dec 2002 18:10:12 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 QQnsqy03305; Tue, 10 Dec 2002 18:06:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsqy08483 for mpls-outgoing; Tue, 10 Dec 2002 18:05:56 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 QQnsqy08478 for ; Tue, 10 Dec 2002 18:05:51 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 QQnsqy18600 for ; Tue, 10 Dec 2002 18:05:07 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 QQnsqy06030 for ; Tue, 10 Dec 2002 18:05:07 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 QQnsqy06023 for ; Tue, 10 Dec 2002 18:05:06 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBAI5ZSC007503 for ; Tue, 10 Dec 2002 13:05:36 -0500 (EST) 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 NAA04805 for ; Tue, 10 Dec 2002 13:05:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBAI55W06417 for mpls@uu.net; Tue, 10 Dec 2002 13:05:05 -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 QQnsqy07781 for ; Tue, 10 Dec 2002 18:03: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 QQnsqy16969 for ; Tue, 10 Dec 2002 18:02: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 QQnsqy04790 for ; Tue, 10 Dec 2002 18:02:58 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 QQnsqy04786 for ; Tue, 10 Dec 2002 18:02:57 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 NAA41316; Tue, 10 Dec 2002 13:00:35 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212101800.NAA41316@workhorse.fictitious.org> To: Shahram Davari cc: "'curtis@fictitious.org'" , Ajay Simha , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Record Object in LSP Ping In-reply-to: Your message of "Tue, 10 Dec 2002 09:35:28 PST." <4B6D09F3B826D411A67300D0B706EFDEB03B72@nt-exch-yow.pmc-sierra.bc.ca> Date: Tue, 10 Dec 2002 13:00:35 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4B6D09F3B826D411A67300D0B706EFDEB03B72@nt-exch-yow.pmc-sierra.bc.ca >, Shahram Davari writes: > I fail to understand how adding a TLV to the ping affects > forwarding ASICs! > > -Shahram Shahram, There are two modes: 1. ping mode 2. traceroute mode Since traceroute mode already yields the full path, the record route, analogous to IP record route option, would be applicable to ping mode or to traceroute once TTL was greater than 1. In traceroute mode, a control plane trace is performed and confirmed by incrementing TTL and checking to see that the router returning the next reply was the one expected, thereby verifying each forwarding hop separately. In ping mode and when traceroute TTL>1 , the forwarding is being exercised. The only way a record route can be supported is to modify the forwarding such that the bottom of the stack is checked, the payload determined to be mpls-ping, the packet extracted from the forwarding stream, the record route hop recorded, and the packet put back into the forwarding stream. This arguably is no longer the normal packet forwarding so not only would we (everyone) have to change hardware, but we defeat a prime purpose of ping mode (a forwarding based continuity check). Curtis > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > Sent: Tuesday, December 10, 2002 12:19 PM > > To: Ajay Simha > > Cc: mpls@UU.NET > > Subject: Re: Record Object in LSP Ping > > > > > > > > In message <20021210114444.GL677@cisco.com>, Ajay Simha writes: > > > Hi, > > > > > > Since the LSP Ping is meant for fault detection, does > > anyone see any value > > > in adding a record route/label TLV to this? > > > > This is infeasible without changing forwarding hardware so "no". > > > > > Each node can add (if requested) the label that the packet > > came in with, > > > the label that this node imposed/swapped and it's LSR-ID. > > > > All you need is new forwarding ASICs. > > > > > Thanks, > > > > > > -ajay > > > > Curtis > > > From owner-mpls@UU.NET Tue Dec 10 13:13: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 NAA16358 for ; Tue, 10 Dec 2002 13:13:06 -0500 (EST) 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 QQnsqw26855; Tue, 10 Dec 2002 17:39:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsqw18235 for mpls-outgoing; Tue, 10 Dec 2002 17:39:40 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 QQnsqw18214 for ; Tue, 10 Dec 2002 17:39: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 QQnsqw07986 for ; Tue, 10 Dec 2002 17:39: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 QQnsqw10966 for ; Tue, 10 Dec 2002 17:39:10 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 QQnsqw10960 for ; Tue, 10 Dec 2002 17:39:10 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBAHdcgN003704 for ; Tue, 10 Dec 2002 12:39:39 -0500 (EST) 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 MAA02592 for ; Tue, 10 Dec 2002 12:39:08 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBAHd8f29987 for mpls@uu.net; Tue, 10 Dec 2002 12:39:08 -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 QQnsqw18037 for ; Tue, 10 Dec 2002 17:37: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 QQnsqw27947 for ; Tue, 10 Dec 2002 17:35:38 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 QQnsqw04503 for ; Tue, 10 Dec 2002 17:35:37 GMT Received: from father.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQnsqw04493 for ; Tue, 10 Dec 2002 17:35:36 GMT Received: (qmail 10366 invoked by uid 104); 10 Dec 2002 17:35:36 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4236. . Clean. Processed in 0.506466 secs); 10 Dec 2002 17:35:36 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 10 Dec 2002 17:35:35 -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 gBAHZUQ05989; Tue, 10 Dec 2002 09:35:30 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Tue, 10 Dec 2002 09:35:29 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B72@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'curtis@fictitious.org'" , Ajay Simha Cc: mpls@UU.NET Subject: RE: Record Object in LSP Ping Date: Tue, 10 Dec 2002 09:35:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk I fail to understand how adding a TLV to the ping affects forwarding ASICs! -Shahram > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: Tuesday, December 10, 2002 12:19 PM > To: Ajay Simha > Cc: mpls@UU.NET > Subject: Re: Record Object in LSP Ping > > > > In message <20021210114444.GL677@cisco.com>, Ajay Simha writes: > > Hi, > > > > Since the LSP Ping is meant for fault detection, does > anyone see any value > > in adding a record route/label TLV to this? > > This is infeasible without changing forwarding hardware so "no". > > > Each node can add (if requested) the label that the packet > came in with, > > the label that this node imposed/swapped and it's LSR-ID. > > All you need is new forwarding ASICs. > > > Thanks, > > > > -ajay > > Curtis > From owner-mpls@UU.NET Tue Dec 10 13:15: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 NAA16425 for ; Tue, 10 Dec 2002 13:15:28 -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 QQnsqz23776 for ; Tue, 10 Dec 2002 18:18: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 QQnsqy16093; Tue, 10 Dec 2002 18:14:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsqy10344 for mpls-outgoing; Tue, 10 Dec 2002 18:13:37 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 QQnsqy10335 for ; Tue, 10 Dec 2002 18:13:36 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 QQnsqy11554 for ; Tue, 10 Dec 2002 18:12: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 QQnsqy12491 for ; Tue, 10 Dec 2002 18:12:44 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 QQnsqy12486 for ; Tue, 10 Dec 2002 18:12:43 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBAIDCfS008723 for ; Tue, 10 Dec 2002 13:13:12 -0500 (EST) 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 NAA05524 for ; Tue, 10 Dec 2002 13:12:42 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBAICgt07846 for mpls@uu.net; Tue, 10 Dec 2002 13:12:42 -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 QQnsqy09746 for ; Tue, 10 Dec 2002 18:10: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 QQnsqy05020 for ; Tue, 10 Dec 2002 18: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 QQnsqy10226 for ; Tue, 10 Dec 2002 18:10:03 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 QQnsqy10210 for ; Tue, 10 Dec 2002 18:10:02 GMT Received: (qmail 8801 invoked by uid 104); 10 Dec 2002 18:10:02 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4236. . Clean. Processed in 0.527541 secs); 10 Dec 2002 18:10:02 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 10 Dec 2002 18:10:01 -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 gBAIA1Q26300; Tue, 10 Dec 2002 10:10:01 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Tue, 10 Dec 2002 10:10:00 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B73@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'curtis@fictitious.org'" Cc: Ajay Simha , mpls@UU.NET Subject: RE: Record Object in LSP Ping Date: Tue, 10 Dec 2002 10:09:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Thanks Curtis, I agree with your conclusion. -Shahram > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: Tuesday, December 10, 2002 1:01 PM > To: Shahram Davari > Cc: 'curtis@fictitious.org'; Ajay Simha; mpls@UU.NET > Subject: Re: Record Object in LSP Ping > > > > In message > <4B6D09F3B826D411A67300D0B706EFDEB03B72@nt-exch-yow.pmc-sierra.bc.ca > >, Shahram Davari writes: > > I fail to understand how adding a TLV to the ping affects > > forwarding ASICs! > > > > -Shahram > > > Shahram, > > There are two modes: > > 1. ping mode > > 2. traceroute mode > > Since traceroute mode already yields the full path, the record route, > analogous to IP record route option, would be applicable to ping mode > or to traceroute once TTL was greater than 1. > > In traceroute mode, a control plane trace is performed and confirmed > by incrementing TTL and checking to see that the router returning the > next reply was the one expected, thereby verifying each forwarding hop > separately. > > In ping mode and when traceroute TTL>1 , the forwarding is being > exercised. The only way a record route can be supported is to modify > the forwarding such that the bottom of the stack is checked, the > payload determined to be mpls-ping, the packet extracted from the > forwarding stream, the record route hop recorded, and the packet put > back into the forwarding stream. This arguably is no longer the > normal packet forwarding so not only would we (everyone) have to > change hardware, but we defeat a prime purpose of ping mode (a > forwarding based continuity check). > > Curtis > > > > > -----Original Message----- > > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > > Sent: Tuesday, December 10, 2002 12:19 PM > > > To: Ajay Simha > > > Cc: mpls@UU.NET > > > Subject: Re: Record Object in LSP Ping > > > > > > > > > > > > In message <20021210114444.GL677@cisco.com>, Ajay Simha writes: > > > > Hi, > > > > > > > > Since the LSP Ping is meant for fault detection, does > > > anyone see any value > > > > in adding a record route/label TLV to this? > > > > > > This is infeasible without changing forwarding hardware so "no". > > > > > > > Each node can add (if requested) the label that the packet > > > came in with, > > > > the label that this node imposed/swapped and it's LSR-ID. > > > > > > All you need is new forwarding ASICs. > > > > > > > Thanks, > > > > > > > > -ajay > > > > > > Curtis > > > > > > From owner-mpls@UU.NET Tue Dec 10 13:23:34 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 NAA16722 for ; Tue, 10 Dec 2002 13:23:34 -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 QQnsqz07597 for ; Tue, 10 Dec 2002 18:26:16 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 QQnsqz02025; Tue, 10 Dec 2002 18:23:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsqz11578 for mpls-outgoing; Tue, 10 Dec 2002 18:23:24 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 QQnsqz11556 for ; Tue, 10 Dec 2002 18:23: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 QQnsqz05927 for ; Tue, 10 Dec 2002 18:22:58 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 QQnsqz10832 for ; Tue, 10 Dec 2002 18:22:58 GMT Received: from ns2.vivacenetworks.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: [64.221.212.135]) id QQnsqz10816 for ; Tue, 10 Dec 2002 18:22:57 GMT Received: from AMALIS.vivacenetworks.com ([10.5.20.23]) by vivacenetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 10 Dec 2002 10:22:50 -0800 Message-Id: <5.1.0.14.2.20021210131838.06660270@po1.vivacenetworks.com> X-Sender: vivacenet\amalis@po1.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 10 Dec 2002 13:22:48 -0500 To: mpls@UU.NET From: "Andrew G. Malis" Subject: Email list problem, and archive? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 10 Dec 2002 18:22:51.0111 (UTC) FILETIME=[2622FF70:01C2A079] Sender: owner-mpls@UU.NET Precedence: bulk I'm sending this email for two reasons: 1. I haven't received any mail on the list for a week or so, and I wanted to make sure I'm still receiving it. Majordomo@uu.net claims I'm still on the list. 2. Is there a working archive for the list? The URL in the charter, http://cell.onecall.net/cell-relay/archives/mpls/mpls.index.html , seems to be broken. Thanks, Andy From owner-mpls@UU.NET Tue Dec 10 13:43: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 NAA17256 for ; Tue, 10 Dec 2002 13:43:01 -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 QQnsrb12153 for ; Tue, 10 Dec 2002 18:45: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 QQnsra09911; Tue, 10 Dec 2002 18:44:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsra13303 for mpls-outgoing; Tue, 10 Dec 2002 18:44:23 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 QQnsra13281 for ; Tue, 10 Dec 2002 18:44:13 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 QQnsra24933 for ; Tue, 10 Dec 2002 18:44: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 QQnsra09431 for ; Tue, 10 Dec 2002 18:44:10 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 QQnsra09356 for ; Tue, 10 Dec 2002 18:44:05 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 gBAIhAD26546; Tue, 10 Dec 2002 13:43:11 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Dec 2002 13:43:08 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C0666D7C5@zcard031.ca.nortel.com> From: "David Allan" To: erosen@cisco.com, Alia Atlas Cc: mpls@UU.NET Subject: RE: Last Call on MPLS ping Date: Tue, 10 Dec 2002 13:43:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2A07B.FB09D5A4" 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_01C2A07B.FB09D5A4 Content-Type: text/plain; charset="iso-8859-1" Eric: Someone else probably should be answering this but I would presume the existence of the FEC stack is that for some implementations, only the PSN label can be tested, not the actual PW label. SO the FEC stack proxies for the inability to test the PW label, and some precision is lost as a result. (esp. when considered in the context of the parallel ECMP discussion). cheers Dave > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Monday, December 09, 2002 12:38 PM > To: Alia Atlas > Cc: mpls@UU.NET > Subject: Re: Last Call on MPLS ping > > > > Alia> So, my concern here is for the case where the > route is not an > Alia> aggregate and the label indicates the egress > attachment circuit as > Alia> well as the encapsulation header for the packet. > > Alia> In this case, LSP ping would send an IP packet > with the specific > Alia> route's label and then the PSN's label. > > That isn't my interpretation of the draft. I think the > intention is that > the LSP ping carries only the "PSN label". That is, it > carries only the > label or labels needed to get it to the egress PE, not > the label that > identifies a particular VPN route (or a particular PWE3 pseudowire). > > If you wanted to know not only whether a particular LSP > leads to the > intended PE, but also whether that PE is a proper egress > for a particular > VPN route (or PWE3 pseudowire), then I think you would need > to use the FEC > stack TLV in the body of the message to identify that VPN route. > > > Alia> I.e., consider if > Alia> a packet comes in with a PSN label, PW label, and then > an IPv4 Explicit > Alia> NULL, as specified in Section 5.3: > Alia> "To test an LSP that carries non-IP traffic, before > injecting ICMP > Alia> and MPLS ping messages into the LSP, the IPv4 > Explicit NULL label > Alia> should be prepended to such messages. The ingress > and egress LSR's > Alia> must follow the procedures defined in [LABEL-STACKING]" > > > I'd agree that this is a strange passage ;-) Remember > though that the > context is RSVP-TE only. I'd guess that the purpose of the > explicit null is > to counteract the effect of the RSVP-TE L3PID field. > ------_=_NextPart_001_01C2A07B.FB09D5A4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Last Call on MPLS ping

Eric:

Someone else probably should be answering this but I = would presume the existence of the FEC stack is that for some = implementations, only the PSN label can be tested, not the actual PW = label. SO the FEC stack proxies for the inability to test the PW label, = and some precision is lost as a result. (esp. when considered in the = context of the parallel ECMP discussion).

cheers
Dave

> -----Original Message-----
> From: Eric Rosen [mailto:erosen@cisco.com]
> Sent: Monday, December 09, 2002 12:38 PM
> To: Alia Atlas
> Cc: mpls@UU.NET
> Subject: Re: Last Call on MPLS ping
>
>
>
> Alia> So,  my concern  here  = is  for the  case  where the 
> route  is not  an
> Alia> aggregate  and the label  = indicates the  egress
> attachment  circuit as
> Alia> well as the encapsulation header for = the packet.
>
> Alia> In  this case,  LSP = ping  would send  an IP  packet
> with  the specific
> Alia> route's label and then the PSN's = label.
>
> That isn't  my interpretation of the  = draft.  I think the 
> intention is that
> the LSP  ping carries only  the = "PSN label".   That is, it
> carries  only the
> label  or labels  needed to  get = it  to the  egress PE,  not
> the  label that
> identifies a particular VPN route (or a = particular PWE3 pseudowire).
>
> If  you wanted  to  know = not  only whether  a  particular LSP
>  leads to  the
> intended PE,  but also whether that = PE  is a proper egress 
> for a particular
> VPN route (or PWE3  pseudowire), then I = think you would need 
> to use the FEC
> stack TLV in the body of the message to = identify that VPN route.
>
>
> Alia> I.e., consider if
> Alia> a packet comes in with a PSN label, PW = label, and then
> an IPv4 Explicit
> Alia> NULL, as specified in Section  = 5.3:
> Alia>     "To test = an LSP that carries non-IP traffic, before
> injecting ICMP
> Alia>     and MPLS ping = messages into  the LSP, the IPv4
> Explicit NULL label
> Alia>     should be = prepended to such messages. The ingress
> and egress LSR's
> Alia>     must follow = the procedures defined in [LABEL-STACKING]"
>
>
> I'd  agree that  this is  = a  strange passage  ;-) Remember 
> though that  the
> context is RSVP-TE only. I'd guess  that = the purpose of the
> explicit null is
> to counteract the effect of the RSVP-TE L3PID = field.
>

------_=_NextPart_001_01C2A07B.FB09D5A4-- From owner-mpls@UU.NET Tue Dec 10 13:59: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 NAA17627 for ; Tue, 10 Dec 2002 13:59:07 -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 QQnsrc00414 for ; Tue, 10 Dec 2002 19:01:50 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 QQnsrb26100; Tue, 10 Dec 2002 18:59:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsrb14790 for mpls-outgoing; Tue, 10 Dec 2002 18:58: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 QQnsrb14780 for ; Tue, 10 Dec 2002 18:58:49 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 QQnsrb03961 for ; Tue, 10 Dec 2002 18:58:15 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 QQnsrb25363 for ; Tue, 10 Dec 2002 18:58:15 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 QQnsrb25355 for ; Tue, 10 Dec 2002 18:58:15 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBAIwiUJ016173 for ; Tue, 10 Dec 2002 13:58:44 -0500 (EST) 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 NAA09411 for ; Tue, 10 Dec 2002 13:58:13 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBAIwDI15430 for mpls@uu.net; Tue, 10 Dec 2002 13:58:13 -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 QQnsrb14582 for ; Tue, 10 Dec 2002 18:56:11 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 QQnsrb02305 for ; Tue, 10 Dec 2002 18:55: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 QQnsrb02053 for ; Tue, 10 Dec 2002 18:55:31 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 QQnsrb02044 for ; Tue, 10 Dec 2002 18:55:30 GMT Received: (qmail 15836 invoked by uid 104); 10 Dec 2002 18:55:29 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4236. . Clean. Processed in 0.677811 secs); 10 Dec 2002 18:55:29 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 10 Dec 2002 18:55:28 -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 gBAItSQ24816; Tue, 10 Dec 2002 10:55:28 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Tue, 10 Dec 2002 10:55:27 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B74@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'erosen@cisco.com'" , Alia Atlas Cc: mpls@UU.NET Subject: RE: Last Call on MPLS ping Date: Tue, 10 Dec 2002 10:55:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Monday, December 09, 2002 12:38 PM > Alia> So, my concern here is for the case where the > route is not an > Alia> aggregate and the label indicates the egress > attachment circuit as > Alia> well as the encapsulation header for the packet. > > Alia> In this case, LSP ping would send an IP packet > with the specific > Alia> route's label and then the PSN's label. > > That isn't my interpretation of the draft. I think the > intention is that > the LSP ping carries only the "PSN label". That is, it > carries only the > label or labels needed to get it to the egress PE, not > the label that > identifies a particular VPN route (or a particular PWE3 pseudowire). > > If you wanted to know not only whether a particular LSP > leads to the > intended PE, but also whether that PE is a proper egress > for a particular > VPN route (or PWE3 pseudowire), then I think you would need > to use the FEC > stack TLV in the body of the message to identify that VPN route. > But how do you test that the VPN route is bound to the proper PW label? -Shahram From owner-mpls@UU.NET Tue Dec 10 14:42: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 OAA18910 for ; Tue, 10 Dec 2002 14:42:45 -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 QQnsrf09645 for ; Tue, 10 Dec 2002 19:45: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 QQnsre03514; Tue, 10 Dec 2002 19:42:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsre16551 for mpls-outgoing; Tue, 10 Dec 2002 19:41: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 QQnsre16509 for ; Tue, 10 Dec 2002 19:41: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 QQnsre12961 for ; Tue, 10 Dec 2002 19:39: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 QQnsre29793 for ; Tue, 10 Dec 2002 19:39:49 GMT Received: from mail.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc239.alcatel.be [195.207.101.239]) id QQnsre29786 for ; Tue, 10 Dec 2002 19:39:48 GMT Received: from bemail05.net.alcatel.be (localhost [127.0.0.1]) by mail.alcatel.be (8.10.1/8.11.4) with ESMTP id gBAJdWZ17621; Tue, 10 Dec 2002 20:39:32 +0100 (MET) Received: from alcatel.be ([138.203.67.228]) by bemail05.net.alcatel.be (Lotus Domino Release 5.0.9a) with ESMTP id 2002121020393045:5441 ; Tue, 10 Dec 2002 20:39:30 +0100 Message-ID: <3DF643DF.4F8AC12C@alcatel.be> Date: Tue, 10 Dec 2002 20:43:27 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: Optical Network Architecture (NTA - Antwerpen) X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jean Philippe Vasseur Cc: sachin laddha , mpls@UU.NET, ccamp@ops.ietf.org Subject: Re: Multi-Area TE Protocol Extensions References: <4.3.2.7.2.20021210090846.06284110@paris.cisco.com> <4.3.2.7.2.20021210123021.0382fe10@paris.cisco.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.9a |January 7, 2002) at 12/10/2002 20:39:30, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.9a |January 7, 2002) at 12/10/2002 20:39:32, Serialize complete at 12/10/2002 20:39:32 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit jp, > this ID does not propose a mechanism to compute inter-area TE path well i would say that either none of them does it, or all of them, more accurately route exclusions are applicable to any mpls network where full computation of the ero is not performed before the LSP is signaled, implying thus a "scope" for computed path thus among other applicable to multiple areas - nevertheless i agree that a next version of this i-d should probably include an applicability section covering this in a bit more details (see also section 4.1 for an example - this said and as for any other input or i-d provided on constraint- passing (as well as path query, btw) lot of work is still needed to achieve a decent first step in this effort; thanks, - dimitri. Jean Philippe Vasseur wrote: > > Hi Dimitri, > > cc'ing CCAMP - see in line, > > At 17:45 10/12/2002 +0100, Dimitri.Papadimitriou@alcatel.be wrote: > >jp, > > > >in fact the below list should simply be as follows for > >signalling-based methods: 1) constraint-passing 2) loose > >routing and 3) path query; > > > >and the for constraint-passing we have a several i-d's > >such as, > > > >http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclude-route-01.txt > > > > this ID does not propose a mechanism to compute inter-area TE path > > >constraint passing may also be extended using the crank- > >back as listed below; the usage scenarios of these methods > >are described in the following: > > > >http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-03.txt > > > >now probably it is worth spending some time in considering > >input coming from the tewg wrt to this effort, most of the > >input that you see listed above has been produced over the > >past year (and more) i can't imagine stepping in the protocol > >details without a clear consensus on what do we want to cover > >within the ccamp wg & w/o taking into account the tewg rec's > >(probably better to discuss this on the ccamp mailing list) > > Fully agree with you. Hopefully multi-area TE should be soon part of the > CCAMP charter. > > JP. > > >thanks, > >- dimitri. > > > >Jean Philippe Vasseur wrote: > > > > > > Hi, > > > > > > At 13:53 10/12/2002 +0530, sachin laddha wrote: > > > >Hi, > > > >'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as > > > >"Initial requirements are given here for protocol support of the > > multi-area > > > >TE methods, which include needs to support > > > > > > > >* path-computation-server (PCS) functionality [kompella, lee, > > vasseur, > > > >te-qos-routing], > > > >* query functionality [query, vasseur], > > > >* crankback functionality [crankback], > > > > > > > >and, optionally, > > > > > > > >* TE feedback functionality [feedback], and > > > >* summary-LSA functionality [summary_lsa]." > > > >. > > > >I want to know whether cisco/juniper routers (standard ones) supports > > all of > > > >the above extension. > > > >or if not,how many.......or Whether router is supposed to support how many > > > >... > > > > > > I do not think any vendor supports all the method mentioned above, but just > > > a subset. If you are running a network, your feed-backs on your preferred > > > method is very welcome. > > > > > > JP. > > > > > > >Regards, > > > >---Sachin > > > >-- > >Papadimitriou Dimitri > >E-mail : dimitri.papadimitriou@alcatel.be > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > >E-mail : dpapadimitriou@psg.com > >Public : http://psg.com/~dpapadimitriou/ > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > >Phone : Work: +32 3 2408491 - Home: +32 2 3434361 -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : Work: +32 3 2408491 - Home: +32 2 3434361 From owner-mpls@UU.NET Tue Dec 10 15:15: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 PAA19731 for ; Tue, 10 Dec 2002 15:15:27 -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 QQnsrh28069 for ; Tue, 10 Dec 2002 20:18: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 QQnsrh25060; Tue, 10 Dec 2002 20:16:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsrh20007 for mpls-outgoing; Tue, 10 Dec 2002 20:16:43 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 QQnsrh19960 for ; Tue, 10 Dec 2002 20:16:36 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 QQnsrh01449 for ; Tue, 10 Dec 2002 20:16:23 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 QQnsrh24608 for ; Tue, 10 Dec 2002 20:16:23 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 QQnsrh24603 for ; Tue, 10 Dec 2002 20:16:22 GMT Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gBAKFkS51587; Tue, 10 Dec 2002 12:15:46 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200212102015.gBAKFkS51587@merlot.juniper.net> To: Dimitri.Papadimitriou@alcatel.be cc: Jean Philippe Vasseur , sachin laddha , mpls@UU.NET, ccamp@ops.ietf.org Subject: Re: Multi-Area TE Protocol Extensions In-Reply-To: Your message of "Tue, 10 Dec 2002 20:43:27 +0100." <3DF643DF.4F8AC12C@alcatel.be> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <50341.1039551345.1@juniper.net> Date: Tue, 10 Dec 2002 12:15:46 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Dimitri, > > this ID does not propose a mechanism to compute inter-area TE path > > well i would say that either none of them does it, or all of > them, more accurately route exclusions are applicable to any > mpls network where full computation of the ero is not performed > before the LSP is signaled, implying thus a "scope" for computed > path thus among other applicable to multiple areas - nevertheless > i agree that a next version of this i-d should probably include > an applicability section covering this in a bit more details (see > also section 4.1 for an example - > > this said and as for any other input or i-d provided on constraint- > passing (as well as path query, btw) lot of work is still needed to > achieve a decent first step in this effort; On the subject passing constraint, I'd like to mention draft-kompella-mpls-rsvp-constraints-00.txt (expired, but I could provide a copy upon request). It contains a fairly general mechanism for passing constraints in RSVP. Yakov. > > thanks, > - dimitri. > > Jean Philippe Vasseur wrote: > > > > Hi Dimitri, > > > > cc'ing CCAMP - see in line, > > > > At 17:45 10/12/2002 +0100, Dimitri.Papadimitriou@alcatel.be wrote: > > >jp, > > > > > >in fact the below list should simply be as follows for > > >signalling-based methods: 1) constraint-passing 2) loose > > >routing and 3) path query; > > > > > >and the for constraint-passing we have a several i-d's > > >such as, > > > > > >http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclude-route- 01.txt > > > > > > > this ID does not propose a mechanism to compute inter-area TE path > > > > >constraint passing may also be extended using the crank- > > >back as listed below; the usage scenarios of these methods > > >are described in the following: > > > > > >http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-03.tx t > > > > > >now probably it is worth spending some time in considering > > >input coming from the tewg wrt to this effort, most of the > > >input that you see listed above has been produced over the > > >past year (and more) i can't imagine stepping in the protocol > > >details without a clear consensus on what do we want to cover > > >within the ccamp wg & w/o taking into account the tewg rec's > > >(probably better to discuss this on the ccamp mailing list) > > > > Fully agree with you. Hopefully multi-area TE should be soon part of the > > CCAMP charter. > > > > JP. > > > > >thanks, > > >- dimitri. > > > > > >Jean Philippe Vasseur wrote: > > > > > > > > Hi, > > > > > > > > At 13:53 10/12/2002 +0530, sachin laddha wrote: > > > > >Hi, > > > > >'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as > > > > >"Initial requirements are given here for protocol support of the > > > multi-area > > > > >TE methods, which include needs to support > > > > > > > > > >* path-computation-server (PCS) functionality [kompella, lee, > > > vasseur, > > > > >te-qos-routing], > > > > >* query functionality [query, vasseur], > > > > >* crankback functionality [crankback], > > > > > > > > > >and, optionally, > > > > > > > > > >* TE feedback functionality [feedback], and > > > > >* summary-LSA functionality [summary_lsa]." > > > > >. > > > > >I want to know whether cisco/juniper routers (standard ones) supports > > > all of > > > > >the above extension. > > > > >or if not,how many.......or Whether router is supposed to support how many > > > > >... > > > > > > > > I do not think any vendor supports all the method mentioned above, but just > > > > a subset. If you are running a network, your feed-backs on your preferr ed > > > > method is very welcome. > > > > > > > > JP. > > > > > > > > >Regards, > > > > >---Sachin > > > > > >-- > > >Papadimitriou Dimitri > > >E-mail : dimitri.papadimitriou@alcatel.be > > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > >E-mail : dpapadimitriou@psg.com > > >Public : http://psg.com/~dpapadimitriou/ > > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > >Phone : Work: +32 3 2408491 - Home: +32 2 3434361 > > -- > Papadimitriou Dimitri > E-mail : dimitri.papadimitriou@alcatel.be > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > E-mail : dpapadimitriou@psg.com > Public : http://psg.com/~dpapadimitriou/ > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > Phone : Work: +32 3 2408491 - Home: +32 2 3434361 > From owner-mpls@UU.NET Tue Dec 10 16:15: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 QAA21216 for ; Tue, 10 Dec 2002 16:15: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 QQnsrl25613 for ; Tue, 10 Dec 2002 21:17:56 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 QQnsrk15346; Tue, 10 Dec 2002 21:12:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsrk24018 for mpls-outgoing; Tue, 10 Dec 2002 21:11:37 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 QQnsrk23966 for ; Tue, 10 Dec 2002 21:11: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 QQnsrk09622 for ; Tue, 10 Dec 2002 21:10: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 QQnsrk07377 for ; Tue, 10 Dec 2002 21:10:38 GMT Received: from mail.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc239.alcatel.be [195.207.101.239]) id QQnsrk07360 for ; Tue, 10 Dec 2002 21:10:37 GMT Received: from bemail05.net.alcatel.be (localhost [127.0.0.1]) by mail.alcatel.be (8.10.1/8.11.4) with ESMTP id gBALAVm28430; Tue, 10 Dec 2002 22:10:31 +0100 (MET) Received: from alcatel.be ([138.203.67.228]) by bemail05.net.alcatel.be (Lotus Domino Release 5.0.9a) with ESMTP id 2002121022102937:5681 ; Tue, 10 Dec 2002 22:10:29 +0100 Message-ID: <3DF65930.1F1B5188@alcatel.be> Date: Tue, 10 Dec 2002 22:14:24 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: Optical Network Architecture (NTA - Antwerpen) X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Yakov Rekhter Cc: Jean Philippe Vasseur , sachin laddha , mpls@UU.NET, ccamp@ops.ietf.org Subject: Re: Multi-Area TE Protocol Extensions References: <200212102015.gBAKFkS51587@merlot.juniper.net> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.9a |January 7, 2002) at 12/10/2002 22:10:29, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.9a |January 7, 2002) at 12/10/2002 22:10:30, Serialize complete at 12/10/2002 22:10:30 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit yakov, i think this i-d provides a fair amount of valuable input thus wouldn't be just better to submit an updated version (since the registers value should be updated anyway) also it fits imho in the context of the ccamp even more largely than just for ma-te thanks, - dimitri. Yakov Rekhter wrote: > > Dimitri, > > > > this ID does not propose a mechanism to compute inter-area TE path > > > > well i would say that either none of them does it, or all of > > them, more accurately route exclusions are applicable to any > > mpls network where full computation of the ero is not performed > > before the LSP is signaled, implying thus a "scope" for computed > > path thus among other applicable to multiple areas - nevertheless > > i agree that a next version of this i-d should probably include > > an applicability section covering this in a bit more details (see > > also section 4.1 for an example - > > > > this said and as for any other input or i-d provided on constraint- > > passing (as well as path query, btw) lot of work is still needed to > > achieve a decent first step in this effort; > > On the subject passing constraint, I'd like to mention > draft-kompella-mpls-rsvp-constraints-00.txt (expired, but I could > provide a copy upon request). It contains a fairly general mechanism > for passing constraints in RSVP. > > Yakov. > > > > > thanks, > > - dimitri. > > > > Jean Philippe Vasseur wrote: > > > > > > Hi Dimitri, > > > > > > cc'ing CCAMP - see in line, > > > > > > At 17:45 10/12/2002 +0100, Dimitri.Papadimitriou@alcatel.be wrote: > > > >jp, > > > > > > > >in fact the below list should simply be as follows for > > > >signalling-based methods: 1) constraint-passing 2) loose > > > >routing and 3) path query; > > > > > > > >and the for constraint-passing we have a several i-d's > > > >such as, > > > > > > > >http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclude-route- > 01.txt > > > > > > > > > > this ID does not propose a mechanism to compute inter-area TE path > > > > > > >constraint passing may also be extended using the crank- > > > >back as listed below; the usage scenarios of these methods > > > >are described in the following: > > > > > > > >http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-03.tx > t > > > > > > > >now probably it is worth spending some time in considering > > > >input coming from the tewg wrt to this effort, most of the > > > >input that you see listed above has been produced over the > > > >past year (and more) i can't imagine stepping in the protocol > > > >details without a clear consensus on what do we want to cover > > > >within the ccamp wg & w/o taking into account the tewg rec's > > > >(probably better to discuss this on the ccamp mailing list) > > > > > > Fully agree with you. Hopefully multi-area TE should be soon part of the > > > CCAMP charter. > > > > > > JP. > > > > > > >thanks, > > > >- dimitri. > > > > > > > >Jean Philippe Vasseur wrote: > > > > > > > > > > Hi, > > > > > > > > > > At 13:53 10/12/2002 +0530, sachin laddha wrote: > > > > > >Hi, > > > > > >'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as > > > > > >"Initial requirements are given here for protocol support of the > > > > multi-area > > > > > >TE methods, which include needs to support > > > > > > > > > > > >* path-computation-server (PCS) functionality [kompella, lee, > > > > vasseur, > > > > > >te-qos-routing], > > > > > >* query functionality [query, vasseur], > > > > > >* crankback functionality [crankback], > > > > > > > > > > > >and, optionally, > > > > > > > > > > > >* TE feedback functionality [feedback], and > > > > > >* summary-LSA functionality [summary_lsa]." > > > > > >. > > > > > >I want to know whether cisco/juniper routers (standard ones) supports > > > > all of > > > > > >the above extension. > > > > > >or if not,how many.......or Whether router is supposed to support how > many > > > > > >... > > > > > > > > > > I do not think any vendor supports all the method mentioned above, but > just > > > > > a subset. If you are running a network, your feed-backs on your preferr > ed > > > > > method is very welcome. > > > > > > > > > > JP. > > > > > > > > > > >Regards, > > > > > >---Sachin > > > > > > > >-- > > > >Papadimitriou Dimitri > > > >E-mail : dimitri.papadimitriou@alcatel.be > > > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > > >E-mail : dpapadimitriou@psg.com > > > >Public : http://psg.com/~dpapadimitriou/ > > > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > > >Phone : Work: +32 3 2408491 - Home: +32 2 3434361 > > > > -- > > Papadimitriou Dimitri > > E-mail : dimitri.papadimitriou@alcatel.be > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > E-mail : dpapadimitriou@psg.com > > Public : http://psg.com/~dpapadimitriou/ > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > Phone : Work: +32 3 2408491 - Home: +32 2 3434361 > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : Work: +32 3 2408491 - Home: +32 2 3434361 From owner-mpls@UU.NET Tue Dec 10 17:05:00 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 RAA22596 for ; Tue, 10 Dec 2002 17:04:59 -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 QQnsro16870 for ; Tue, 10 Dec 2002 22:07:52 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 QQnsro11583; Tue, 10 Dec 2002 22:05:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsro09897 for mpls-outgoing; Tue, 10 Dec 2002 22:04:42 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 QQnsro09119 for ; Tue, 10 Dec 2002 22:04:23 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 QQnsro00332 for ; Tue, 10 Dec 2002 22:04: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 QQnsro12955 for ; Tue, 10 Dec 2002 22:04:05 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 QQnsro12925 for ; Tue, 10 Dec 2002 22:04:05 GMT Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gBAM3hS62408; Tue, 10 Dec 2002 14:03:43 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200212102203.gBAM3hS62408@merlot.juniper.net> To: Dimitri.Papadimitriou@alcatel.be cc: Jean Philippe Vasseur , sachin laddha , mpls@UU.NET, ccamp@ops.ietf.org Subject: Re: Multi-Area TE Protocol Extensions In-Reply-To: Your message of "Tue, 10 Dec 2002 22:14:24 +0100." <3DF65930.1F1B5188@alcatel.be> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <86765.1039557823.1@juniper.net> Date: Tue, 10 Dec 2002 14:03:43 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Dimitri, > yakov, > > i think this i-d provides a fair amount of valuable > input thus wouldn't be just better to submit an > updated version (since the registers value should > be updated anyway) also it fits imho in the context > of the ccamp even more largely than just for ma-te I fully agree with you. I hope that the author of this i-d would be kind enough to resubmit it. Yakov. > > thanks, > - dimitri. > > Yakov Rekhter wrote: > > > > Dimitri, > > > > > > this ID does not propose a mechanism to compute inter-area TE path > > > > > > well i would say that either none of them does it, or all of > > > them, more accurately route exclusions are applicable to any > > > mpls network where full computation of the ero is not performed > > > before the LSP is signaled, implying thus a "scope" for computed > > > path thus among other applicable to multiple areas - nevertheless > > > i agree that a next version of this i-d should probably include > > > an applicability section covering this in a bit more details (see > > > also section 4.1 for an example - > > > > > > this said and as for any other input or i-d provided on constraint- > > > passing (as well as path query, btw) lot of work is still needed to > > > achieve a decent first step in this effort; > > > > On the subject passing constraint, I'd like to mention > > draft-kompella-mpls-rsvp-constraints-00.txt (expired, but I could > > provide a copy upon request). It contains a fairly general mechanism > > for passing constraints in RSVP. > > > > Yakov. > > > > > > > > thanks, > > > - dimitri. > > > > > > Jean Philippe Vasseur wrote: > > > > > > > > Hi Dimitri, > > > > > > > > cc'ing CCAMP - see in line, > > > > > > > > At 17:45 10/12/2002 +0100, Dimitri.Papadimitriou@alcatel.be wrote: > > > > >jp, > > > > > > > > > >in fact the below list should simply be as follows for > > > > >signalling-based methods: 1) constraint-passing 2) loose > > > > >routing and 3) path query; > > > > > > > > > >and the for constraint-passing we have a several i-d's > > > > >such as, > > > > > > > > > >http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclude-ro ute- > > 01.txt > > > > > > > > > > > > > this ID does not propose a mechanism to compute inter-area TE path > > > > > > > > >constraint passing may also be extended using the crank- > > > > >back as listed below; the usage scenarios of these methods > > > > >are described in the following: > > > > > > > > > >http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-0 3.tx > > t > > > > > > > > > >now probably it is worth spending some time in considering > > > > >input coming from the tewg wrt to this effort, most of the > > > > >input that you see listed above has been produced over the > > > > >past year (and more) i can't imagine stepping in the protocol > > > > >details without a clear consensus on what do we want to cover > > > > >within the ccamp wg & w/o taking into account the tewg rec's > > > > >(probably better to discuss this on the ccamp mailing list) > > > > > > > > Fully agree with you. Hopefully multi-area TE should be soon part of th e > > > > CCAMP charter. > > > > > > > > JP. > > > > > > > > >thanks, > > > > >- dimitri. > > > > > > > > > >Jean Philippe Vasseur wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > At 13:53 10/12/2002 +0530, sachin laddha wrote: > > > > > > >Hi, > > > > > > >'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as > > > > > > >"Initial requirements are given here for protocol support of the > > > > > multi-area > > > > > > >TE methods, which include needs to support > > > > > > > > > > > > > >* path-computation-server (PCS) functionality [kompella, lee , > > > > > vasseur, > > > > > > >te-qos-routing], > > > > > > >* query functionality [query, vasseur], > > > > > > >* crankback functionality [crankback], > > > > > > > > > > > > > >and, optionally, > > > > > > > > > > > > > >* TE feedback functionality [feedback], and > > > > > > >* summary-LSA functionality [summary_lsa]." > > > > > > >. > > > > > > >I want to know whether cisco/juniper routers (standard ones) suppo rts > > > > > all of > > > > > > >the above extension. > > > > > > >or if not,how many.......or Whether router is supposed to support how > > many > > > > > > >... > > > > > > > > > > > > I do not think any vendor supports all the method mentioned above, but > > just > > > > > > a subset. If you are running a network, your feed-backs on your pre ferr > > ed > > > > > > method is very welcome. > > > > > > > > > > > > JP. > > > > > > > > > > > > >Regards, > > > > > > >---Sachin > > > > > > > > > >-- > > > > >Papadimitriou Dimitri > > > > >E-mail : dimitri.papadimitriou@alcatel.be > > > > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > > > >E-mail : dpapadimitriou@psg.com > > > > >Public : http://psg.com/~dpapadimitriou/ > > > > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > > > >Phone : Work: +32 3 2408491 - Home: +32 2 3434361 > > > > > > -- > > > Papadimitriou Dimitri > > > E-mail : dimitri.papadimitriou@alcatel.be > > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > > E-mail : dpapadimitriou@psg.com > > > Public : http://psg.com/~dpapadimitriou/ > > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > > Phone : Work: +32 3 2408491 - Home: +32 2 3434361 > > > > > -- > Papadimitriou Dimitri > E-mail : dimitri.papadimitriou@alcatel.be > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > E-mail : dpapadimitriou@psg.com > Public : http://psg.com/~dpapadimitriou/ > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > Phone : Work: +32 3 2408491 - Home: +32 2 3434361 From owner-mpls@UU.NET Tue Dec 10 17:13: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 RAA22732 for ; Tue, 10 Dec 2002 17:13:12 -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 QQnsrp22900 for ; Tue, 10 Dec 2002 22:16: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 QQnsro20053; Tue, 10 Dec 2002 22:14:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsro17994 for mpls-outgoing; Tue, 10 Dec 2002 22:14: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 QQnsro17987 for ; Tue, 10 Dec 2002 22:14:01 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 QQnsro14764 for ; Tue, 10 Dec 2002 22:13: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 QQnsro05103 for ; Tue, 10 Dec 2002 22:13:11 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 QQnsro05094 for ; Tue, 10 Dec 2002 22:13:10 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBAMDcWW021130 for ; Tue, 10 Dec 2002 17:13:38 -0500 (EST) 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 RAA26823 for ; Tue, 10 Dec 2002 17:13:07 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBAMD7I03113 for mpls@uu.net; Tue, 10 Dec 2002 17:13:07 -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 QQnsro17918 for ; Tue, 10 Dec 2002 22:12: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 QQnsro18501 for ; Tue, 10 Dec 2002 22:10:59 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 QQnsro17548 for ; Tue, 10 Dec 2002 22:10:58 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 QQnsro17529 for ; Tue, 10 Dec 2002 22:10:58 GMT Received: (qmail 9675 invoked by uid 104); 10 Dec 2002 22:10:57 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4236. . Clean. Processed in 0.847449 secs); 10 Dec 2002 22:10:57 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 10 Dec 2002 22:10:56 -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 gBAMAtQ23006; Tue, 10 Dec 2002 14:10:55 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Tue, 10 Dec 2002 14:10:54 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B78@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: Shahram Davari , "'erosen@cisco.com'" , Alia Atlas Cc: mpls@UU.NET Subject: RE: Last Call on MPLS ping Date: Tue, 10 Dec 2002 14:10:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Eric, The LSP-ping text says: " In either case, the MPLS echo request would have a label stack of <1001, 23456>. (Note: in this example, 1001 is the "outer" label and 23456 is the "inner" label.)" -Shahram > -----Original Message----- > From: Shahram Davari > Sent: Tuesday, December 10, 2002 1:55 PM > To: 'erosen@cisco.com'; Alia Atlas > Cc: mpls@UU.NET > Subject: RE: Last Call on MPLS ping > > > > -----Original Message----- > > From: Eric Rosen [mailto:erosen@cisco.com] > > Sent: Monday, December 09, 2002 12:38 PM > > Alia> So, my concern here is for the case where the > > route is not an > > Alia> aggregate and the label indicates the egress > > attachment circuit as > > Alia> well as the encapsulation header for the packet. > > > > Alia> In this case, LSP ping would send an IP packet > > with the specific > > Alia> route's label and then the PSN's label. > > > > That isn't my interpretation of the draft. I think the > > intention is that > > the LSP ping carries only the "PSN label". That is, it > > carries only the > > label or labels needed to get it to the egress PE, not > > the label that > > identifies a particular VPN route (or a particular PWE3 > pseudowire). > > > > If you wanted to know not only whether a particular LSP > > leads to the > > intended PE, but also whether that PE is a proper egress > > for a particular > > VPN route (or PWE3 pseudowire), then I think you would need > > to use the FEC > > stack TLV in the body of the message to identify that VPN route. > > > > But how do you test that the VPN route is bound to the proper > PW label? > > > -Shahram > From owner-mpls@UU.NET Tue Dec 10 17:29:10 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 RAA23150 for ; Tue, 10 Dec 2002 17:29:10 -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 QQnsrq13910 for ; Tue, 10 Dec 2002 22:32:03 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 QQnsrp07853; Tue, 10 Dec 2002 22:29:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsrp19760 for mpls-outgoing; Tue, 10 Dec 2002 22:28: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 QQnsrp19752 for ; Tue, 10 Dec 2002 22:28:48 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 QQnsrp01328 for ; Tue, 10 Dec 2002 22:27: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 QQnsrp17481 for ; Tue, 10 Dec 2002 22:27:51 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 QQnsrp17475 for ; Tue, 10 Dec 2002 22:27:51 GMT Received: from cisco.com (erosen-u10.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBAMQmFp014423; Tue, 10 Dec 2002 14:26:48 -0800 (PST) Message-Id: <200212102226.gBAMQmFp014423@sj-msg-core-1.cisco.com> To: Shahram Davari cc: Alia Atlas , mpls@UU.NET Subject: Re: Last Call on MPLS ping In-reply-to: Your message of Tue, 10 Dec 2002 14:10:52 -0800. <4B6D09F3B826D411A67300D0B706EFDEB03B78@nt-exch-yow.pmc-sierra.bc.ca> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 10 Dec 2002 17:26:47 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Shahram> The LSP-ping text says: " In either case, the MPLS echo request would have a label stack of <1001, 23456>. (Note: in this example, 1001 is the "outer" label and 23456 is the "inner" label.)" Okay, so my interpretation was overly charitable ;-) Perhaps I overlooked that passage because it is obvious that it can't work that way, as Alia has pointed out in more detail. Generally one can't put the PW label or the VPN route label on the LSP ping, because the LSP egress for those labels will be a CE device. But I don't think that's a real problem, since we don't want the pings to go to the CE device. From owner-mpls@UU.NET Tue Dec 10 18:39: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 SAA24993 for ; Tue, 10 Dec 2002 18:39:54 -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 QQnsru25770 for ; Tue, 10 Dec 2002 23:42: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 QQnsru23305; Tue, 10 Dec 2002 23:41:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsru13804 for mpls-outgoing; Tue, 10 Dec 2002 23:40: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 QQnsru13791 for ; Tue, 10 Dec 2002 23:40:24 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 QQnsru10330 for ; Tue, 10 Dec 2002 23:40:19 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 QQnsru14296 for ; Tue, 10 Dec 2002 23:40:18 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 QQnsru14158 for ; Tue, 10 Dec 2002 23:40:10 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBANedDN004287 for ; Tue, 10 Dec 2002 18:40:39 -0500 (EST) 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 SAA02953 for ; Tue, 10 Dec 2002 18:40:09 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBANe9212306 for mpls@uu.net; Tue, 10 Dec 2002 18:40:09 -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 QQnsru13758 for ; Tue, 10 Dec 2002 23:39: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 QQnsru03689 for ; Tue, 10 Dec 2002 23:38:49 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 QQnsru13116 for ; Tue, 10 Dec 2002 23:38:49 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 QQnsru13106 for ; Tue, 10 Dec 2002 23:38:48 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBANdHWC004098 for ; Tue, 10 Dec 2002 18:39:18 -0500 (EST) 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 SAA02872 for ; Tue, 10 Dec 2002 18:38:47 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id SAA15866 for ; Tue, 10 Dec 2002 18:38:47 -0500 (EST) Message-Id: <200212102338.SAA15866@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Subject: Draft MPLS minutes Date: Tue, 10 Dec 2002 18:38:47 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Attached are the minutes. Many thanks to Andy Malis for taking such detailed notes. Also if you have not yet forwarded me your presentation for the proceedings, please do so now. ...George ====================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 ====================================================================== MPLS Working Group minutes Chairs: George Swallow , Loa Andersson 1. Agenda bashing 2. Fast Reroute 2a. Fast Reroute Extensions to RSVP-TE for LSP Tunnels draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt Alia Atlas This document defines extensions to and describes the use of RSVP-TE to establish backup LSP tunnels for local repair of LSP tunnels. It is a "consensus" draft that resulted from the combination of multiple prior drafts. Since the -00 version the draft was reorganized to describe LER/LSR behavior for each role in fast-reroute. Details were combined which were the same, regardless of technique used (one-to-one or facility backup) and removed redundancy. Behavior was clarified to facilitate interoperability between techniques. A number of technical modifications were made as well (see the presentation in the proceedings). The authors believe the draft is ready for working group last call. Multiple implementations currently exist. The have resolved the issues found in interoperability testing at Isocore and elsewhere. There was consensus in the room, and last call will be issued following the IETF meeting. 2b. Sven Van den Bosch Backup Record Route for Fast Reroute Techniques in RSVP-TE draft-decnodder-mpls-ero-rro-fastreroute-02.txt MPLS fast reroute is considered as a solution to protect traffic against link and node failures by re-directing the traffic locally to a backup LSP. A backup LSP can be either a detour LSP or a bypass tunnel. This document describes two methods to optimize the routing of detour LSPs such that they merge faster, a distributed method and a centralized method. The distributed method uses the Backup Record Route Object (BRRO) and the centralized method uses the Backup Explicit Route Object (BERO). There were several issues raised about the draft that were addressed in this revision. The first was support of distributed detour computation by allowing BERO to use loose hops, and the second was regarding the object length - messages could become very long. The BERO may now be "compressed" by only specifying relevant nodes. The third issue was operation with inter-area LSPs, and that was addressed with a change to the BRRO procedures. The next steps are implementation, future investigation of performance gain and label state for different network topologies. Further comments are invited on the list. They requested that this become a working group document. Scott Bradner, SUB-IP Area Director, said that any call for a working group draft in this WG must mention what in the charter it is addressing. The response is that it enhances the fast reroute extensions, which is in the charter. There was little interest in this draft expressed in the room; it will be further discussed on the list. 2c. Distinguishing link and node failures using RSVP Hellos draft-vasseur-mpls-linknode-failure-00.txt Jean-Phillipe Vasseur The aim of this draft is to provide a method to distinguish a link failure from a node failure using RSVP hello extensions. The ability to make this distinction is important when re-using link bandwidth to provide multiple protection paths (assuming that only one failure will occur at a time), which results in significant bandwidth savings. See the presentation in the proceedings for an animated tutorial on the draft's mechanisms. It also fits in the charter as a part of the fast reroute work item. The draft was requested to be accepted as a working group document. George asked if there are new procedures, or if this would be an informational draft. The answer is that it would be an information draft. Lou Berger asked how this is related to the work in GMPLS to detect node and link failures - it seems that this duplicates that work. JP said that they are complementary - you can run one or the other. It's an alternative. Scott said that given that we already have something that does this, there should be only one. Scott also said that complicated technology proposals shouldn't be made in a short presentation - people should read the draft and discuss it on the list. He would like to see discussion on the list first. Yakov Rekhter said that hello mechanisms have been overloaded to detect the liveness of both control and data planes, and he is concerned by such overloading - he feels that they should be unbundled into separate mechanisms. There was a question on how fast link or node failure can be detected. There's no way to do it faster than a round trip time, so you can't always guarantee 50 ms or any other particular time. Further discussion will be taken to the list. 3. Encapsulation Encapsulating MPLS in IP or GRE draft-rosen-mpls-in-ip-or-gre-00.txt Eric Rosen In various MPLS applications, label stacks with multiple entries are used. In some cases, it is possible to replace the top label of the stack with an IP-based encapsulation, thereby enabling the application to run over networks which do not have MPLS enabled in their core routers. This draft specifies two IP-based encapsulations, MPLS-in-IP, and MPLS-in-GRE. Each of these is applicable in some circumstances. This allows two LSRs to be "adjacent" when they are separated by an MPLS-less IP backbone. It servers a clear need for network transitions. Eric noted that the WG charter allows work in "MPLS-in-foo", so it fits in the charter. The issues are the IP encapsulation does require a "scarce" protocol number, and the GRE encapsulation doesn't use the key field or the checksum. For both, there are also MTU, TTL, QoS, and DSCP issues that are discussed. There has been support expressed on the list, and no objections. Eric proposed that it be moved forward for Proposed Standard. Scott complemented him on his presentation and said it should go ahead. We had strong consensus to make it a WG item. 4. OAM 4a. A Framework for MPLS User Plane OAM draft-allan-mpls-oam-frmwk-03.txt Dave Allan This draft discusses many of the issues associated with user plane OAM for MPLS. The goal is to provide tools to perform "in service" maintenance of LSPs. Included in this discussion is some of the implications of the MPLS architecture on the ability to support fault, diagnostic and performance management OAM applications, potential solutions for distinguishing user plane OAM, and a summary of what the authors believe can be achieved in addressing all aspects of the MPLS architecture. In his presentation, he replaced the words "user plane" with "data plane". The motivations for the draft were to explore all issues associated with instrumenting MPLS LSPs. The document outcome is to see what can be done in any given MPLS "level", and what can be done by leveraging the entire architecture. Topics covered include mechanisms for distinguishing OAM flows, return path, multi-provider issues, and OAM applications. The changes since the last version are a new section on OAM probe state association, new section on the use of hierarchy to simplify OAM, enhanced security section, and minor editorial changes. The current state of the document is that the authors feel it is largely complete. They proposed that it be adopted as a WG draft - it contains common MPLS WG input into both WG and ITU-T SG 13 efforts, and is a useful survey of the space. It would be even better with additional WG input, then it can be put to bed. Tom Nadeau said that it's a pretty reasonable document. 4b. IP-based Tool Requirements for MPLS Networks draft-nadeau-ip-basedtool-requirements-00.txt Tom Nadeau This memo describes requirements for operations and management based on IP-based tools for MPLS networks. The document scope is requirements for IP-based tools for fault detection, diagnostics, statistic reporting, and security management. The motivation is that providers have been coming to the authors with OAM requirements that differed from those that were available from both the IETF and the ITU-T, and there was a concern that current requirements did not reflect real operational environments. There were also disparately located requirements for MPLS-related OAM scattered about, and they felt it would be best to put these together into one place. The base message from providers is that they wanted an evolutionary approach rather than a revolutionary approach that might have new hardware requirements and require fork-lift upgrades in their networks (sensitive to both OPEX and CAPEX). Since they published the draft, they have received comments that will result in revisions, and they would like to move the requirements from Dave Allan's framework document, and make it a WG document. Tom asked Scott if he agreed that the requirements be combined in one place, and Scott agreed that sounded like a good idea. Jerry Ash said that some service providers have provided requirements against MPLS MIBs, and should those requirements also be applied to OAM? Tom said that some of the requirements were specific to MIB changes, but some of the others were overall requirements that do apply here as well. Dimitri Papadimitriou would like a discussion of how data plane OAM interacts with control plane mechanisms like fast reroute. Dave Allan supports getting all of the requirements in one place. 4c. Detecting MPLS Data Plane Liveness draft-ietf-mpls-lsp-ping-01.txt Kireeti Kompella This document describes a simple and efficient mechanism that can be used to detect data plane failures in MPLS 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. Changes from the last revision were the packet format was changed and a version number field was added, a "Don't Reply" reply mode was added, the reply flags were removed, and return codes were extended. RSVP session formats were modified, VPN IPv4/v6 formats were defined, L2 VPN endpoint and L2 circuits were defined, downstream mapping format was changed, and PAD and Error Code TLVs were introduced. The next step is that the base document is done for base MPLS tunnels as well as applications such as VPNs, and it is time to get it out and go to WG last call. Tom Nadeau had two questions - there's no reference in the document for the encapsulation type, and the document needs clarified on what is required to be implemented and what is optional - what's the base implementation? Kireeti said that the draft already does that, and it will be improved. Shahram Davari asked if there were requirements for this work, and Kireeti said they were implied in the draft, and there is a real problem in that we need to know if our MPLS networks are working. Tom Nadeau said the requirements draft he discussed previously also covers this draft. Kireeti also said that if something is missing, we can add it later. There was consensus for last call, and it will be issued following the meeting. George said that for the framework and requirements, he would not want them to become WG documents yet; rather, the authors should get together and see what information should go into each document and produce new higher quality revisions that can then become WG drafts. We agreed that will be the plan. 5. Load Balancing Guidelines for MPLS Load Balancing draft-allan-mpls-loadbal-00.txt Dave Allan RFC 3031 permits MPLS load balancing while making no specific representations as to implementation requirements. This has subsequently become an issue with respect to the reliability of path test mechanisms. Load balancing algorithms may separate path test probes from the path of interest. This draft proposes guidelines for implementation of load balancing such that path test mechanisms are not impacted. The motivation is that it is desirable that when multiple NHLFEs exist, that both the user traffic and any OAM probes follow the same path through the network. The goal is consistency in monitoring and fault isolation. The draft requires that for next hop selection, you not use reserved labels, don't include the "S" bit, and don't include TTL. The proposal is to obtain the sense of the WG that some solution is required, and to adopt the draft as a WG starting point. Kireeti said that this violates the principal of reproductive freedom - what's in my body is mine, and don't tell me what to do with it. This is similar to allowing implementations to do what they want for SPF. You can tell me what to put on the wire, but not how to implement it in my box. Dave agreed that what's in your box is your business, but the externally observable behavior of your box IS the issue here and is important to service providers. Kireeti said that this should be information if it is published at all, but certainly not standards track or a BCP. Dave said that anything that bounds detection time of problems in the network is good, and carriers want bounded detection times. Kireeti kept arguing that this is a paradigm change to the forwarding path. We have ECMP and it works, and it's up to each vendor to decide how they implement it. Dave said that is going to be important for PWE3 as well, since you need to bound the detection time for failures on pseudo-wires as well as for the transport LSPs. Kireeti also doesn't want any limits on label depth that were discussed in the draft. Not looking at the S bit is also bogus. Eric Rosen agrees with Kireeti's comments. While its a good OAM requirement that OAM packets need to follow the data packets, he doesn't agree with the way the document tries to do it by imposing the restrictions it does. Alia Atlas also agreed - this is a revolutionary approach rather than evolutionary approach due to the required changes in the forwarding path. It's bad to adversely affect ECMP in order to support OAM. In some cases, you don't know that length of the label stack. Dave said that the only reason he discussed label stack depth in the draft was an attempt to keep it simple. He also wanted measurement consistency on a per-node basis rather than a per-LSP basis. Shahram Davari said that this probably breaks MPLS ping. Kireeti asked the ADs at what point do we stop intruding into boxes? This came up not just here, but also in the routing area discussion on SPF implementation. He suggested that this just be published as an information RFC saying "this is a good idea". Scott said that this is really an IAB/IESG plenary discussion rather than something that should be discussed here. If the WG believes that something is wrong with the way something was done in the boxes, and the WG consists of box builders, than that's the consensus. Be he hasn't seen a consensus at the microphone for this point. There was considerable opposition to this being a WG document. Further comments will be taken to the list. 6. Bi-directional LSPs Bi-directional LSPs for Classical MPLS draft-dube-bidirectional-lsp-00.txt Rohit Dube This draft proposes extensions to support bi-directional LSPs for classical MPLS. Specifically, RSVP-TE is extended with objects similar to those in GMPLS to allow establishment of bi-directional LSPs. It's a pretty simple protocol extension to make this work. Kireeti disagrees that GMPLS is different from MPLS - it is a superset of MPLS, and bidirectional as defined in GMPLS works in MPLS as well, so this draft is unnecessary. Kireeti and Rohit discussed some the differences between the two approaches, but Kireeti felt that the GMPLS approach is sufficient for the requirements. Rahul Aggarwal had a second comment along the same lines - just use what was already done for GMPLS. George added that while it's simple to do an extension for bidirectional, it's harder to make sure it works for fast reroute and make-before-break. So he wants some though on how these other mechanisms would be supported for bidirectional as well as just the data flow. Rohit agreed that these could require some additional work. Discussion will be continued on the list. 7. MPLS Security Analysis of the Security of the MPLS Architecture draft-behringer-mpls-security-03.txt Michel Behringer This document analyses the security of the BGP/MPLS VPN architecture as described in RFC 2547, especially in comparison with other VPN technologies such as ATM and Frame Relay. The document consists of two main parts: the requirements for security in VPN services are defined, and MPLS is examined with respect to these requirements. The analysis shows that MPLS VPN networks can be equally secured as traditional layer-2 VPN networks such as ATM and Frame Relay. This was originally written as a white paper for customer consumption, and he decided to also make it available as an internet draft. The question being answered by the draft is can you operate an MPLS backbone in a secure manner. What secure means here is address space and routing separation, hiding the MPLS core structure, resistance to attacks, and impossibility of VPN spoofing. This allows MPLS to be a replacement for L2 services, like ATM and Frame Relay. It does NOT address the security of the operations of RFC 2547, such as misconfiguring VPNs and security of the implementations due to bugs. He was concentrating on the security of the architecture, but it's still possible to shoot yourself in the foot. It does not yet include Inter-AS operations. It's pretty stable. There is one open issue - during rerouting, one label too many might get popped for a short time. He's still researching this to see if it's a bug in the implementation, or a bug in the protocol. Questions: Is this useful? What is missing? Does it fit in this WG? His goal is to publish it as an informational RFC. Eric Rosen said that this addresses the issue as to whether a VPN implementation fits the requirements, and he feels it belongs in the PPVPN working group. Michael asked if this document could become a security section for RFC 2547? Eric wasn't sure if he would take that approach, but in any event, he still thinks it should be in the PPVPN WG. Dave McDysan said that this draft was used to help with the PPVPN requirements document, and he also would like to see it in the PPVPN WG - it's already been referenced. Michael said that he's already presented it there, and the answer was no at that time. Dave said that it's already been included in the PPVPN requirements. Loa said that a question heard from customers is - Is the MPLS architecture, and VPNs on top of it, secure enough to replace L2 VPN networks? Loa feels that this work is important and needed. Yakov said that this document would be a great replacement for the security section in rfc2547bis - that security section should just be a pointer to this document. Ananth Nagarajan said that this needs to be expended to cover the carriers of carriers case. Marco Carugi (PPVPN co-chair) agreed with Yakov's comments, and that it should be generalized into a complete security framework for all of the PPVPNs technologies, not just rfc2547. Scott agreed with Marco. But George feels that when it comes to security, it's better to be specific than general. George said that discussion of this document should be moved to the PPVPN email list. 8. Multicast Extended RSVP-TE for Multicast LSP Tunnels draft-yasukawa-mpls-rsvp-multicast-01.txt Allan Kullberg This document specifies extensions and mechanisms to RSVP-TE in order to support MPLS point-to-multipoint LSPs. The changes from -01 were: - All tree modifications via changed TERO - Always from sender node via Path message - Avoids race conditions - Supports Graft/Prune - Leaf Initiated Join/Leave - Leaf node sends Join/Leave message directly to sender node - Sender node sends changed TERO - Looks like single node Graft/Prune - Sequence number in TERO hop (Saves comparing entire TERO) - Terminating node flag in TERO hop - Allows node to be branch and leaf - MulticastNotify message for error indications - Error handling description The future directions are: - Add sequence # to TRRO (Saves compare of entire TRRO) - GMPLS Notify instead of McastNotify? (Reuse is good) Allan requested that this become a WG draft. Rahul said that there is a draft that describes how to do multicast in tunnels using PIM, and seems less complex. Allan said that this draft doesn't require the use of a multicast routing protocol. George asked what's the driving need that this is trying to satisfy? Allan said that this to support multicast without requiring the use of an IP multicast address as the destination. Discussion will continue on the list. 9. LDP FT/Restart draft-farrel-mpls-ldp-restart-applic-01.txt Adrian Farrell There are two drafts for recovery of LDP sessions after failures, draft-ietf-mpls-ldp-ft-06.txt and draft-ietf-mpls-ldp-restart-05.txt. These drafts have completed WG last call and have moved forward to IESG review. There is a need for information indicating which draft should be implemented and when. In addition, draft-ietf-mpls-ldp-ft also has options. Implementation choices are complex, so this draft was written to give guidance on when it is advisable to implement a LDP restart mechanism and which approach might be more suitable. The draft has expanded to contain additional background information. The draft is stable, but has a few updates still needed - in particular, Yakov had some comments that Adrian is working on. Adrian requested that this become a WG document with a view to moving forward as an informational draft. George spoke in favor of the draft. But it was a late addition to the agenda, and people need more time to read it. So people are encouraged to read it and discuss it on the list. 10. Workgroup Status 10a. LDP to Draft Standard status Loa Andersson Loa presented the current results from the LDP implementation survey. The full presentation appears in the proceedings. Some highlights follow: 12 Responses - 10 Public, 2 Anonymous. - 10 Product; 2 Beta - 11 On sale; 1 Other - Implementation Approach 7 From spec; 4 Purchased/free code + additions; 1 Purchased code. Highlights - Every item in survey questionnaire implemented by at least 2 respondents. - Each of the 8 Label Distribution Modes implemented and tested; Legend T Tested against another independent implementation I Implemented by not tested against another independent implementation N Not implemented. T I N T I N ======= ======= 8 2 2 DU, Ord Cntl, Lib Reten 6 1 5 DU, Ord Cntl, Con Reten 7 1 4 DU, Ind Cntl, Lib Reten 6 0 6 DU, Ind Cntl, Con Reten 7 1 4 DoD Ord Cntl, Cons Reten 4 3 5 DoD, Ord Cntl, Lib Reten 6 1 5 DoD, Ind Cntl, Cons Reten 4 2 6 DoD, Ind, Cntl, Lib Reten - Platform and Interface Label Spaces both widely supported. T I N T I N ======= ======= 12 0 0 Per Platform 7 1 4 Per Interface - Basic and Targeted Sessions both widely supported. T I N T I N ======= ======= 12 0 0 Basic/Directly Connected 11 1 0 Targeted - TCP MD5 Option not widely implemented. T I N ======= 3 1 8 - Interface Types T I N ======= 12 0 0 Packet 6 2 4 ATM 2 3 7 Frame Relay This will continue to be updated as responses come in, and a draft will be written summarizing how LDP is being used and if anything should be removed in order for it to become a Draft Standard. 10b. MPLS MIB review meeting report Joan Cucchiara & Tom Nadeau There was an open MPLS MIB meeting held this past Saturday in Atlanta. The agenda was: - Review of Final Changes for MIBs requested by MIB Doctors - Review Interaction between MIBs: MPLS-TC, MPLS-LSR, MPLS-LDP, MPLS-TE, MPLS-FTN, TE-TE, LINK-BUNDLING MPLS MIB Overview draft - FINAL ACTION Items for Authors Complete detail of changes are recorded at the IETF ID Tracker Site: https://datatracker.ietf.org/public/pidtracker.cgi - Many minor changes DESCRIPTION clauses Clarification of examples Editorial in nature (split REFS, IPR statement) - Very few significant changes See the presentation in the proceedings for the complete list of changes to each of the MIBs. Next steps: - Goal is to update MIBs and Overview by 12/15 (MIB co-authors) - Depends on - IESG Comments on latest MIBs - Resolution of issues on email list - Additional Working Group "LAST, LAST, LAST Call" at that time? Tom asked for clarification from the chairs on whether we need another WG last call. Loa said yes, but it would only be on the changes since the last WG last call, and on the MIBs as a group. So all six MIBs need to be ready at the same time. The overview document will be last called at the same time. If there are any additional comments that people have, please make them this week so that the MIBs can be updated by the above deadline. Loa thanked everyone that participated in the MIB review, and the MIB authors, for all of their hard work in getting the MIBs done. 10c. Status of MPLS WG Internet Drafts George Swallow George presented the status of all MPLS wg documents. The presentation is included in the proceedings. Among the drafts awaiting updates from authors was: MTU Signalling Extensions for LDP Kireeti said that the draft needs to be redone based on received comments. There should be a new version by the second week of December. George also note that it's time to move forward on draft status for the architecture, encapsulation, ATM VC switching, and RSVP-TE RFCs. Loa said that the CR-LDP decision was documented in an individual draft, was reviewed by the IESG (which returned comments), and there was a general comment on grammar. Scott will be reviewing it for grammar, after which it will be sent to the RFC Editor. From owner-mpls@UU.NET Tue Dec 10 19:57: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 TAA26339 for ; Tue, 10 Dec 2002 19:57:36 -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 QQnssa26173 for ; Wed, 11 Dec 2002 01:00: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 QQnsrz23647; Wed, 11 Dec 2002 00:59:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsrz09240 for mpls-outgoing; Wed, 11 Dec 2002 00:58:54 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 QQnsrz09228 for ; Wed, 11 Dec 2002 00:58: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 QQnsrz06717 for ; Wed, 11 Dec 2002 00:58: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 QQnsrz04577 for ; Wed, 11 Dec 2002 00:58:08 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 QQnsrz04565 for ; Wed, 11 Dec 2002 00:58:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBB0wax9010917 for ; Tue, 10 Dec 2002 19:58:36 -0500 (EST) 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 TAA06881 for ; Tue, 10 Dec 2002 19:58:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBB0w5819541 for mpls@uu.net; Tue, 10 Dec 2002 19:58:05 -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 QQnsrz09181 for ; Wed, 11 Dec 2002 00:57: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 QQnsrz00899 for ; Wed, 11 Dec 2002 00:55: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 QQnsrz20912 for ; Wed, 11 Dec 2002 00:55: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 QQnsrz20845 for ; Wed, 11 Dec 2002 00:55:49 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26278; Tue, 10 Dec 2002 19:52:52 -0500 (EST) Message-Id: <200212110052.TAA26278@ietf.org> To: IETF-Announce:; Cc: RFC Editor , Internet Architecture Board , mpls@UU.NET From: The IESG Subject: Protocol Action: Fault Tolerance for the Label Distribution Protocol (LDP) to Proposed Standard Date: Tue, 10 Dec 2002 19:52:52 -0500 Sender: owner-mpls@UU.NET Precedence: bulk The IESG has approved the Internet-Draft 'Fault Tolerance for the Label Distribution Protocol (LDP)' as a Proposed Standard. This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Scott Bradner and Bert Wijnen. Technical Summary 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 defines 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". Working Group Summary The mpls working group supported publication of this document. Protocol Quality This document was reviewed for the IESG by Scott Bradner. RFC-Editor: This IESG Note goes at the start of the document: IESG Note: This specification includes procedures for failure detection and failover for a TCP connection carrying MPLS LDP control traffic. It is limited to that application, and does not provide a general approach for using TCP connections with applications requiring fault tolerance. The specification lacks guidance for timer and retry value choices. The specification should not serve as a model for TCP fault tolerance design for any future document, and any user is advised to test any configuration based on this specification very carefully for problems such as premature failovers. From owner-mpls@UU.NET Tue Dec 10 20:15: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 UAA26798 for ; Tue, 10 Dec 2002 20:15:19 -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 QQnssb16687 for ; Wed, 11 Dec 2002 01:18: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 QQnssa02862; Wed, 11 Dec 2002 01:11:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQnssa28844 for mpls-outgoing; Wed, 11 Dec 2002 01: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 QQnssa28629 for ; Wed, 11 Dec 2002 01:10:54 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 QQnssa12428 for ; Wed, 11 Dec 2002 01:10:10 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 QQnssa17074 for ; Wed, 11 Dec 2002 01:10:09 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 QQnssa17070 for ; Wed, 11 Dec 2002 01:10:08 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBB1AbRf011919 for ; Tue, 10 Dec 2002 20:10:37 -0500 (EST) 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 UAA07456 for ; Tue, 10 Dec 2002 20:10:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBB1A6l21874 for mpls@uu.net; Tue, 10 Dec 2002 20:10:06 -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 QQnssa28066 for ; Wed, 11 Dec 2002 01:09:05 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 QQnssa08247 for ; Wed, 11 Dec 2002 01:08: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 QQnssa08031 for ; Wed, 11 Dec 2002 01:08:32 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 QQnssa08024 for ; Wed, 11 Dec 2002 01:08:31 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26548; Tue, 10 Dec 2002 20:05:35 -0500 (EST) Message-Id: <200212110105.UAA26548@ietf.org> To: IETF-Announce:; Cc: RFC Editor , Internet Architecture Board , mpls@UU.NET From: The IESG Subject: Protocol Action: Signalling Unnumbered Links in CR-LDP to Proposed Standard Date: Tue, 10 Dec 2002 20:05:35 -0500 Sender: owner-mpls@UU.NET Precedence: bulk The IESG has approved the Internet-Draft 'Signalling Unnumbered Links in CR-LDP' as a Proposed Standard. This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Scott Bradner and Bert Wijnen. Technical Summary This document defines procedures and extensions to Constraint-Routing Label Distribution Protocol (CR-LDP), one of the MPLS TE signaling protocols, that are needed in order to support unnumbered links. Supporting MPLS TE over unnumbered links (i.e., links that do not have IP addresses) involves two components: (a) the ability to carry traffic engineering (TE) information about unnumbered links in IGP TE extensions (ISIS or OSPF), and (b) the ability to specify unnumbered links in MPLS TE signaling. The focus of this document is on the latter. Working Group Summary The MPLS working group supported publication of this document. Protocol Quality This document was reviewed for the IESG by Scott Bradner. From owner-mpls@UU.NET Tue Dec 10 20:35: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 UAA27370 for ; Tue, 10 Dec 2002 20:35:53 -0500 (EST) 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 QQnsrk08959; Tue, 10 Dec 2002 21:08:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsrk23221 for mpls-outgoing; Tue, 10 Dec 2002 21:07:40 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 QQnsrk23214 for ; Tue, 10 Dec 2002 21:07: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 QQnsrk25441 for ; Tue, 10 Dec 2002 21:06:09 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 QQnsrk04205 for ; Tue, 10 Dec 2002 21:06:08 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 QQnsrk04198 for ; Tue, 10 Dec 2002 21:06:08 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBAL6bj7007071 for ; Tue, 10 Dec 2002 16:06:37 -0500 (EST) 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 QAA21038 for ; Tue, 10 Dec 2002 16:06:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBAL66A26894 for mpls@uu.net; Tue, 10 Dec 2002 16:06:06 -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 QQnsrk22724 for ; Tue, 10 Dec 2002 21:04:51 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 QQnsrk27717 for ; Tue, 10 Dec 2002 21:03:28 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 QQnsrk14954 for ; Tue, 10 Dec 2002 21:03:28 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 QQnsrk14913 for ; Tue, 10 Dec 2002 21:03:25 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 QAA41901; Tue, 10 Dec 2002 16:01:25 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212102101.QAA41901@workhorse.fictitious.org> To: mpls@UU.NET cc: curtis@fictitious.org Reply-To: curtis@fictitious.org Subject: draft-ietf-mpls-lsp-ping-01.txt - ECMP considerations Date: Tue, 10 Dec 2002 16:01:24 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk This is a consolidation of some of what I wrote as a participant in an overly long thread (appologies offered for the length of that thread) in which ECMP (among other things) were discussed. Curtis \begin{aside} An early email in this thread stated: That is not to say that no legitimate issues have been brought up. For example: 1) it is not clear to me how to handle IP src/dst hash based or MPLS label hash based load balancing, as would occur in LDP/ECMP, 2) I'm not clear on the usage of the FEC stack. I think 1) may be a deficiency, 2) is either a clarity or a feature with no clear purpose. Perhaps an example (sent to the list if not in the document) would clear up the purpose of FEC stack. [Correction: "a clarity" should be "a clarity issue".] Note that a reread of the example in 3.1 cleared up 2) for me so just the multipath (MP) issue remains. [This was my fault. I was trying to read more functionality into the FEC label stack than was intended resulting in my confusion. There is no requirement that RFCs be clear to rushed and careless readers so this is fine.] \end{aside} Rather than just paste the past mail in here, I'll summarize. I've added detail to this. There are a number of MP cases to consider: cases: 1. IP traffic at an ingress LSR is put on multiple LSPs. 2. An LSP splits traffic at one or more midpoints based on labels beneath the top label. 3. An LSP which is known to contain IP traffic (either through signaling or empirically) and that traffic path splits at one or more midpoints based on IP header information. 4. Traffic is spread over more than one reasource (for example: forwarding ASIC, switch fabric channel, external link) where the component path needs to be exposed for a thorough test. It is worth checking to see if all of these cases exist and looking at the requirements of those know to exist before adding more complexity to MPLS-ping than is needed. 1. ECMP over LDP is implemented and known to be deployed. Multipath over MPLS/TE is implemented and known to be deployed. 2. Label stack based load split is the default behavior for LDP midpoints that support ECMP and allow branching at a midpoint. No equivalent exists in MPLS/TE (the traffic must be split at the ingress, even if loose hops are specified). 3. Some router hardware is capable of looking underneath the label stack either a) only if the depth is one or b) regardless of depth, and hash based on the src/dst of the packet. I do not know if anyone takes advantage of this in a deployed network. Cases where this could be applied are: a. At an LDP node doing ECMP as an ingress to IP traffic, traffic coming in as MPLS could also be split in the same way as the ingress IP traffic if the incoming LSP is known to contain IP. b. At an LDP node not doing ECMP per se, but using a MPLS/TE tunnel split among more than one MPLS/TE LSP, could be split in the same way as the ingress IP traffic if the incoming LSP is known to contain IP. c. A PSC hop in a hierarchical MPLS/TE could be a hop over more than one LSP with same egress and an incoming LSP that is known to contain IP (in this case L3PID is available) may be split in the same way as IP traffic that enters at this ingress. 4a. Many routers today perform some operations in parallel or support multiple parallel data paths. Where the paths are deterministic, these paths could be exposed to the diagnostic and individually checked. Whether any vendor would do this is questionable. 4b. Many routers support a form of link bundling in which load split can be done by either MPLS label, or by IP header. Load split of MPLS traffic by IP header over this type of link is deployed. It might be better is responses which argue the existence or non-existence of one of the above cases be separated from responses to the technical part below. In ping mode, you start with a TTL=255 and either the egress responds, or it doesn't. If it does, then at least one path in a MP works. For MP, periodic traceroute is needed. Ideally, traceroute would yield the full set of paths. In either ping mode or traceroute mode the ingress must know: problems: 1. An address on the egress router to be placed in the IP header. 2. Whether there are multiple paths, and if so how to exercise each one. The use of a 127/8 solves problem 1) for the case of LDP where the egress is not known, for the case of a hop over a MPLS-ping incapable LSR where the following LSR is not yet known, and for the case where the packet emerges at an unexpected LSR. Problem 2) for case 1 (top of message) where the LSR is the ingress to IP traffic is trivially solved. The ingress LSR must be able to force a packet into any one of the available LSPs. The fixed 127.0.0.1 address would be fine since some minimal programming effort is already needed to force a packet with a 127/8 destination into the LSP. [Note that problem 2 is an issue if any of case 2-4 exist in real routers. As I said earlier, discussion of whether they all don't exist should be separated from discussion of the protocol bits suggested here.] Problem 2) for case 2-4 can be handled with a simple extension. We could solve this by adding a "Downstream Multipath Mapping" TLV as type 5 and Multipath Exercise TLV as type 6 (or squeeze it into 3 and 4 and renumber the current 3 and 4). Downstream Multipath Mapping TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | number of multipaths | type of multipath | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multipath Exercise TLV | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream Mapping TLV | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ..... more Multipath Exercise / Downstream Mapping TLV pairs .... . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ number of multipaths - This gives the number of multipaths and determines the number of Multipath Exercise / Downstream Mapping TLV pairs to follow unless TLV or packet size limits cause truncation. type of multipath - This gives the type of multipath split performed at the branchpoint. It also determines the format of the Multipath Exercise TLVs. Supported types are: type of multipath meaning ----------------- ------- 1 Per packet split (use of this form of multipath is highly discouraged). 2 Seeded unspecified hash based on underlying labels. 3 Seeded unspecified hash based on IP source and destination. 4 Seeded unspecified hash based on IP source and destination for stack depth of one, based on underlying labels for stack depth greater than one. 5 Other or unspecified. Any "type of multipath" which is unrecognized must be treated like type 5 and any "Multipath Exercise TLV" provided with a unrecognized "type of multipath" must be ignored. Multipath Exercise TLV Omitted for multipath type 1 (non-deterministic) and for type 5. for mulipath type 2-4: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hash Key Type | Depth Limit | MP Index |reserved (zero)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address or Next Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... Hash Key Type: IP Address or Next Label -------------- ------------------------ 1 label 1 or more label 2 IP address 1 or more IP address 3 label range 1 or more low/high label pairs 4 IP address range 1 or more low/high address pairs 5 no more labels (nothing) 6 All IP addresses (nothing) 7 no match (nothing) Depth Limit - applicable only to a label stack, the maximum number of labels considered in the hash or zero for unspecified or unlimited. MP Index - used to number the MP paths and refer to them. IP Address or Next Label - an IP address from the range 127/8 or an next label which will exercise this path are given. Use of Hash Key Type and IP Address or Next Label: -------------------------------------------------- type 1 - a list of single labels is provided, any one of which will cause the hash to match this MP path. type 2 - a list of single IP addresses is provided, any one of which will cause the hash to match this MP path. type 3 - a list of label ranges is provided, any one of which will cause the hash to match this MP path. type 4 - a list of IP address ranges is provided, any one of which will cause the hash to match this MP path. type 5 - if no more labels are provided on the stack, this MP path will apply (can only appear once). type 6 - Any IP addresses matches. Undertlying labels may go elsewhere, but all IP takes only one MP path (can only appear once). type 7 - no matches are possible given the set of "Multipath Exercise TLV" provided by prior hops. If prior hops provide a "Downstream Multipath Mapping TLV" the labels and IP addreesses should be picked from the set provided in prior "Multipath Exercise TLV" or "Hash Key Type" of 7 used. An ingress may choose to reduce the size of a "Downstream Multipath Mapping TLV" when copying into the next Echo Request as long as the Hash Key Type matching the label or IP address used to exercise the current MP is still present. This solves the problem if there is only one branch point. If there is more than one branch point, then this is not a satisfactory. This could be solved by adding to the "type of multipath" types in which the hash algoritm is specified and the seed is provided rather than an short list of addresses or labels. The ingress can then determine what addresses or labels will take each branch and either exercise the branch or determine that a branch will never be used. It is uncertain whether router makers will reveal their hash functions (I don't know if my employer will, though I personnally can't see why not), but if they do, the extension mechanism is there to support it. The only other solution is to add the ability to specify which path to check and to trace the control plane only. This would not be a satisfactory solution since a clear goal is to verify forwarding. ... Appendix of sorts - Some notes on multipath algorithms ... RFC2991 is informational and points to some requirements. It is not normative, but if a router doesn't meet the requirements the consequences (microflow reorder or poor load split) are clear and ample indication of how to avoid this is given. requirements: 1. Any multipath implementation must avoid reordering microflows. 2. Some algorithms split traffic better than others. Using the whole address rather than part of it still doesn't split microflows and balances load better. 3. Some algorithms produce a delay discontinuity for less microflows when a new member is added or deleted. The third criteria in RFC2991 is ignored by current practice. key points: 1. Per packet (send every other packet to a different interface) load split reorders the packets within microflows and is bad. [This also impacts L2VPN if reordering at egress is unsupported.] 2. The granularity of per IP perfix load split is too coarse and the resulting load split can be terrible. For example, all traffic to 18/8 (MIT) going to one interface might make for a very uneven load split on a Boston circuit. Current practice dates back to the late 1980s, possible earlier, when the PC-RT based T1-NSFNET routers did multipath by src/dst based hash. The method of hash and modulo or a specific hash designed to produce an even distribution over a number range has been used by numerous routers and remains in widespread use. From owner-mpls@UU.NET Tue Dec 10 20:52: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 UAA27655 for ; Tue, 10 Dec 2002 20:52:29 -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 QQnssd23260 for ; Wed, 11 Dec 2002 01:55: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 QQnssd19746; Wed, 11 Dec 2002 01:53:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQnssd02719 for mpls-outgoing; Wed, 11 Dec 2002 01:53:29 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 QQnssd02714 for ; Wed, 11 Dec 2002 01:53: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 QQnssd08576 for ; Wed, 11 Dec 2002 01:52: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 QQnssd27018 for ; Wed, 11 Dec 2002 01:52:12 GMT Received: from zcars04f.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQnssd27010 for ; Wed, 11 Dec 2002 01:52:11 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 gBB1pwD20858; Tue, 10 Dec 2002 20:51:58 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Dec 2002 20:51:58 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C06746B4D@zcard031.ca.nortel.com> From: "David Allan" To: curtis@fictitious.org, mpls@UU.NET Subject: RE: draft-ietf-mpls-lsp-ping-01.txt - ECMP considerations Date: Tue, 10 Dec 2002 20:51:58 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Hi Curtis: I think what you are proposing illustrates the complexity of the problem, and highlights that we need a different approach in order for detecting problems to be tractable. IMHO such constructs cannot be reliably and proactively tested from a single arbitrary upstream point and what you describe illustrates the complexity of actually performing meaningful testing. This is compounded exponentially as load spreading points are cascaded between the ingress and any point of failure. IMHO the correct answer is to proactively test from more than one point in the network and depend on the aggregate effect of the whole, and not try to produce a protocol that reverse engineers proprietary boxes. Each load spreading point should behave as a set of ingresses (from the POV of probe injection) for some low frequency of probes. You live with not necessaraily exercising all aspects of the actual load spreader but that is true for any approach that is not ICMP monotonically going through the IP address plan. This will provide bounded error detection in the network. Ideally you need some smarts to locate the probe source closest to and upstream of the point of failure once somthing goes wrong. food for thought Dave From owner-mpls@UU.NET Tue Dec 10 22:22: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 WAA29779 for ; Tue, 10 Dec 2002 22:22:15 -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 QQnssj28460 for ; Wed, 11 Dec 2002 03:25: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 QQnssj26246; Wed, 11 Dec 2002 03:24:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQnssj17207 for mpls-outgoing; Wed, 11 Dec 2002 03:23:50 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 QQnssj17199 for ; Wed, 11 Dec 2002 03:23:48 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 QQnssj16654 for ; Wed, 11 Dec 2002 03:22:28 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 QQnssj27315 for ; Wed, 11 Dec 2002 03:22:27 GMT Received: from mail.cad.zju.edu.cn by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: cad.zju.edu.cn [210.32.131.2]) id QQnssj27285 for ; Wed, 11 Dec 2002 03:22:26 GMT Received: (qmail 20144 invoked from network); 11 Dec 2002 03:28:28 -0000 Received: from unknown (HELO ultra1) (210.32.131.97) by 210.32.131.2 with SMTP; 11 Dec 2002 03:28:28 -0000 Received: from cad.zju.edu.cn (ultra1 [210.32.131.97]) by ultra1 (8.12.6/8.12.6) with ESMTP id gBB3N3p1019599; Wed, 11 Dec 2002 11:23:03 +0800 (CST) Message-ID: <3DF6AF96.FD3EECB1@cad.zju.edu.cn> Date: Wed, 11 Dec 2002 11:23:02 +0800 From: Jing Shen Reply-To: jshen@cad.zju.edu.cn Organization: State Key Lab of CAD&CG X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Eric Osborne CC: Venkata.Naidu@Marconi.com, mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: [MPLS-OPS]: Jitter and MPLS References: <39469E08BD83D411A3D900204840EC55763471@VIE-MSGUSR-01> <3DF48F65.840949E1@cad.zju.edu.cn> <20021209084638.D4090@eosborne-u10.cisco.com> <3DF5F2E9.8BE4DF71@cad.zju.edu.cn> <20021210104155.B6118@eosborne-u10.cisco.com> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > else's. but any ipdv and other such performance characteristics are > not that of the mpls architecture, but of the implementation you're > testing. I'm not sure if you agree with me or not, can you please > confirm that you do or don't? > I agree with you that MPLS architecture does not have aparent difference from IP when we are talking about forwarding performance. What I care about is , how could that affect e2e performance when we measure UDP/TCP. We consider such a protocol stack: [application protocol/TCP(UDP)/IP/MPLS], and we consider MPLS as a protocol adding values to IP networks. So, from the viewpoint of protocol processing there may be some different mechanism and implementation. I agree that different implementation has different effect on e2e performance. But, the protocol processing at LER/LSR should have the same logical procedure which is a little different from pure IP networks. What I care about is how may those changes affect the performance. From your word I come to see that our experimental result may only stick to our implementation and our experimental policy, but I'm still not clear that how could a ASIC implemention of MPLS engine compares to a ASIC implementation IP engine? Is there any measurement data or paper on this? > > > > On the other hand, if no bandwidth reservation is done: if network > > is lightly loaded there is nearly no difference in e2e delay between > > IP routing and MPLS switching, while MPLS shows bettter in IPDV; > > if network is heavy loaded MPLS behaves worse in both aspects than > > IP does. As we know, the way to control jitter is smoothing packet > > transfer > > by controling queueing behavior, and we find the overhead of IP routing > > and MPLS switching is nearly the same. This means in our testbed MPLS's > > encap/decap introduces something good to jitter control. > > > > MPLS encap/decap changing delay/jitter characteristics for better or > worse is a byproduct of the implementation. > > > We extend the result to a path consisting multi-hop because middle-LSP > > could be considered a tunnel connecting LERs, and also it directly > > applies to LSPs consisting LERs. So, if e2e qos for individual > > connection > > is considered in MPLS network, it should take the LSP which pass a path > > as highly loaded as possible. > > > > I don't get this. If you want qos, surely you want to strive for > low-load paths? > I mean, LSP should be set up along a path which is as low loaded as possible. And, also sessions for src-dst pair should chose the least loaded LSP if there are multiple LSPs available. If the LSP is not set up, it should be computed to be along the least loaded path. > >Why shoudn't we make use of those idled resource ? > > I agree. > > What does any of this have to do with policy routing, as you state > below? Why do you give the impression that policy routing is only > necessary for MPLS networks, and not IP? What, for that matter, is > policy routing? I know what I think it is, but that's because we > happen to implement a feature called "policy-based routing". I have > no idea whether this is what you refer to or not. Also, if you > continue to insist on confusing architecture with implementation, you > may want to remember that a policy routing implementation will > probably have adverse effects on delay/jitter, as there's generally > more work involved in policy-routing a packet than in normal routing > or switching or whatever of the same packet. I agree that both IP and MPLS need policy based routing ( constraint based routing), and to our implementation and experiments LER-LER switching path is more sensitive to load state. This may be only to our implementation, the reason I take it is I find that is changes with protocol stacks which is definitely affect the implementation. I'm not so clear about how those commerical implementation different from academic implementation at the fundamental theoretical level, so is there anyone could do me a favor to give some explanation or reference? Thanks a lot! regards -- Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, Z.J. 310027 P.R.China ********************************************************************** * The SunShine of life is made up of very little beams which is * * bright all the time * ********************************************************************** From owner-mpls@UU.NET Wed Dec 11 02:29: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 CAA27923 for ; Wed, 11 Dec 2002 02:29:27 -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 QQnsta04106 for ; Wed, 11 Dec 2002 07:32: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 QQnsta01156; Wed, 11 Dec 2002 07:30:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsta19352 for mpls-outgoing; Wed, 11 Dec 2002 07:30: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 QQnsta19347 for ; Wed, 11 Dec 2002 07:30:11 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 QQnssz20177 for ; Wed, 11 Dec 2002 07:29: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 QQnssz25572 for ; Wed, 11 Dec 2002 07:29:07 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 QQnssz25563 for ; Wed, 11 Dec 2002 07:29:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBB7Tats007007 for ; Wed, 11 Dec 2002 02:29:36 -0500 (EST) 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 CAA27449 for ; Wed, 11 Dec 2002 02:29:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBB7T5813560 for mpls@uu.net; Wed, 11 Dec 2002 02:29:05 -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 QQnssz19276 for ; Wed, 11 Dec 2002 07:28:25 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 QQnssz17328 for ; Wed, 11 Dec 2002 07:28:13 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 QQnssz21973 for ; Wed, 11 Dec 2002 07:28:11 GMT Received: from sj-msg-core-4.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-4.cisco.com [171.71.163.54]) id QQnssz21954 for ; Wed, 11 Dec 2002 07:28:11 GMT Received: from asimha-u10.cisco.com (asimha-u10.cisco.com [64.102.48.65]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gBB7S0Kv017684; Tue, 10 Dec 2002 23:28:00 -0800 (PST) Received: (asimha@localhost) by asimha-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id CAA01998; Wed, 11 Dec 2002 02:28:00 -0500 (EST) Date: Wed, 11 Dec 2002 02:28:00 -0500 From: Ajay Simha To: Curtis Villamizar Cc: Ajay Simha , mpls@UU.NET Subject: Re: Record Object in LSP Ping Message-ID: <20021211072800.GA1984@cisco.com> References: <20021210114444.GL677@cisco.com> <200212101718.MAA40838@workhorse.fictitious.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200212101718.MAA40838@workhorse.fictitious.org> User-Agent: Mutt/1.4i Sender: owner-mpls@UU.NET Precedence: bulk Pls disgregard my previous email. I caught up with your response to Shahram on the list. Makes sense. -ajay On Tue Dec 10 12:18:43 2002, Curtis Villamizar wrote: > > In message <20021210114444.GL677@cisco.com>, Ajay Simha writes: > > Hi, > > > > Since the LSP Ping is meant for fault detection, does anyone see any value > > in adding a record route/label TLV to this? > > This is infeasible without changing forwarding hardware so "no". > > > Each node can add (if requested) the label that the packet came in with, > > the label that this node imposed/swapped and it's LSR-ID. > > All you need is new forwarding ASICs. > > > Thanks, > > > > -ajay > > Curtis From owner-mpls@UU.NET Wed Dec 11 05:31: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 FAA00925 for ; Wed, 11 Dec 2002 05:31: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 QQnstm01473 for ; Wed, 11 Dec 2002 10:34: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 QQnstm29306; Wed, 11 Dec 2002 10:33:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQnstm27805 for mpls-outgoing; Wed, 11 Dec 2002 10:33: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 QQnstm27795 for ; Wed, 11 Dec 2002 10:33:19 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 QQnstm08750 for ; Wed, 11 Dec 2002 10:30: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 QQnstm16004 for ; Wed, 11 Dec 2002 10:30:47 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 QQnstm15995 for ; Wed, 11 Dec 2002 10:30:46 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 gBBAUkS04627; Wed, 11 Dec 2002 02:30:46 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id gBBAUki19695; Wed, 11 Dec 2002 02:30:46 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Wed, 11 Dec 2002 02:30:46 -0800 (PST) From: Kireeti Kompella To: Shahram Davari cc: Subject: RE: Last call on LSP Ping In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03B59@nt-exch-yow.pmc-sierra.bc.ca> Message-ID: <20021211022435.B19625-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Boy, I decide to take a break from reading the mpls list for a few days and I miss all the fireworks! On Fri, 6 Dec 2002, Shahram Davari wrote: > More proof: > > RFC 1812 (Requirements for IP Version 4 Routers): Let me start here, as this one is easy: > A router SHOULD NOT forward any packet that has an invalid IP > destination address or a destination address on network 0. A router > SHOULD NOT forward, except over a loopback interface, any packet that > has a destination address on network 127. A router MAY have a switch > that allows the network manager to disable these checks. If such a > switch is provided, it MUST default to performing the checks... As several people have pointed out, the ping packet with destination 127.x.y.z is *not* to be forwarded. > A router SHOULD provide a mechanism to filter out obviously invalid > routes (such as those for net 127). Clarification: this talks about filtering *routes*, not packets. So, if I were to send you a BGP route to 127/8, you're supposed to ignore it, and not install it in your forwarding table. Kireeti. From owner-mpls@UU.NET Wed Dec 11 05:39: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 FAA01024 for ; Wed, 11 Dec 2002 05:39: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 QQnstm13336 for ; Wed, 11 Dec 2002 10:42: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 QQnstm10655; Wed, 11 Dec 2002 10:41:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQnstm28291 for mpls-outgoing; Wed, 11 Dec 2002 10:40:56 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 QQnstm28284 for ; Wed, 11 Dec 2002 10:40: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 QQnstm20693 for ; Wed, 11 Dec 2002 10:40: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 QQnstm22079 for ; Wed, 11 Dec 2002 10:40:18 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 QQnstm22073 for ; Wed, 11 Dec 2002 10:40:18 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 gBBAeHS05013; Wed, 11 Dec 2002 02:40:17 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id gBBAeHj19762; Wed, 11 Dec 2002 02:40:17 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Wed, 11 Dec 2002 02:40:17 -0800 (PST) From: Kireeti Kompella To: Curtis Villamizar cc: Subject: Re: Last call on LSP Ping In-Reply-To: <200212062202.RAA23239@workhorse.fictitious.org> Message-ID: <20021211023339.K19625-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Curtis, On Fri, 6 Dec 2002, Curtis Villamizar wrote: > Maybe one of the authors can join (do they really want to?) Not really :-) > whether they would see fit to add a sentence or deem it too obvious. Saying what? "Setting the destination IP address to something from 127/8 causes some to break out in a rash, but is perfectly valid"? Kireeti. From owner-mpls@UU.NET Wed Dec 11 05:45: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 FAA01137 for ; Wed, 11 Dec 2002 05:45: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 QQnstn21831 for ; Wed, 11 Dec 2002 10:48:49 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 QQnstn18327; Wed, 11 Dec 2002 10:47:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQnstn29274 for mpls-outgoing; Wed, 11 Dec 2002 10:46: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 QQnstn29219 for ; Wed, 11 Dec 2002 10:46: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 QQnstn08265 for ; Wed, 11 Dec 2002 10:45:46 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 QQnstn19685 for ; Wed, 11 Dec 2002 10:45:45 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 QQnstn19675 for ; Wed, 11 Dec 2002 10:45:45 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 gBBAjiS05247; Wed, 11 Dec 2002 02:45:44 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id gBBAjiP19783; Wed, 11 Dec 2002 02:45:44 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Wed, 11 Dec 2002 02:45:44 -0800 (PST) From: Kireeti Kompella To: "Gray, Eric" cc: "'George Swallow'" , Subject: RE: Last call on LSP Ping In-Reply-To: <1117F7D44159934FB116E36F4ABF221B0267ED4E@celox-ma1-ems1.celoxnetworks.com> Message-ID: <20021211024125.W19625-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Eric, On Fri, 6 Dec 2002, Gray, Eric wrote: > I am a little concerned about your line of > reasoning. This usage may be "within the spirit" > of what has been specified previously, but it is > likely to result in things happening in networks > that could never have happened before. To re-iterate: a packet may have a dest IP address from 127/8 -- nothing illegal in that -- happens all the time on Unix boxes. A box receiving such a packet SHOULD NOT forward it. LSP ping actually strongly desires that the box NOT forward the packet. It's all ferpeckly legal. Kireeti. From owner-mpls@UU.NET Wed Dec 11 06:00: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 GAA01310 for ; Wed, 11 Dec 2002 06:00: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 QQnsto07055 for ; Wed, 11 Dec 2002 11:03: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 QQnsto02982; Wed, 11 Dec 2002 11:01:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsto07366 for mpls-outgoing; Wed, 11 Dec 2002 11:01:16 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 QQnsto07255 for ; Wed, 11 Dec 2002 11:01:15 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 QQnsto25766 for ; Wed, 11 Dec 2002 11:00: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 QQnsto28498 for ; Wed, 11 Dec 2002 11:00:17 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 QQnsto28487 for ; Wed, 11 Dec 2002 11:00:17 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 gBBB0GS05771; Wed, 11 Dec 2002 03:00:16 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id gBBB0GH19829; Wed, 11 Dec 2002 03:00:16 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Wed, 11 Dec 2002 03:00:16 -0800 (PST) From: Kireeti Kompella To: Curtis Villamizar cc: Subject: Re: Last call on LSP Ping In-Reply-To: <200212091832.NAA36084@workhorse.fictitious.org> Message-ID: <20021211025947.B19625-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk > So I'm still in favor of using 127/8 but think that ECMP could be done > better. Any concrete suggestions? Kireeti. From owner-mpls@UU.NET Wed Dec 11 06:07: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 GAA01394 for ; Wed, 11 Dec 2002 06:07: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 QQnsto13211 for ; Wed, 11 Dec 2002 11:10: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 QQnsto09368; Wed, 11 Dec 2002 11:08:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsto18245 for mpls-outgoing; Wed, 11 Dec 2002 11:07:28 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 QQnsto18235 for ; Wed, 11 Dec 2002 11:07: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 QQnsto18353 for ; Wed, 11 Dec 2002 11:07: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 QQnsto11826 for ; Wed, 11 Dec 2002 11:07:04 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 QQnsto11814 for ; Wed, 11 Dec 2002 11:07:03 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 gBBB73S07638; Wed, 11 Dec 2002 03:07:03 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id gBBB73620064; Wed, 11 Dec 2002 03:07:03 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Wed, 11 Dec 2002 03:07:03 -0800 (PST) From: Kireeti Kompella To: "Gray, Eric" cc: Subject: RE: Last call on LSP Ping In-Reply-To: <1117F7D44159934FB116E36F4ABF221B0267ED5B@celox-ma1-ems1.celoxnetworks.com> Message-ID: <20021211030208.B19625-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Eric, > I am suggesting that attempting to use any address range > as a mechanism for testing ECMP routes is a mistake. I don't follow. If I send ping packets with 127.0.0.1 and 127.31.41.59, the worst that can happen is that they end up on the same path. But I may get lucky and hit two paths. If I only use 127.0.0.1 (or the ALL-ROUTERS.MCAST.NET address or whatever), I am guaranteed not to test more than one path. Kireeti. From owner-mpls@UU.NET Wed Dec 11 06:13:39 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 GAA01471 for ; Wed, 11 Dec 2002 06:13:38 -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 QQnstp25181 for ; Wed, 11 Dec 2002 11:16:27 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 QQnsto19884; Wed, 11 Dec 2002 11:13:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsto19594 for mpls-outgoing; Wed, 11 Dec 2002 11:13:16 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 QQnsto19587 for ; Wed, 11 Dec 2002 11:13:12 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 QQnsto07385 for ; Wed, 11 Dec 2002 11:12: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 QQnsto17772 for ; Wed, 11 Dec 2002 11:12:54 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 QQnsto17761 for ; Wed, 11 Dec 2002 11:12:53 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 gBBBCrS07875; Wed, 11 Dec 2002 03:12:53 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id gBBBCrI20098; Wed, 11 Dec 2002 03:12:53 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Wed, 11 Dec 2002 03:12:53 -0800 (PST) From: Kireeti Kompella To: Curtis Villamizar cc: Subject: Re: Last call on LSP Ping In-Reply-To: <200212091857.NAA36364@workhorse.fictitious.org> Message-ID: <20021211030739.A19625-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Mon, 9 Dec 2002, Curtis Villamizar wrote: > > First of all I did propose using the egress IP address and setting the > > TTL=1 in the IP header. This makes sure that the LSP-ping packet will > > not get forwarded after the MPLS labels are poped. > > Glad to see this change to a technical discussion. Took a while. :-) > This proposal has two flaws, 1) when the label gets POPed and the > egress isn't the router you thought it should be the response is an > ICMP TTL expired, 2) no way to handle ECMP is proposed. Big flaw: there ain't no such thing as *the* egress router. Some router "at the other end of the network" announces a label mapping for 9/8, and this mapping makes its way to me. How do I know who the egress router is? Moreover, there could be many routers announcing 9/8 ... Kireeti. PS: IP TTL = 1 is already in the draft. From owner-mpls@UU.NET Wed Dec 11 07:07: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 HAA02245 for ; Wed, 11 Dec 2002 07:07:13 -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 QQnsts16237 for ; Wed, 11 Dec 2002 12:10: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 QQnsts13435; Wed, 11 Dec 2002 12:08:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsts11311 for mpls-outgoing; Wed, 11 Dec 2002 12:08: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 QQnsts11300 for ; Wed, 11 Dec 2002 12:07:55 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 QQnsts16401 for ; Wed, 11 Dec 2002 12:06: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 QQnsts01759 for ; Wed, 11 Dec 2002 12:06:30 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 QQnsts01751 for ; Wed, 11 Dec 2002 12:06:30 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 gBBC6TS10093; Wed, 11 Dec 2002 04:06:29 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id gBBC6T820369; Wed, 11 Dec 2002 04:06:29 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Wed, 11 Dec 2002 04:06:29 -0800 (PST) From: Kireeti Kompella To: Shahram Davari cc: Subject: RE: Last call on LSP Ping In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03B38@nt-exch-yow.pmc-sierra.bc.ca> Message-ID: <20021211033541.L19625-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Shahram, > Although I have no hope of getting any response, but here is a repeat of my ignored comments raised in March, 2002 and some new ones: Does that mean I don't have to reply? :-) > 1) Time stamp: Why is the time stamp in both seconds and microseconds? The microsecond could count up to 71 minutes. Isn't that enough? Why isn't the > same timestamp used in ICMP not used here which says: > > The Timestamp is a right-justified, 32-bit timestamp in > milliseconds since midnight UT. Is there a problem with having both seconds and microseconds? > 2) Section 3: Why the echo reply time stamp is not similar to ICMP echo-reply time-stamp in which a received time-stamp and sent-time stamp is set by the receiver? Which gives you the processing time at the receiver too. Is there a problem if the time stamp is different? > 3) Section 3.1: If I understand it correctly a Target FEC TLV could > consist of a number of FEC stack sub-TLVs. Therefore it seems that the > number of these sub-TLVs could be determined by looking at the Target > FEC TLV length field and subtracting the sub-TLV lengths from it. But > the text says it could be determined by looking at the sub-TLV length > field. Needs clarification. You just said it. > 4) Section 3.1: How can you ping multiple FECs simultaneously (i.e., piggy back multiple pings), while each FEC belongs to a different level of the label stack? This requires that all those hierarchical labels (LSPs) be initiated and terminated at the same LSRs. Also how do you intend to generate error response if the result of some of those FEC pings are positive and some are negative? Send multiple pings. > 5) Section 3 under return code. There is no return code for the case that one of the FECs fail while others pass, or when one of the label mappings don't pass, while others pass. Can you give me an example of such a case? > 6) Why doesn't the MPLS ping permit pinging multiple FECs that belong to the same LSP level? It seems that if 1000s of FECs are all mapped to the same LSP, then 1000's of MPLS-pings are required. [There is a delicious _attitude_ in the way you pose your questions.] One could do that. > 7) Why is the downstream label field in the downstream mapping TLV 24 bits? Is it for ATM? How is the 20 bit label mapped to this 24 bit? Good question. 20 bits right justified. Will clarify. > 8) Section 3.2: When X receives a packet with TTL of n>1, shouldn't it compute the downstream LSRs that could receive the packet with TTL=n-1 (rather than TTL=n+1 as indicated)? It's obvious I need to clarify this section. > 9) Section 3.2 last paragraph: Does this apply to trace-route mode only? See last para of section 4.1. > 10) Section 4.3: Does the downstream mapping TLV of the echo-reply replace the downstream mapping TLV of the echo-request or it is appended to it? As the section makes clear the fields that are copied from the echo request to the reply, it should be obvious that the downstream mapping that the receiver computes is the only one in the echo reply (i.e., replace, not append). But it doesn't hurt to say that explicitly. > 11) Section 4.5: If the egress for an FEC stack being pinged doesn't support MPLS ping, isn't an ICMP TTL expire message generated for the IP TTL=1 received (instead of no reply as mentioned in the draft)? No LSP echo reply will be sent. > 12) Section 5 2nd paragraph last sentence I think should be changed to: "Note that this may not work if some transit LSR does not support IP options" (not 'MPLS ping' as mentioned in the draft) No, it is correct as is. A router that doesn't support MPLS ping will not know how to deal with the MPLS echo reply. It would get this strange-looking packet and probably discard it. > 13) Section 5: Is RSVP-TE return path used only in "ping" mode or also in trace-route mode? Both. > 14) Section 5.3 last paragraph: I think you need to delete ICMP here. It has no meaning here. Okay. > 15) Section 5.5: I think you need to mention that if intermediate LSRs don't support refresh reduction, then it could take many minutes before the echo-reply is received at the source. Explain. > 16) Section 3.1.7 and 3.1.8: What is Encapsulation Type and how is it encoded? I'll add a reference. > 17) Section 3.2: Why are there multiple downstream labels in the downstream mapping? do they belong to different LSP levels? Or the figure is simply showing many downstream mapping TLVs? That LSR may swap and push. > 18) Section 3.3: what is the purpose of Pad TLV? To pad the ping packet, e.g., to test large packets. > 19) Section 4.3: Should an Echo reply always have a downstream mapping TLV even if no downstream mapping TLV is in the Echo request? No. > 20) Section 4.4: Seems like back to back echo-request can't be sent before receiving the echo-reply of previous echo-request. Why this limitation? Where did you read this? > 21) Section 5.1: How is the downstream mapping TLV conveyed in the echo-reply sent over RSVP-TE? it seems no downstream mapping TLV is defined for RSVP-TE. Do you think it should be added? Kireeti. From owner-mpls@UU.NET Wed Dec 11 07:22: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 HAA02567 for ; Wed, 11 Dec 2002 07:22: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 QQnstt16577 for ; Wed, 11 Dec 2002 12:25: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 QQnstt12900; Wed, 11 Dec 2002 12:23:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQnstt13376 for mpls-outgoing; Wed, 11 Dec 2002 12:23:41 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 QQnstt13371 for ; Wed, 11 Dec 2002 12:23: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 QQnstt07517 for ; Wed, 11 Dec 2002 12:22: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 QQnstt12034 for ; Wed, 11 Dec 2002 12:22:46 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 QQnstt12028 for ; Wed, 11 Dec 2002 12:22:46 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 gBBCMjS10778; Wed, 11 Dec 2002 04:22:45 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id gBBCMje20410; Wed, 11 Dec 2002 04:22:45 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Wed, 11 Dec 2002 04:22:45 -0800 (PST) From: Kireeti Kompella To: Shahram Davari cc: Subject: RE: Last call on LSP Ping In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03B44@nt-exch-yow.pmc-sierra.bc.ca> Message-ID: <20021211041157.N19625-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Shahram, On Thu, 5 Dec 2002, Shahram Davari wrote: > 22) I can't understand section 3.2 at all. Since TTL=n+1 makes no sense, for the sake of argument I'll assume you meant TTL=n-1. Now let's assume the following topology: It's quite simple: read "initial TTL=n>1", "initial TTL=n+1", etc. > L1 L2 L3 > -------R1-------R2-------R3 > \ L4 > \-----R4 > > In which R1, R2, R3, and R4 are LSRs and L1, L2, L3 and L4 are each a > set of labels that are received on those LSRs. Correction: L1, ... L4 are all label mappings for a given FEC. Also, R3 and R4 are equidistant from R2. To make this more exciting, add an R5 with label L5 such that R5's metric from R2 is bigger than R3's. > It seems from the text that the following sequential behavior is expected: (DM means Downstream Mapping TLV) > > Ingress => Echo Request: DM (R1, L1) > R1 => Echo Reply : DM (R2, L2) > Ingress => Echo Request: DM (R2, L2) > R2 => Echo Reply : DM (R3, L3 and R4, L4) > Ingress => Echo Request: DM (R3, L3 and R4, L4) > etc. > > Is this the behavior that is intended? And does it apply only to trace-route? Yes (with the changes above), and yes. > What is the purpose of this function? it seems that DM is being used to extract the > whole switching table of each interface, is that correct? If so, then it is neither ping, nor trace-route? No, just the label bindings for a given FEC. > 23) section 4.1: In order to exercise all the ECMP paths, you need to > scan through all 127/8 addresses (16 million of them), don't you think > this is not feasible? "The difficult, we do immediately. The impossible takes a little longer." > 24) Section 4.1: Why should an LSR send multiple echo requests with the same seq#? What function is in mind that can't be achieved by incrementing seq #? To increase the probability of receipt of a ping with a given sequence number. Kireeti. From owner-mpls@UU.NET Wed Dec 11 07:31: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 HAA02662 for ; Wed, 11 Dec 2002 07:31:28 -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 QQnstu09957 for ; Wed, 11 Dec 2002 12:34: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 QQnstu06293; Wed, 11 Dec 2002 12:32:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQnstu14029 for mpls-outgoing; Wed, 11 Dec 2002 12:31: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 QQnstu14024 for ; Wed, 11 Dec 2002 12:31:53 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 QQnstu21405 for ; Wed, 11 Dec 2002 12:31:05 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 QQnstu04935 for ; Wed, 11 Dec 2002 12:31:05 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 QQnstu04911 for ; Wed, 11 Dec 2002 12:31:04 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 gBBCV4S11082; Wed, 11 Dec 2002 04:31:04 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id gBBCV4E20438; Wed, 11 Dec 2002 04:31:04 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Wed, 11 Dec 2002 04:31:04 -0800 (PST) From: Kireeti Kompella To: Eric Rosen cc: George Swallow , Subject: Re: Last call on LSP Ping In-Reply-To: <200212052229.gB5MTGK0027806@sj-msg-core-1.cisco.com> Message-ID: <20021211042517.U19625-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Eric, On Thu, 5 Dec 2002, Eric Rosen wrote: > Re the last call on "LSP Ping", I have a few questions and comments on the > ping functionality. > > >From section 4.1: > > > An MPLS echo request is a (possibly) labelled UDP packet. The IP > header is set as follows: the source IP address is a routable address > of the sender; the destination IP address is a (randomly chosen) > address from 127/8; the IP TTL is set to 1. The source UDP port is > chosen by the sender; the destination UDP port is set to 3503 > (assigned by IANA for MPLS echo requests). If the echo request is > labelled, the MPLS TTL on all the labels except the outermost should > be set to 1. > > Although this suggests that the MPLS echo request might be sent as an > unlabeled UDP datagram, that doesn't actually seem possible. If you try to > send a UDP datagram to 127.0.0.1 it won't go very far. (In fact, RFC 3330 > seems to make it illegal to send over the network an IP packet whose address > is in the range 127/8. Whether it makes it illegal to send such packets > encapsulated is less clear.) So I think it is REQUIRED that the echo > request be labeled. Actually, I think the requirements are: > > - The originator of the echo request decides to test a FEC or a stack of > FECs. > > - The originator determines the next hop for that FEC, or for the topmost > FEC in the stack. > > - The originator labels the echo request with the label stack that is used > for sending packets with that FEC via that next hop. > > - The originator sends the labeled echo request to that next hop. (If > reaching the next hop requires going through an LSP tunnel, this might > causes more labels to be pushed on the stack.) As I said in an earlier reply, what if the LSP is a one-hopper, with PHP? > It would also be nice if the document were more explicit about what sorts of > error conditions elicit what sorts of responses. If you get no response, > you can conclude that one of the following conditions holds: > > - The label stack you put on the echo request did not get the UDP datagram > delivered a node in your network which supports LSP Ping. > > - The echo response couldn't be delivered for some reason. (The option for > replying via the control plane is intended to eliminate this possibility.) Yes. > If the UDP datagram does end up, unlabeled, somewhere where LSP Ping is > understood, then the 127/8 address will cause it to be processed at that > point. Presumably the responder is supposed to look at the stack of FECs, > and determine whether it is an LSP egress for each FEC in the stack. If so, > it responds with a return code of 3; otherwise with a return code of 4. (I'm > ignoring the "downstream router" stuff for now.) > > So if you get a response with a return code of 3, you know that it is > possible to get MPLS packets to the responder, and that the responder is the > right place to be sending packets that are in the specified FEC or stack of > FECs. If you get a response with a return code of 4, you know that > something has gone wrong somewhere, your labeled packets are going > someplace other than where they are supposed to go, and you'd better do > something right away. Yes. > The suggestion to randomly choose IP destination addresses from the 127/8 > block is, presumably, the way to ensure that the various paths created by > equal cost load splitting get exercised. The question is, how many pings do > you need to send in order to get good coverage? We've beaten this one to death. Suggestions are most welcome. > If the request has a stack of n FECs, and the responder is the egress for > the topmost m FECs but not for the bottommost n-m, it might be useful to > have a way to indicate that in the response. True. Someone else pointed this out -- will fix. > Some minor observations: > > - The notion of "time of day" is not well-defined. I have no idea what is > supposed to be put in the time of day fields. This doesn't really seem > that useful anyway unless there is synchronized time. Seconds and microseconds since 00:00:00.0, Jan 1, 1970, UTC? > - I'm not sure that the sequence number really needs to be a separate field > from the sender's handle. It just seems like an extension of the handle, > whose semantics are private to the sender. Same as for regular ping. Kireeti. From owner-mpls@UU.NET Wed Dec 11 07:45:01 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 HAA02815 for ; Wed, 11 Dec 2002 07:45:01 -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 QQnstv13212 for ; Wed, 11 Dec 2002 12:47: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 QQnstv08116; Wed, 11 Dec 2002 12:45:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQnstv15107 for mpls-outgoing; Wed, 11 Dec 2002 12:45: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 QQnstv15096 for ; Wed, 11 Dec 2002 12:45:17 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 QQnstu06054 for ; Wed, 11 Dec 2002 12:44: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 QQnstu27844 for ; Wed, 11 Dec 2002 12:44:57 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 QQnstu27833 for ; Wed, 11 Dec 2002 12:44:56 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 gBBCiuS11467; Wed, 11 Dec 2002 04:44:56 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id gBBCith20464; Wed, 11 Dec 2002 04:44:56 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Wed, 11 Dec 2002 04:44:55 -0800 (PST) From: Kireeti Kompella To: George Swallow cc: Subject: Re: Last call on LSP Ping In-Reply-To: <200212060001.TAA24892@bifocal.cisco.com> Message-ID: <20021211043429.K19625-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi George, > I think you're really only testing one FEC. The stack gives you a way > of noting how you set off the get to that FEC (assuming you had > multiple options - like two TE tunnels). Sometimes you're testing just the one FEC, sometimes you're really testing the stack. Say you're testing prefix 10/8 in VPN foo, and it so happens that you go over LSP bar. You don't really care, you create a ping packet with target FEC "10/8 in VPN foo", slap a label stack on it, and off it goes. However, suppose you learned 10/8 in VPN foo from two PEs (dual-homed CE), with LSPs bar1 and bar2. You may want to test each independently. So, in one case you'd have a target FEC stack of "LSP bar1; 10/8 in VPN foo" and in the other case, "LSP bar2; 10/8 in VPN foo". Does that make sense? Kireeti. From owner-mpls@UU.NET Wed Dec 11 10:28: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 KAA08854 for ; Wed, 11 Dec 2002 10:28:54 -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 QQnsug15638 for ; Wed, 11 Dec 2002 15:31:43 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 QQnsuf08778; Wed, 11 Dec 2002 15:28:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsuf23427 for mpls-outgoing; Wed, 11 Dec 2002 15:28: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 QQnsuf23422 for ; Wed, 11 Dec 2002 15:27: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 QQnsuf17467 for ; Wed, 11 Dec 2002 15:27: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 QQnsuf07660 for ; Wed, 11 Dec 2002 15:27:17 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 QQnsuf07655 for ; Wed, 11 Dec 2002 15:27:17 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 11 Dec 2002 10:27:16 -0500 Message-ID: <1117F7D44159934FB116E36F4ABF221B0267ED95@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'Kireeti Kompella'" Cc: mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Wed, 11 Dec 2002 10:27:16 -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 Kireeti, The main issue is that this approach is actually unlikely to result in full coverage of all ECMP paths. I would need to send PING packets to more than half of the entire address range in order to be certain of full coverage in the simplest case in which there are only two alternative paths. And that would only work if I know for certain that the destination IP address of the PING packets is being used in the ECMP hash function. In fact, given the objections I have stated already in other mail (which you will likely see as you catch up on this thread), this "door-to-door PING" approach is not very likely to provide coverage for more than one path for most ECMP/MPLS implementations and LSPs. However, the mere fact that it is included may suggest to some that it will work in some cases. Since this is certainly not true, it is misleading as well as not particularly useful. I frankly see little point in including something in a specification that is so very likely to require a later "considered dangerous" RFC. I actually think that Curtis is on the right track with his proposal. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Wednesday, December 11, 2002 6:07 AM > To: Gray, Eric > Cc: mpls@UU.NET > Subject: RE: Last call on LSP Ping > > Hi Eric, > > > I am suggesting that attempting to use any address range > > as a mechanism for testing ECMP routes is a mistake. > > I don't follow. If I send ping packets with 127.0.0.1 and 127.31.41.59, > the worst that can happen is that they end up on the same path. But > I may get lucky and hit two paths. If I only use 127.0.0.1 (or the > ALL-ROUTERS.MCAST.NET address or whatever), I am guaranteed not to > test more than one path. > > Kireeti. From owner-mpls@UU.NET Wed Dec 11 10:31: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 KAA08998 for ; Wed, 11 Dec 2002 10:31:31 -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 QQnsug13807 for ; Wed, 11 Dec 2002 15:34: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 QQnsug10757; Wed, 11 Dec 2002 15:32:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsug23728 for mpls-outgoing; Wed, 11 Dec 2002 15:32:20 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 QQnsug23704 for ; Wed, 11 Dec 2002 15:32:11 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 QQnsug07857 for ; Wed, 11 Dec 2002 15:31:49 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 QQnsug15844 for ; Wed, 11 Dec 2002 15:31:48 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 QQnsug15825 for ; Wed, 11 Dec 2002 15:31:48 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 11 Dec 2002 10:31:47 -0500 Message-ID: <1117F7D44159934FB116E36F4ABF221B0267ED96@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'Kireeti Kompella'" , Eric Rosen Cc: George Swallow , mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Wed, 11 Dec 2002 10:31:47 -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 > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Wednesday, December 11, 2002 7:31 AM > To: Eric Rosen > Cc: George Swallow; mpls@UU.NET > Subject: Re: Last call on LSP Ping > > ... > > > The suggestion to randomly choose IP destination addresses from > > the 127/8 block is, presumably, the way to ensure that the > > various paths created by equal cost load splitting get exercised. > > The question is, how many pings do you need to send in order to > > get good coverage? > > We've beaten this one to death. Suggestions are most welcome. Actually, I wish we had beaten this one to death - it surely needs to die... :-) For suggestions, see Curtis Villamizar's proposal. > > > ... > > Kireeti. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 From owner-mpls@UU.NET Wed Dec 11 10:49:18 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 KAA09650 for ; Wed, 11 Dec 2002 10:49:17 -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 QQnsuh13054 for ; Wed, 11 Dec 2002 15:52: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 QQnsuh01951; Wed, 11 Dec 2002 15:46:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsuh25293 for mpls-outgoing; Wed, 11 Dec 2002 15:46: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 QQnsuh25186 for ; Wed, 11 Dec 2002 15:46:07 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 QQnsug03743 for ; Wed, 11 Dec 2002 15:44: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 QQnsug24280 for ; Wed, 11 Dec 2002 15:44:25 GMT Received: from kanmx1.ca.alcatel.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: m115-138.on.tac.net [209.202.115.138] (may be forged)) id QQnsug24272 for ; Wed, 11 Dec 2002 15:44:24 GMT Received: (qmail 27800 invoked from network); 11 Dec 2002 15:50:27 -0000 Received: (ofmipd 138.120.118.71); 11 Dec 2002 15:50:05 -0000 Received: from alcatel.com ([138.120.62.58]) by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA7506; Wed, 11 Dec 2002 10:44:20 -0500 Date: 11 Dec 2002 10:43:41 -0500 Message-ID: <3DF75D2D.4BE2F8BF@alcatel.com> From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com To: Dimitri.Papadimitriou@alcatel.be Cc: "Jean Philippe Vasseur" , "sachin laddha" , mpls@UU.NET, ccamp@ops.ietf.org X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Multi-Area TE Protocol Extensions References: <4.3.2.7.2.20021210090846.06284110@paris.cisco.com> <4.3.2.7.2.20021210123021.0382fe10@paris.cisco.com> <3DF643DF.4F8AC12C@alcatel.be> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dimitri, JP, While I think an applicability section/statement is fine, I'm not sure if a mechanism to compute inter-area TE path belong in this ID. We did include applications in the first discussion of this ID and in the slides http://www.ietf.org/proceedings/02mar/slides/ccamp-6/index.html and in addressing Kireeti's suggestion to include a discussion on the impact of message size, we provided an inter-area example for illustration purposes. However, there have also been suggestions in the past to not discuss applications specifically in the draft itself. I am fine with either way. thanks cheng-yin Dimitri.Papadimitriou@alcatel.be wrote: > jp, > > > this ID does not propose a mechanism to compute inter-area TE path > > well i would say that either none of them does it, or all of > them, more accurately route exclusions are applicable to any > mpls network where full computation of the ero is not performed > before the LSP is signaled, implying thus a "scope" for computed > path thus among other applicable to multiple areas - nevertheless > i agree that a next version of this i-d should probably include > an applicability section covering this in a bit more details (see > also section 4.1 for an example - > > this said and as for any other input or i-d provided on constraint- > passing (as well as path query, btw) lot of work is still needed to > achieve a decent first step in this effort; > > thanks, > - dimitri. > > Jean Philippe Vasseur wrote: > > > > Hi Dimitri, > > > > cc'ing CCAMP - see in line, > > > > At 17:45 10/12/2002 +0100, Dimitri.Papadimitriou@alcatel.be wrote: > > >jp, > > > > > >in fact the below list should simply be as follows for > > >signalling-based methods: 1) constraint-passing 2) loose > > >routing and 3) path query; > > > > > >and the for constraint-passing we have a several i-d's > > >such as, > > > > > >http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclude-route-01.txt > > > > > > > this ID does not propose a mechanism to compute inter-area TE path > > > > >constraint passing may also be extended using the crank- > > >back as listed below; the usage scenarios of these methods > > >are described in the following: > > > > > >http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-03.txt > > > > > >now probably it is worth spending some time in considering > > >input coming from the tewg wrt to this effort, most of the > > >input that you see listed above has been produced over the > > >past year (and more) i can't imagine stepping in the protocol > > >details without a clear consensus on what do we want to cover > > >within the ccamp wg & w/o taking into account the tewg rec's > > >(probably better to discuss this on the ccamp mailing list) > > > > Fully agree with you. Hopefully multi-area TE should be soon part of the > > CCAMP charter. > > > > JP. > > > > >thanks, > > >- dimitri. > > > > > >Jean Philippe Vasseur wrote: > > > > > > > > Hi, > > > > > > > > At 13:53 10/12/2002 +0530, sachin laddha wrote: > > > > >Hi, > > > > >'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as > > > > >"Initial requirements are given here for protocol support of the > > > multi-area > > > > >TE methods, which include needs to support > > > > > > > > > >* path-computation-server (PCS) functionality [kompella, lee, > > > vasseur, > > > > >te-qos-routing], > > > > >* query functionality [query, vasseur], > > > > >* crankback functionality [crankback], > > > > > > > > > >and, optionally, > > > > > > > > > >* TE feedback functionality [feedback], and > > > > >* summary-LSA functionality [summary_lsa]." > > > > >. > > > > >I want to know whether cisco/juniper routers (standard ones) supports > > > all of > > > > >the above extension. > > > > >or if not,how many.......or Whether router is supposed to support how many > > > > >... > > > > > > > > I do not think any vendor supports all the method mentioned above, but just > > > > a subset. If you are running a network, your feed-backs on your preferred > > > > method is very welcome. > > > > > > > > JP. > > > > > > > > >Regards, > > > > >---Sachin > > > > > >-- > > >Papadimitriou Dimitri > > >E-mail : dimitri.papadimitriou@alcatel.be > > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > >E-mail : dpapadimitriou@psg.com > > >Public : http://psg.com/~dpapadimitriou/ > > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > >Phone : Work: +32 3 2408491 - Home: +32 2 3434361 > > -- > Papadimitriou Dimitri > E-mail : dimitri.papadimitriou@alcatel.be > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > E-mail : dpapadimitriou@psg.com > Public : http://psg.com/~dpapadimitriou/ > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > Phone : Work: +32 3 2408491 - Home: +32 2 3434361 From owner-mpls@UU.NET Wed Dec 11 11: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 LAA11013 for ; Wed, 11 Dec 2002 11:26:22 -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 QQnsuj02797 for ; Wed, 11 Dec 2002 16:29:11 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 QQnsuj26281; Wed, 11 Dec 2002 16:25:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsuj16917 for mpls-outgoing; Wed, 11 Dec 2002 16:25: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 QQnsuj16892 for ; Wed, 11 Dec 2002 16:25:04 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 QQnsuj23082 for ; Wed, 11 Dec 2002 16:24: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 QQnsuj05552 for ; Wed, 11 Dec 2002 16:24:12 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 QQnsuj05547 for ; Wed, 11 Dec 2002 16:24:12 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBBGOf9N008306 for ; Wed, 11 Dec 2002 11:24:41 -0500 (EST) 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 LAA24335 for ; Wed, 11 Dec 2002 11:24:10 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBBGO5e17366 for mpls@uu.net; Wed, 11 Dec 2002 11:24:05 -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 QQnsuj16791 for ; Wed, 11 Dec 2002 16:22:51 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 QQnsuj20655 for ; Wed, 11 Dec 2002 16:22: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 QQnsuj09131 for ; Wed, 11 Dec 2002 16:22:18 GMT Received: from father.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQnsuj09126 for ; Wed, 11 Dec 2002 16:22:17 GMT Received: (qmail 24864 invoked by uid 104); 11 Dec 2002 16:22:17 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4236. . Clean. Processed in 0.639205 secs); 11 Dec 2002 16:22:17 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 11 Dec 2002 16:22:15 -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 gBBGMFQ17123; Wed, 11 Dec 2002 08:22:15 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Wed, 11 Dec 2002 08:22:15 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B7C@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Kireeti Kompella'" Cc: mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Wed, 11 Dec 2002 08:22:13 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Thanks Kireeti. Understood and accepted. -Shahram > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Wednesday, December 11, 2002 5:31 AM > To: Shahram Davari > Cc: mpls@UU.NET > Subject: RE: Last call on LSP Ping > > > Boy, I decide to take a break from reading the mpls list for a few > days and I miss all the fireworks! > > On Fri, 6 Dec 2002, Shahram Davari wrote: > > > More proof: > > > > RFC 1812 (Requirements for IP Version 4 Routers): > > Let me start here, as this one is easy: > > > A router SHOULD NOT forward any packet that has an invalid IP > > destination address or a destination address on network > 0. A router > > SHOULD NOT forward, except over a loopback interface, > any packet that > > has a destination address on network 127. A router MAY > have a switch > > that allows the network manager to disable these checks. > If such a > > switch is provided, it MUST default to performing the checks... > > As several people have pointed out, the ping packet with destination > 127.x.y.z is *not* to be forwarded. > > > A router SHOULD provide a mechanism to filter out > obviously invalid > > routes (such as those for net 127). > > Clarification: this talks about filtering *routes*, not packets. > So, if I were to send you a BGP route to 127/8, you're supposed to > ignore it, and not install it in your forwarding table. > > Kireeti. > From owner-mpls@UU.NET Wed Dec 11 11:28: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 LAA11151 for ; Wed, 11 Dec 2002 11:28:29 -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 QQnsuk24344 for ; Wed, 11 Dec 2002 16:31:22 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 QQnsuj10652; Wed, 11 Dec 2002 16:24:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsuj16851 for mpls-outgoing; Wed, 11 Dec 2002 16:23:53 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 QQnsuj16842 for ; Wed, 11 Dec 2002 16:23:49 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 QQnsuj20107 for ; Wed, 11 Dec 2002 16:23:15 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 QQnsuj05045 for ; Wed, 11 Dec 2002 16:23:14 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 QQnsuj05032 for ; Wed, 11 Dec 2002 16:23:14 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBBGNh6c008114 for ; Wed, 11 Dec 2002 11:23:43 -0500 (EST) 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 LAA24249 for ; Wed, 11 Dec 2002 11:23:13 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBBGNCs17311 for mpls@uu.net; Wed, 11 Dec 2002 11:23:12 -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 QQnsuj16767 for ; Wed, 11 Dec 2002 16:22: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 QQnsuj14555 for ; Wed, 11 Dec 2002 16:19:56 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 QQnsuj07193 for ; Wed, 11 Dec 2002 16:19:55 GMT Received: from father.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQnsuj07172 for ; Wed, 11 Dec 2002 16:19:54 GMT Received: (qmail 23579 invoked by uid 104); 11 Dec 2002 16:19:50 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4236. . Clean. Processed in 1.012354 secs); 11 Dec 2002 16:19:50 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 11 Dec 2002 16:19:49 -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 gBBGJnQ15795; Wed, 11 Dec 2002 08:19:49 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Wed, 11 Dec 2002 08:19:48 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B7B@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Kireeti Kompella'" Cc: mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Wed, 11 Dec 2002 08:19:43 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Kireeti, Thanks for (finally :)) replying to my comments. Some follow ups: > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Wednesday, December 11, 2002 7:06 AM > To: Shahram Davari > Cc: mpls@UU.NET > Subject: RE: Last call on LSP Ping > > > Hi Shahram, > > > Although I have no hope of getting any response, but here > is a repeat of my ignored comments raised in March, 2002 and > some new ones: > > Does that mean I don't have to reply? :-) > > > 1) Time stamp: Why is the time stamp in both seconds and > microseconds? The microsecond could count up to 71 minutes. > Isn't that enough? Why isn't the > > same timestamp used in ICMP not used here which says: > > > > The Timestamp is a right-justified, 32-bit timestamp in > > milliseconds since midnight UT. > > Is there a problem with having both seconds and microseconds? It seems redundant and not needed. > > > 2) Section 3: Why the echo reply time stamp is not similar > to ICMP echo-reply time-stamp in which a received time-stamp > and sent-time stamp is set by the receiver? Which gives you > the processing time at the receiver too. > > Is there a problem if the time stamp is different? Since people are familiar with ICMP, and there is no specific reason for introducing a new notion for time stamping, it seems logical to stick to the same format. It is like inventing a different CRC-32 for each new protocol. If the purpose is the same, then let's use what we already have. > > > 3) Section 3.1: If I understand it correctly a Target FEC TLV could > > consist of a number of FEC stack sub-TLVs. Therefore it > seems that the > > number of these sub-TLVs could be determined by looking at > the Target > > FEC TLV length field and subtracting the sub-TLV lengths > from it. But > > the text says it could be determined by looking at the > sub-TLV length > > field. Needs clarification. > > You just said it. Thanks. Appreciate if you could make it more clear in the text. > > > 4) Section 3.1: How can you ping multiple FECs > simultaneously (i.e., piggy back multiple pings), while each > FEC belongs to a different level of the label stack? This > requires that all those hierarchical labels (LSPs) be > initiated and terminated at the same LSRs. Also how do you > intend to generate error response if the result of some of > those FEC pings are positive and some are negative? > > Send multiple pings. But the text says you could send a ping with multiple FEC (aka FEC stack)! My comment was that sending multiple FECs (belonging to different LSP levels) in a single ping applies only to cases where those FECs originate and terminate at the same LSR (e.g., L2VPN and L3VPN). Also what happens if a few of the FECs are matched but others are not, what is the error code? Another point is regarding the example given in the draft that Eric Rosen also agrees is not accurate. By that I mean in L2VPN and L3VPN it is better not to push the PW/VPN label, but only push PSN label. However, to test the binding between the PW/VPN label and the VPN route I suggest adding the PW/PSN label to the VPN IPV4 and IPV6 prefix as following: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Distinguisher | | (8 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW/PSN Label | Must be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Distinguisher | | (8 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 prefix | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW/PSN Label | Must be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > 5) Section 3 under return code. There is no return code for > the case that one of the FECs fail while others pass, or when > one of the label mappings don't pass, while others pass. > > Can you give me an example of such a case? In the example of section 3.1, where it says: " Alternatively, X can send a FEC Stack TLV with two FECs, the first of type LDP IPv4 with a prefix of 192.168.1.1/32 and the second of type of IP VPN with a prefix 10/8 in VPN foo. " What happens if the 192.168.1.1/32 is the correct prefix for that egress but prefix 10/8 is not recognized or does not correspond to the "inner label" ? > > > 6) Why doesn't the MPLS ping permit pinging multiple FECs > that belong to the same LSP level? It seems that if 1000s of > FECs are all mapped to the same LSP, then 1000's of > MPLS-pings are required. > > [There is a delicious _attitude_ in the way you pose your questions.] > > One could do that. Thanks. My suggestion is to let each FEC element in the FEC stack be an FEC stack itself, in which each FEC in that stack corresponds to one of the FECs bound to that LSP. > > > 7) Why is the downstream label field in the downstream > mapping TLV 24 bits? Is it for ATM? How is the 20 bit label > mapped to this 24 bit? > > Good question. 20 bits right justified. Will clarify. Thanks. To support ATM (28-bit VPI/VCI) and FR (10-bit or 23-bit DLCI) may I suggest changing the size of the Downstream label to 28 bits and right justifying any ATM/FR/MPLS label in this field as following: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream IPv4 Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU | Address Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream Label |Protoco| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream Label |Protoco| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > 8) Section 3.2: When X receives a packet with TTL of n>1, > shouldn't it compute the downstream LSRs that could receive > the packet with TTL=n-1 (rather than TTL=n+1 as indicated)? > > It's obvious I need to clarify this section. Thanks. > > > 9) Section 3.2 last paragraph: Does this apply to > trace-route mode only? > > See last para of section 4.1. May be it is best if you could add a single sentence to 3.1 to say that this applies to trace-route only. > > > 10) Section 4.3: Does the downstream mapping TLV of the > echo-reply replace the downstream mapping TLV of the > echo-request or it is appended to it? > > As the section makes clear the fields that are copied from the echo > request to the reply, it should be obvious that the downstream mapping > that the receiver computes is the only one in the echo reply (i.e., > replace, not append). But it doesn't hurt to say that explicitly. Thanks. > > > 11) Section 4.5: If the egress for an FEC stack being > pinged doesn't support MPLS ping, isn't an ICMP TTL expire > message generated for the IP TTL=1 received (instead of no > reply as mentioned in the draft)? > > No LSP echo reply will be sent. I think I answered my question. If 127/8 is used then no ICMP TTL expire will be generated. > > > 12) Section 5 2nd paragraph last sentence I think should be > changed to: "Note that this may not work if some transit LSR > does not support IP options" (not 'MPLS ping' as mentioned in > the draft) > > No, it is correct as is. A router that doesn't support MPLS > ping will not > know how to deal with the MPLS echo reply. It would get this > strange-looking packet and probably discard it. OK. > > > 13) Section 5: Is RSVP-TE return path used only in "ping" > mode or also in trace-route mode? > > Both. In both cases what happens if the packet is misrouted? the RSVP RESV will be returned to a different ingress ! > > > 14) Section 5.3 last paragraph: I think you need to delete > ICMP here. It has no meaning here. > > Okay. > > > 15) Section 5.5: I think you need to mention that if > intermediate LSRs don't support refresh reduction, then it > could take many minutes before the echo-reply is received at > the source. > > Explain. LSP-ping using the RSVP return path should have refresh reduction enabled: meaning a refresh should be generated immediately in all intermediate nodes. > > > 16) Section 3.1.7 and 3.1.8: What is Encapsulation Type and > how is it encoded? > > I'll add a reference. Thanks. > > > 17) Section 3.2: Why are there multiple downstream labels > in the downstream mapping? do they belong to different LSP > levels? Or the figure is simply showing many downstream mapping TLVs? > > That LSR may swap and push. Thanks, could you please add this clarification. Also please indicate the correspondence between order of labels in the TLV and the label stack. > > > 18) Section 3.3: what is the purpose of Pad TLV? > > To pad the ping packet, e.g., to test large packets. Thanks, could you please write down this example. > > > 19) Section 4.3: Should an Echo reply always have a > downstream mapping TLV even if no downstream mapping TLV is > in the Echo request? > > No. Please add this to the text explicitly. > > > 20) Section 4.4: Seems like back to back echo-request can't > be sent before receiving the echo-reply of previous > echo-request. Why this limitation? > > Where did you read this? Text says: "Once an Echo Reply is received for a given Sequence Number (for a given UDP port and Handle), the Sequence Number for subsequent Echo Requests for that UDP port and Handle SHOULD be incremented." If the echo requests could be sent without needing to receive the echo response of previous echo request, then there should not be any relationship between seq # of echo request and echo reply. Right? > > > 21) Section 5.1: How is the downstream mapping TLV conveyed > in the echo-reply sent over RSVP-TE? it seems no downstream > mapping TLV is defined for RSVP-TE. > > Do you think it should be added? Sure, if RSVP-TE return path is a valid return path, then you need to somehow convey this TLV. right? -Shahram > > Kireeti. > From owner-mpls@UU.NET Wed Dec 11 11:46:04 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 LAA12002 for ; Wed, 11 Dec 2002 11:46:03 -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 QQnsul17436 for ; Wed, 11 Dec 2002 16:48:37 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 QQnsuk08011; Wed, 11 Dec 2002 16:43:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsuk18902 for mpls-outgoing; Wed, 11 Dec 2002 16:43: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 QQnsuk18897 for ; Wed, 11 Dec 2002 16:43:19 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 QQnsuk21717 for ; Wed, 11 Dec 2002 16:42: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 QQnsuk21398 for ; Wed, 11 Dec 2002 16:42:21 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 QQnsuk21390 for ; Wed, 11 Dec 2002 16:42:21 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBBGgo9b011203 for ; Wed, 11 Dec 2002 11:42:50 -0500 (EST) 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 LAA25953 for ; Wed, 11 Dec 2002 11:42:20 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBBGgKJ25142 for mpls@uu.net; Wed, 11 Dec 2002 11:42:20 -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 QQnsuk18822 for ; Wed, 11 Dec 2002 16:41:15 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 QQnsuk27381 for ; Wed, 11 Dec 2002 16:39: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 QQnsuk15317 for ; Wed, 11 Dec 2002 16:39:50 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 QQnsuk15300 for ; Wed, 11 Dec 2002 16:39:49 GMT Received: (qmail 6504 invoked by uid 104); 11 Dec 2002 16:39:31 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4236. . Clean. Processed in 0.521225 secs); 11 Dec 2002 16:39:31 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 11 Dec 2002 16:39: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 gBBGdUQ27331; Wed, 11 Dec 2002 08:39:30 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Wed, 11 Dec 2002 08:39:30 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B7D@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Kireeti Kompella'" Cc: mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Wed, 11 Dec 2002 08:39:24 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Kireeti, > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Wednesday, December 11, 2002 7:23 AM > To: Shahram Davari > Cc: mpls@UU.NET > Subject: RE: Last call on LSP Ping > > > Hi Shahram, > > On Thu, 5 Dec 2002, Shahram Davari wrote: > > > 22) I can't understand section 3.2 at all. Since TTL=n+1 > makes no sense, for the sake of argument I'll assume you > meant TTL=n-1. Now let's assume the following topology: > > It's quite simple: read "initial TTL=n>1", "initial TTL=n+1", etc. OK, I think what you meant is: If a packet with outermost label L and initial TTL n>1 arrived at X on interface I (with TTL=1), X must be able to compute which LSRs could receive the packet if the initial TTL=n+1, and what label they would see. (It is outside the scope of this document to specify how this computation may be done.) The set of these LSRs are the downstream routers (and their corresponding labels) for X with respect to L. Correct? > > > L1 L2 L3 > > -------R1-------R2-------R3 > > \ L4 > > \-----R4 > > > > In which R1, R2, R3, and R4 are LSRs and L1, L2, L3 and L4 > are each a > > set of labels that are received on those LSRs. > > Correction: L1, ... L4 are all label mappings for a given FEC. So am I correct to conclude that the format of the downstream Mapping is actually as follows and multiple of them can exist in a single echo reply? Also the downstream routers reported in the echo reply are in fact representing the ECMP paths? 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream IPv4 Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU | Address Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream Label | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream Label | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Also, > R3 and R4 are equidistant from R2. To make this more exciting, add an > R5 with label L5 such that R5's metric from R2 is bigger than R3's. Will R5 also be included in the echo reply? > > > It seems from the text that the following sequential > behavior is expected: (DM means Downstream Mapping TLV) > > > > Ingress => Echo Request: DM (R1, L1) > > R1 => Echo Reply : DM (R2, L2) > > Ingress => Echo Request: DM (R2, L2) > > R2 => Echo Reply : DM (R3, L3 and R4, L4) > > Ingress => Echo Request: DM (R3, L3 and R4, L4) > > etc. > > > > Is this the behavior that is intended? And does it apply > only to trace-route? > > Yes (with the changes above), and yes. > > > What is the purpose of this function? it seems that DM is > being used to extract the > > whole switching table of each interface, is that correct? > If so, then it is neither ping, nor trace-route? > > No, just the label bindings for a given FEC. Thanks. Could you please clarify all that you said in the text. > > > 23) section 4.1: In order to exercise all the ECMP paths, > you need to > > scan through all 127/8 addresses (16 million of them), > don't you think > > this is not feasible? > > "The difficult, we do immediately. The impossible takes a > little longer." I would say it is impossible. I concur to Curtis's suggestion of returning ECMP identifiers from split points. > > > 24) Section 4.1: Why should an LSR send multiple echo > requests with the same seq#? What function is in mind that > can't be achieved by incrementing seq #? > > To increase the probability of receipt of a ping with a given sequence > number. But by incrementing the echo requests, not only you could achieve the same goal, but also detect packet loss. > > Kireeti. > From owner-mpls@UU.NET Wed Dec 11 11:51:44 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 LAA12330 for ; Wed, 11 Dec 2002 11:51:43 -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 QQnsul04413 for ; Wed, 11 Dec 2002 16:54:16 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 QQnsul22513; Wed, 11 Dec 2002 16:48:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsul19805 for mpls-outgoing; Wed, 11 Dec 2002 16:47:43 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 QQnsul19754 for ; Wed, 11 Dec 2002 16:47:34 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 QQnsul27307 for ; Wed, 11 Dec 2002 16:47: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 QQnsul25332 for ; Wed, 11 Dec 2002 16:47:26 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 QQnsul25324 for ; Wed, 11 Dec 2002 16:47:26 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBBGluEb011977 for ; Wed, 11 Dec 2002 11:47:56 -0500 (EST) 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 LAA26367 for ; Wed, 11 Dec 2002 11:47:25 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBBGlPk25881 for mpls@uu.net; Wed, 11 Dec 2002 11:47:25 -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 QQnsul19632 for ; Wed, 11 Dec 2002 16:46:34 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 QQnsul24146 for ; Wed, 11 Dec 2002 16:46:15 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 QQnsul24182 for ; Wed, 11 Dec 2002 16:46:14 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 QQnsul24142 for ; Wed, 11 Dec 2002 16:46:14 GMT Received: (qmail 10392 invoked by uid 104); 11 Dec 2002 16:45:58 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4236. . Clean. Processed in 0.568373 secs); 11 Dec 2002 16:45:58 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 11 Dec 2002 16:45: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 gBBGjvQ00783; Wed, 11 Dec 2002 08:45:57 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Wed, 11 Dec 2002 08:45:57 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B7E@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Kireeti Kompella'" , George Swallow Cc: mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Wed, 11 Dec 2002 08:45:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Kireeti, Isn't it better to use two different receiver's CE-ID, one for each receiver CE interface, rather than introducing FEC stack? Thanks, -Shahram > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Wednesday, December 11, 2002 7:45 AM > To: George Swallow > Cc: mpls@UU.NET > Subject: Re: Last call on LSP Ping > > > Hi George, > > > I think you're really only testing one FEC. The stack > gives you a way > > of noting how you set off the get to that FEC (assuming you had > > multiple options - like two TE tunnels). > > Sometimes you're testing just the one FEC, sometimes you're really > testing the stack. Say you're testing prefix 10/8 in VPN foo, and > it so happens that you go over LSP bar. You don't really care, you > create a ping packet with target FEC "10/8 in VPN foo", slap a label > stack on it, and off it goes. > > However, suppose you learned 10/8 in VPN foo from two PEs (dual-homed > CE), with LSPs bar1 and bar2. You may want to test each > independently. > So, in one case you'd have a target FEC stack of "LSP bar1; > 10/8 in VPN > foo" and in the other case, "LSP bar2; 10/8 in VPN foo". > > Does that make sense? > > Kireeti. > From owner-mpls@UU.NET Wed Dec 11 11:53:45 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 LAA12415 for ; Wed, 11 Dec 2002 11:53:44 -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 QQnsul06967 for ; Wed, 11 Dec 2002 16:56:36 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 QQnsul04517; Wed, 11 Dec 2002 16:55:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsul20761 for mpls-outgoing; Wed, 11 Dec 2002 16:54:31 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 QQnsul20689 for ; Wed, 11 Dec 2002 16:54:16 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 QQnsul27768 for ; Wed, 11 Dec 2002 16:53:33 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 QQnsul03082 for ; Wed, 11 Dec 2002 16:53:33 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 QQnsul03076 for ; Wed, 11 Dec 2002 16:53:32 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBBGs2UW012843 for ; Wed, 11 Dec 2002 11:54:02 -0500 (EST) 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 LAA26827 for ; Wed, 11 Dec 2002 11:53:31 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBBGrVs28491 for mpls@uu.net; Wed, 11 Dec 2002 11:53:31 -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 QQnsul20352 for ; Wed, 11 Dec 2002 16:51: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 QQnsul02878 for ; Wed, 11 Dec 2002 16:50: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 QQnsul21815 for ; Wed, 11 Dec 2002 16:50:42 GMT Received: from father.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQnsul21764 for ; Wed, 11 Dec 2002 16:50:40 GMT Received: (qmail 13687 invoked by uid 104); 11 Dec 2002 16:50:40 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4236. . Clean. Processed in 0.555238 secs); 11 Dec 2002 16:50:40 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 11 Dec 2002 16:50: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 gBBGocQ04193; Wed, 11 Dec 2002 08:50:38 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Wed, 11 Dec 2002 08:50:38 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B80@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Kireeti Kompella'" , "Gray, Eric" Cc: mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Wed, 11 Dec 2002 08:50:29 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Kireeti, I agree that random addresses chosen from a range is better than a single address. But we don't want to rely on pure luck either to detect breaks. I think Curtis's suggestion has good merits in solving this problem. Yours, -Shahram > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Wednesday, December 11, 2002 6:07 AM > To: Gray, Eric > Cc: mpls@UU.NET > Subject: RE: Last call on LSP Ping > > > Hi Eric, > > > I am suggesting that attempting to use any address range > > as a mechanism for testing ECMP routes is a mistake. > > I don't follow. If I send ping packets with 127.0.0.1 and > 127.31.41.59, > the worst that can happen is that they end up on the same path. But > I may get lucky and hit two paths. If I only use 127.0.0.1 (or the > ALL-ROUTERS.MCAST.NET address or whatever), I am guaranteed not to > test more than one path. > > Kireeti. > From owner-mpls@UU.NET Wed Dec 11 11:56: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 LAA12486 for ; Wed, 11 Dec 2002 11:56:19 -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 QQnsul12954 for ; Wed, 11 Dec 2002 16:58: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 QQnsul04817; Wed, 11 Dec 2002 16:54:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsul20685 for mpls-outgoing; Wed, 11 Dec 2002 16:54: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 QQnsul20650 for ; Wed, 11 Dec 2002 16:53:56 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 QQnsul24669 for ; Wed, 11 Dec 2002 16:52:34 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 QQnsul02290 for ; Wed, 11 Dec 2002 16:52:34 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 QQnsul02113 for ; Wed, 11 Dec 2002 16:52:24 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBBGqrSg012684 for ; Wed, 11 Dec 2002 11:52:53 -0500 (EST) 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 LAA26745 for ; Wed, 11 Dec 2002 11:52:22 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBBGqMM27847 for mpls@uu.net; Wed, 11 Dec 2002 11:52:22 -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 QQnsul19933 for ; Wed, 11 Dec 2002 16:49: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 QQnsul24567 for ; Wed, 11 Dec 2002 16:48:13 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 QQnsul16554 for ; Wed, 11 Dec 2002 16:48:10 GMT Received: from father.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQnsul16362 for ; Wed, 11 Dec 2002 16:48:04 GMT Received: (qmail 11940 invoked by uid 104); 11 Dec 2002 16:48:01 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4236. . Clean. Processed in 0.483286 secs); 11 Dec 2002 16:48:01 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 11 Dec 2002 16:48:01 -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 gBBGlvQ02489; Wed, 11 Dec 2002 08:47:57 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Wed, 11 Dec 2002 08:47:57 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B7F@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Kireeti Kompella'" , Curtis Villamizar Cc: mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Wed, 11 Dec 2002 08:47:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Kireeti, Saying that LSRs that receive a packet with 127/8 address should not discard the packet, rather they should send the packet to the control-plane for processing. Thanks, -Shahram > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Wednesday, December 11, 2002 5:40 AM > To: Curtis Villamizar > Cc: mpls@UU.NET > Subject: Re: Last call on LSP Ping > > > Hi Curtis, > > On Fri, 6 Dec 2002, Curtis Villamizar wrote: > > > Maybe one of the authors can join (do they really want to?) > > Not really :-) > > > whether they would see fit to add a sentence or deem it too obvious. > > Saying what? "Setting the destination IP address to > something from 127/8 > causes some to break out in a rash, but is perfectly valid"? > > Kireeti. > From owner-mpls@UU.NET Wed Dec 11 12:04:08 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 MAA12729 for ; Wed, 11 Dec 2002 12:04:08 -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 QQnsum28138 for ; Wed, 11 Dec 2002 17:07:02 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 QQnsul13170; Wed, 11 Dec 2002 16:58:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsul20780 for mpls-outgoing; Wed, 11 Dec 2002 16:54:53 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 QQnsul20765 for ; Wed, 11 Dec 2002 16:54:34 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 QQnsul14970 for ; Wed, 11 Dec 2002 16:54: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 QQnsul03556 for ; Wed, 11 Dec 2002 16:54:01 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 QQnsul03268 for ; Wed, 11 Dec 2002 16:53:46 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBBGsGM4012867 for ; Wed, 11 Dec 2002 11:54:16 -0500 (EST) 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 LAA26846 for ; Wed, 11 Dec 2002 11:53:45 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBBGrjS28660 for mpls@uu.net; Wed, 11 Dec 2002 11:53:45 -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 QQnsul20393 for ; Wed, 11 Dec 2002 16:51:22 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 QQnsul06543 for ; Wed, 11 Dec 2002 16:50: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 QQnsul21383 for ; Wed, 11 Dec 2002 16:50:27 GMT Received: from falcon.mail.pas.earthlink.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: falcon.mail.pas.earthlink.net [207.217.120.74]) id QQnsul21334 for ; Wed, 11 Dec 2002 16:50:25 GMT Received: from washdc3-ar8-4-40-020-193.washdc3.elnk.dsl.genuity.net ([4.40.20.193] helo=DellPC.mplsrc.com) by falcon.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18MA3z-0004L3-00; Wed, 11 Dec 2002 08:50:23 -0800 Message-Id: <5.1.0.14.2.20021211114836.019df8f8@localhost> X-Sender: news/mplsrc.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 11 Dec 2002 11:50:25 -0500 To: mplsrc_news@mplsrc.com From: MPLS Resource Center News Subject: MPLScon Spring 2003 - Call for Presentations Cc: mpls@UU.NET Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk The call for presentations for MPLScon Spring 2003 is now available at http://www.mplscon.com/speaker/submit_pres.html The conference will take place on May 19-22 in New York City, NY at the New Yorker Hotel. This is the first MPLS conference specifically targeted to end-users and enterprise network managers responsible for evaluating and selecting MPLS-based services, as well as evaluating the use of MPLS within their own networks. For additional details please contact: Irwin Lazar, Conference Director ilazar@mplscon.com 703-742-9659 From owner-mpls@UU.NET Wed Dec 11 12:30:33 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 MAA13567 for ; Wed, 11 Dec 2002 12:30:32 -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 QQnsuo11405 for ; Wed, 11 Dec 2002 17:33:19 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 QQnsun00290; Wed, 11 Dec 2002 17:27:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsun12904 for mpls-outgoing; Wed, 11 Dec 2002 17:27: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 QQnsun12897 for ; Wed, 11 Dec 2002 17:27: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 QQnsun09444 for ; Wed, 11 Dec 2002 17:26: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 QQnsun13553 for ; Wed, 11 Dec 2002 17:26:41 GMT Received: from mail.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc239.alcatel.be [195.207.101.239]) id QQnsun13544 for ; Wed, 11 Dec 2002 17:26:41 GMT Received: from bemail05.net.alcatel.be (localhost [127.0.0.1]) by mail.alcatel.be (8.10.1/8.11.4) with ESMTP id gBBHQaQ08853; Wed, 11 Dec 2002 18:26:36 +0100 (MET) Received: from alcatel.be ([138.203.67.27]) by bemail05.net.alcatel.be (Lotus Domino Release 5.0.9a) with ESMTP id 2002121118263507:5126 ; Wed, 11 Dec 2002 18:26:35 +0100 Message-ID: <3DF77635.B37A4905@alcatel.be> Date: Wed, 11 Dec 2002 18:30:29 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: Optical Network Architecture (NTA - Antwerpen) X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Cheng-Yin.Lee@alcatel.com Cc: Jean Philippe Vasseur , sachin laddha , mpls@UU.NET, ccamp@ops.ietf.org Subject: Re: Multi-Area TE Protocol Extensions References: <4.3.2.7.2.20021210090846.06284110@paris.cisco.com> <4.3.2.7.2.20021210123021.0382fe10@paris.cisco.com> <3DF643DF.4F8AC12C@alcatel.be> <3DF75D2D.4BE2F8BF@alcatel.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.9a |January 7, 2002) at 12/11/2002 18:26:35, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.9a |January 7, 2002) at 12/11/2002 18:26:36, Serialize complete at 12/11/2002 18:26:36 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit hi, my suggestion based on the jp's comment was to scope the examples and usage scenarios in this i-d to have at the end some material for the coverage of constraint passing methods in the ma-te context (i interpreted the remark of jp as follows, it is not cristal clear to see how this method applies to ma-te), also discussion from ietf 53 is settled we don't cover inter-as for the time being at the ccamp wg - fyi te wg has just start the discussions on inter-as te thus we first wait for their input... and then we see based on their results - ps: this said there are plenty of ways to avoid to deal with specific application usage within the core of the document specifications thanks, - dimitri. Cheng-Yin.Lee@alcatel.com wrote: > > Dimitri, JP, > While I think an applicability section/statement is fine, I'm not sure if a mechanism > to compute inter-area TE path belong in this ID. > > We did include applications in the first discussion of this ID and in the slides > http://www.ietf.org/proceedings/02mar/slides/ccamp-6/index.html and in addressing > Kireeti's suggestion to include a discussion on the impact of message size, we provided > an inter-area example for illustration purposes. However, there have also been > suggestions in the past to not discuss applications specifically in the draft itself. > I am fine with either way. > > thanks > cheng-yin > > Dimitri.Papadimitriou@alcatel.be wrote: > > > jp, > > > > > this ID does not propose a mechanism to compute inter-area TE path > > > > well i would say that either none of them does it, or all of > > them, more accurately route exclusions are applicable to any > > mpls network where full computation of the ero is not performed > > before the LSP is signaled, implying thus a "scope" for computed > > path thus among other applicable to multiple areas - nevertheless > > i agree that a next version of this i-d should probably include > > an applicability section covering this in a bit more details (see > > also section 4.1 for an example - > > > > this said and as for any other input or i-d provided on constraint- > > passing (as well as path query, btw) lot of work is still needed to > > achieve a decent first step in this effort; > > > > thanks, > > - dimitri. > > > > Jean Philippe Vasseur wrote: > > > > > > Hi Dimitri, > > > > > > cc'ing CCAMP - see in line, > > > > > > At 17:45 10/12/2002 +0100, Dimitri.Papadimitriou@alcatel.be wrote: > > > >jp, > > > > > > > >in fact the below list should simply be as follows for > > > >signalling-based methods: 1) constraint-passing 2) loose > > > >routing and 3) path query; > > > > > > > >and the for constraint-passing we have a several i-d's > > > >such as, > > > > > > > >http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclude-route-01.txt > > > > > > > > > > this ID does not propose a mechanism to compute inter-area TE path > > > > > > >constraint passing may also be extended using the crank- > > > >back as listed below; the usage scenarios of these methods > > > >are described in the following: > > > > > > > >http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-03.txt > > > > > > > >now probably it is worth spending some time in considering > > > >input coming from the tewg wrt to this effort, most of the > > > >input that you see listed above has been produced over the > > > >past year (and more) i can't imagine stepping in the protocol > > > >details without a clear consensus on what do we want to cover > > > >within the ccamp wg & w/o taking into account the tewg rec's > > > >(probably better to discuss this on the ccamp mailing list) > > > > > > Fully agree with you. Hopefully multi-area TE should be soon part of the > > > CCAMP charter. > > > > > > JP. > > > > > > >thanks, > > > >- dimitri. > > > > > > > >Jean Philippe Vasseur wrote: > > > > > > > > > > Hi, > > > > > > > > > > At 13:53 10/12/2002 +0530, sachin laddha wrote: > > > > > >Hi, > > > > > >'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as > > > > > >"Initial requirements are given here for protocol support of the > > > > multi-area > > > > > >TE methods, which include needs to support > > > > > > > > > > > >* path-computation-server (PCS) functionality [kompella, lee, > > > > vasseur, > > > > > >te-qos-routing], > > > > > >* query functionality [query, vasseur], > > > > > >* crankback functionality [crankback], > > > > > > > > > > > >and, optionally, > > > > > > > > > > > >* TE feedback functionality [feedback], and > > > > > >* summary-LSA functionality [summary_lsa]." > > > > > >. > > > > > >I want to know whether cisco/juniper routers (standard ones) supports > > > > all of > > > > > >the above extension. > > > > > >or if not,how many.......or Whether router is supposed to support how many > > > > > >... > > > > > > > > > > I do not think any vendor supports all the method mentioned above, but just > > > > > a subset. If you are running a network, your feed-backs on your preferred > > > > > method is very welcome. > > > > > > > > > > JP. > > > > > > > > > > >Regards, > > > > > >---Sachin > > > > > > > >-- > > > >Papadimitriou Dimitri > > > >E-mail : dimitri.papadimitriou@alcatel.be > > > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > > >E-mail : dpapadimitriou@psg.com > > > >Public : http://psg.com/~dpapadimitriou/ > > > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > > >Phone : Work: +32 3 2408491 - Home: +32 2 3434361 > > > > -- > > Papadimitriou Dimitri > > E-mail : dimitri.papadimitriou@alcatel.be > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > E-mail : dpapadimitriou@psg.com > > Public : http://psg.com/~dpapadimitriou/ > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > Phone : Work: +32 3 2408491 - Home: +32 2 3434361 -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : Work: +32 3 2408491 - Home: +32 2 3434361 From owner-mpls@UU.NET Wed Dec 11 12:44: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 MAA14181 for ; Wed, 11 Dec 2002 12:44:11 -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 QQnsup04788 for ; Wed, 11 Dec 2002 17:47: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 QQnsup01582; Wed, 11 Dec 2002 17:45:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsup14412 for mpls-outgoing; Wed, 11 Dec 2002 17:45: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 QQnsup14405 for ; Wed, 11 Dec 2002 17:45:23 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 QQnsup09351 for ; Wed, 11 Dec 2002 17:45:09 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 QQnsts19154 for ; Wed, 11 Dec 2002 12:11:25 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 gBBCBKS10293; Wed, 11 Dec 2002 04:11:20 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id gBBCBKV20383; Wed, 11 Dec 2002 04:11:20 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Wed, 11 Dec 2002 04:11:20 -0800 (PST) From: Kireeti Kompella To: Peter Willis cc: Subject: Re: Last call on LSP Ping In-Reply-To: Message-ID: <20021211040721.S19625-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Peter, On Thu, 5 Dec 2002, Peter Willis wrote: > Comments on draft-ietf-mpls-lsp-ping-01.txt > > "4.1. Sending an MPLS Echo Request > > An MPLS echo request is a (possibly) labelled UDP packet. The IP > header is set as follows: the source IP address is a routable address > of the sender; the destination IP address is a (randomly chosen) > address from 127/8; the IP TTL is set to 1. " > > Question 1 - What does "possibly" mean above? Why possibly? Would it work if > it was not labelled? Consider a one-hop LSP with PHP. > Question 2 - The destination address 127/8, we should also have an IPv6 > destination loopback address if we want to be future proof. (Would > that be ::1 in IPv6 speak?) The whole issue of encoding the LSP ping in an IPv6 header hasn't been addressed. It might be worth doing -- I'll let the chairs and ADs guide me. > Question 3 - What is a "routable address" when we have IP VPNs? I'm thinking > if the LSP ping originates in a customer-routed domain (or the edge carrier in > a carriers-carrier scenario) then in the core (P routers) that address isn't > routable! If the ping starts in a customer domain, hopefully it ends in a customer domain, and the reply will be routable. The traceroute mode will not work, but that is to be expected -- it's no different from "regular" traceroute. Kireeti. From owner-mpls@UU.NET Wed Dec 11 13:03:33 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 NAA14834 for ; Wed, 11 Dec 2002 13:03:33 -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 QQnsuq15674 for ; Wed, 11 Dec 2002 18:06:27 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 QQnsuq11553; Wed, 11 Dec 2002 18:04:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsuq02805 for mpls-outgoing; Wed, 11 Dec 2002 18:03: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 QQnsuq02772 for ; Wed, 11 Dec 2002 18:03: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 QQnsuq05709 for ; Wed, 11 Dec 2002 18:03: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 QQnsuq06390 for ; Wed, 11 Dec 2002 18:03:08 GMT Received: from kanmx1.ca.alcatel.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: m115-138.on.tac.net [209.202.115.138] (may be forged)) id QQnsuq06386 for ; Wed, 11 Dec 2002 18:03:07 GMT Received: (qmail 4040 invoked from network); 11 Dec 2002 18:09:06 -0000 Received: (ofmipd 138.120.118.71); 11 Dec 2002 18:08:44 -0000 Received: from alcatel.com ([138.120.62.58]) by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA3AFD; Wed, 11 Dec 2002 13:02:59 -0500 Date: 11 Dec 2002 13:02:19 -0500 Message-ID: <3DF77DAB.70C6DFF0@alcatel.com> From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com To: Dimitri.Papadimitriou@alcatel.be Cc: "Jean Philippe Vasseur" , "sachin laddha" , mpls@UU.NET, ccamp@ops.ietf.org X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Multi-Area TE Protocol Extensions References: <4.3.2.7.2.20021210090846.06284110@paris.cisco.com> <4.3.2.7.2.20021210123021.0382fe10@paris.cisco.com> <3DF643DF.4F8AC12C@alcatel.be> <3DF75D2D.4BE2F8BF@alcatel.com> <3DF77635.B37A4905@alcatel.be> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Dimitri, Dimitri.Papadimitriou@alcatel.be wrote: > hi, my suggestion based on the jp's comment was to > scope the examples and usage scenarios in this i-d > to have at the end some material for the coverage > of constraint passing methods in the ma-te context > (i interpreted the remark of jp as follows, it is > not cristal clear to see how this method applies > to ma-te), Ok, I see. Clarifying the scope of the problem that the ID addresses, is definitely useful. > also discussion from ietf 53 is settled > we don't cover inter-as for the time being at the > ccamp wg - fyi te wg has just start the discussions > on inter-as te thus we first wait for their input... > and then we see based on their results - Understood. > ps: this said there are plenty of ways to avoid to > deal with specific application usage within the core > of the document specifications Sure. thanks cheng-yin > > > thanks, > - dimitri. > > Cheng-Yin.Lee@alcatel.com wrote: > > > > Dimitri, JP, > > While I think an applicability section/statement is fine, I'm not sure if a mechanism > > to compute inter-area TE path belong in this ID. > > > > We did include applications in the first discussion of this ID and in the slides > > http://www.ietf.org/proceedings/02mar/slides/ccamp-6/index.html and in addressing > > Kireeti's suggestion to include a discussion on the impact of message size, we provided > > an inter-area example for illustration purposes. However, there have also been > > suggestions in the past to not discuss applications specifically in the draft itself. > > I am fine with either way. > > > > thanks > > cheng-yin > > > > Dimitri.Papadimitriou@alcatel.be wrote: > > > > > jp, > > > > > > > this ID does not propose a mechanism to compute inter-area TE path > > > > > > well i would say that either none of them does it, or all of > > > them, more accurately route exclusions are applicable to any > > > mpls network where full computation of the ero is not performed > > > before the LSP is signaled, implying thus a "scope" for computed > > > path thus among other applicable to multiple areas - nevertheless > > > i agree that a next version of this i-d should probably include > > > an applicability section covering this in a bit more details (see > > > also section 4.1 for an example - > > > > > > this said and as for any other input or i-d provided on constraint- > > > passing (as well as path query, btw) lot of work is still needed to > > > achieve a decent first step in this effort; > > > > > > thanks, > > > - dimitri. > > > > > > Jean Philippe Vasseur wrote: > > > > > > > > Hi Dimitri, > > > > > > > > cc'ing CCAMP - see in line, > > > > > > > > At 17:45 10/12/2002 +0100, Dimitri.Papadimitriou@alcatel.be wrote: > > > > >jp, > > > > > > > > > >in fact the below list should simply be as follows for > > > > >signalling-based methods: 1) constraint-passing 2) loose > > > > >routing and 3) path query; > > > > > > > > > >and the for constraint-passing we have a several i-d's > > > > >such as, > > > > > > > > > >http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclude-route-01.txt > > > > > > > > > > > > > this ID does not propose a mechanism to compute inter-area TE path > > > > > > > > >constraint passing may also be extended using the crank- > > > > >back as listed below; the usage scenarios of these methods > > > > >are described in the following: > > > > > > > > > >http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-03.txt > > > > > > > > > >now probably it is worth spending some time in considering > > > > >input coming from the tewg wrt to this effort, most of the > > > > >input that you see listed above has been produced over the > > > > >past year (and more) i can't imagine stepping in the protocol > > > > >details without a clear consensus on what do we want to cover > > > > >within the ccamp wg & w/o taking into account the tewg rec's > > > > >(probably better to discuss this on the ccamp mailing list) > > > > > > > > Fully agree with you. Hopefully multi-area TE should be soon part of the > > > > CCAMP charter. > > > > > > > > JP. > > > > > > > > >thanks, > > > > >- dimitri. > > > > > > > > > >Jean Philippe Vasseur wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > At 13:53 10/12/2002 +0530, sachin laddha wrote: > > > > > > >Hi, > > > > > > >'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as > > > > > > >"Initial requirements are given here for protocol support of the > > > > > multi-area > > > > > > >TE methods, which include needs to support > > > > > > > > > > > > > >* path-computation-server (PCS) functionality [kompella, lee, > > > > > vasseur, > > > > > > >te-qos-routing], > > > > > > >* query functionality [query, vasseur], > > > > > > >* crankback functionality [crankback], > > > > > > > > > > > > > >and, optionally, > > > > > > > > > > > > > >* TE feedback functionality [feedback], and > > > > > > >* summary-LSA functionality [summary_lsa]." > > > > > > >. > > > > > > >I want to know whether cisco/juniper routers (standard ones) supports > > > > > all of > > > > > > >the above extension. > > > > > > >or if not,how many.......or Whether router is supposed to support how many > > > > > > >... > > > > > > > > > > > > I do not think any vendor supports all the method mentioned above, but just > > > > > > a subset. If you are running a network, your feed-backs on your preferred > > > > > > method is very welcome. > > > > > > > > > > > > JP. > > > > > > > > > > > > >Regards, > > > > > > >---Sachin > > > > > > > > > >-- > > > > >Papadimitriou Dimitri > > > > >E-mail : dimitri.papadimitriou@alcatel.be > > > > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > > > >E-mail : dpapadimitriou@psg.com > > > > >Public : http://psg.com/~dpapadimitriou/ > > > > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > > > >Phone : Work: +32 3 2408491 - Home: +32 2 3434361 > > > > > > -- > > > Papadimitriou Dimitri > > > E-mail : dimitri.papadimitriou@alcatel.be > > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > > E-mail : dpapadimitriou@psg.com > > > Public : http://psg.com/~dpapadimitriou/ > > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > > Phone : Work: +32 3 2408491 - Home: +32 2 3434361 > > -- > Papadimitriou Dimitri > E-mail : dimitri.papadimitriou@alcatel.be > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > E-mail : dpapadimitriou@psg.com > Public : http://psg.com/~dpapadimitriou/ > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > Phone : Work: +32 3 2408491 - Home: +32 2 3434361 From owner-mpls@UU.NET Wed Dec 11 13:20:08 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 NAA15357 for ; Wed, 11 Dec 2002 13:20:08 -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 QQnsur22321 for ; Wed, 11 Dec 2002 18:22:59 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 QQnsur19781; Wed, 11 Dec 2002 18:21:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsur05910 for mpls-outgoing; Wed, 11 Dec 2002 18:21:18 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 QQnsur05899 for ; Wed, 11 Dec 2002 18:21:14 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 QQnsur02398 for ; Wed, 11 Dec 2002 18:21: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 QQnsur19370 for ; Wed, 11 Dec 2002 18:21:07 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 QQnsur19358 for ; Wed, 11 Dec 2002 18:21:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBBILasF025337 for ; Wed, 11 Dec 2002 13:21:37 -0500 (EST) 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 NAA04442 for ; Wed, 11 Dec 2002 13:21:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBBIL5p14876 for mpls@uu.net; Wed, 11 Dec 2002 13:21:05 -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 QQnsur05685 for ; Wed, 11 Dec 2002 18:20:01 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 QQnsur25520 for ; Wed, 11 Dec 2002 18:19:43 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 QQnsur04935 for ; Wed, 11 Dec 2002 18:19:42 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 QQnsur04924 for ; Wed, 11 Dec 2002 18:19:41 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 NAA44983; Wed, 11 Dec 2002 13:17:28 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212111817.NAA44983@workhorse.fictitious.org> To: Kireeti Kompella cc: Curtis Villamizar , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Wed, 11 Dec 2002 02:40:17 PST." <20021211023339.K19625-100000@kummer.juniper.net> Date: Wed, 11 Dec 2002 13:17:27 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <20021211023339.K19625-100000@kummer.juniper.net>, Kireeti Kompella writes: > Hi Curtis, > > On Fri, 6 Dec 2002, Curtis Villamizar wrote: > > > Maybe one of the authors can join (do they really want to?) > > Not really :-) Smart move. > > whether they would see fit to add a sentence or deem it too obvious. > > Saying what? "Setting the destination IP address to something from 127/8 > causes some to break out in a rash, but is perfectly valid"? I'll take that as closer to a "no its too obvious". My first choice as well. If there remains insistence on the list that we justify the choice of 127/8, the criteria would be: An ideal destination address would be deliverable to the local LSR when TTL expires, regardless of where in the topology that router was. This first requirement is so that an address on the next MPLS-ping capable downstream LSR need not be known to get a response. An ideal destination address would be deliverable within an MPLS LSP but otherwise unrouteable even in networks using the IANA designated private address space [RFC1700]. This second requirement insures that the MPLS-ping packet is not forwarded by IP and does not travel further than the LSR where TTL expires, or the egress LSR. The address space 127/8 is explicitly chosen by IANA to be used only to reach the local loopback device on a host or router [RFC1812]. This address space is never routeable. For these reasons, destination addresses are chosen from the address range 127/8. Multipath capabilities on some routers, are based on a hash or other algorithm applied to IP source and IP destination addresses [RFC2991]. In order to exercise multipath, addresses from a range of addresses must be used. An MPLS-ping capable LSR as an LSP egress must be able to deliver packets exiting the LSP with an address anywhere in the range 127/8 and a UDP payload with destination port 3503 to a local loopback device. An MPLS-ping capable LSR as an LSP midpoint must be able to deliver packets for which TTL expires which have an IP payload and a destination address anywhere in the range 127/8 and a UDP payload with destination port 3503 to a local loopback device. Maybe I should have suggested text in the first place. Now we have two questions... First do you agree with the text. Second is do we need it. > Kireeti. Curtis From owner-mpls@UU.NET Wed Dec 11 13:29: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 NAA15615 for ; Wed, 11 Dec 2002 13:29:08 -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 QQnsus15270 for ; Wed, 11 Dec 2002 18:31:58 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 QQnsur03513; Wed, 11 Dec 2002 18:25:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsur06106 for mpls-outgoing; Wed, 11 Dec 2002 18:25: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 QQnsur06083 for ; Wed, 11 Dec 2002 18:24: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 QQnsur21437 for ; Wed, 11 Dec 2002 18:24: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 QQnsur24910 for ; Wed, 11 Dec 2002 18:24:32 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 QQnsur24755 for ; Wed, 11 Dec 2002 18:24:26 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBBIOdFX025915 for ; Wed, 11 Dec 2002 13:24:39 -0500 (EST) 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 NAA04748 for ; Wed, 11 Dec 2002 13:24:08 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBBIO8315075 for mpls@uu.net; Wed, 11 Dec 2002 13:24:08 -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 QQnsur05942 for ; Wed, 11 Dec 2002 18:22:18 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 QQnsur29541 for ; Wed, 11 Dec 2002 18:21: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 QQnsur28669 for ; Wed, 11 Dec 2002 18:21:14 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 QQnsur28644 for ; Wed, 11 Dec 2002 18:21:13 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 NAA45001; Wed, 11 Dec 2002 13:19:00 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212111819.NAA45001@workhorse.fictitious.org> To: Kireeti Kompella cc: Curtis Villamizar , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Wed, 11 Dec 2002 03:00:16 PST." <20021211025947.B19625-100000@kummer.juniper.net> Date: Wed, 11 Dec 2002 13:19:00 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <20021211025947.B19625-100000@kummer.juniper.net>, Kireeti Kompella writes: > > > So I'm still in favor of using 127/8 but think that ECMP could be done > > better. > > Any concrete suggestions? > > Kireeti. You must be catching up. I just made one. No problem. Volume has been high, s/n low, but some signal. Curtis From owner-mpls@UU.NET Wed Dec 11 13:36:46 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 NAA15793 for ; Wed, 11 Dec 2002 13:36:46 -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 QQnsus28017 for ; Wed, 11 Dec 2002 18:39:38 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 QQnsus19077; Wed, 11 Dec 2002 18:34:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsus07342 for mpls-outgoing; Wed, 11 Dec 2002 18:34:31 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 QQnsus07331 for ; Wed, 11 Dec 2002 18:34:25 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 QQnsus12765 for ; Wed, 11 Dec 2002 18:34: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 QQnsus07742 for ; Wed, 11 Dec 2002 18:34:16 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 QQnsus07733 for ; Wed, 11 Dec 2002 18:34:15 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBBIYi8R027610 for ; Wed, 11 Dec 2002 13:34:45 -0500 (EST) 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 NAA05637 for ; Wed, 11 Dec 2002 13:34:14 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBBIYE218883 for mpls@uu.net; Wed, 11 Dec 2002 13:34:14 -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 QQnsus07224 for ; Wed, 11 Dec 2002 18:32:48 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 QQnsus13757 for ; Wed, 11 Dec 2002 18:31:39 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 QQnsus15458 for ; Wed, 11 Dec 2002 18:31:39 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 QQnsus15448 for ; Wed, 11 Dec 2002 18:31:38 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 NAA45218; Wed, 11 Dec 2002 13:29:24 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212111829.NAA45218@workhorse.fictitious.org> To: Kireeti Kompella cc: Curtis Villamizar , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Wed, 11 Dec 2002 03:12:53 PST." <20021211030739.A19625-100000@kummer.juniper.net> Date: Wed, 11 Dec 2002 13:29:24 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <20021211030739.A19625-100000@kummer.juniper.net>, Kireeti Kompella writes: > > > On Mon, 9 Dec 2002, Curtis Villamizar wrote: > > > > First of all I did propose using the egress IP address and setting the > > > TTL=1 in the IP header. This makes sure that the LSP-ping packet will > > > not get forwarded after the MPLS labels are poped. > > > > Glad to see this change to a technical discussion. Took a while. > > :-) > > > This proposal has two flaws, 1) when the label gets POPed and the > > egress isn't the router you thought it should be the response is an > > ICMP TTL expired, 2) no way to handle ECMP is proposed. > > Big flaw: there ain't no such thing as *the* egress router. Some > router "at the other end of the network" announces a label mapping > for 9/8, and this mapping makes its way to me. How do I know who > the egress router is? Moreover, there could be many routers announcing > 9/8 ... For ping mode that far end router is the egress. TTL is 255 on top label, 1 on all other labels. Something POPs out at the end of the LSP. For traceroute mode TTL starts as 1 on top. The first packet doesn't go far but identifies itself and returns a mapping. TTL is incremented, next router identifies itself and returns a mapping. Eventually the egress is reached. BTW- the draft only describes ping mode operation - traceroute mode is inadequately described except for those for whom "analogous to IP traceroute" is plenty. Works for me, but that doesn't count. (Unless of course, I interpreted your intentions incorrectly.) So there is an egress but my statement is still not entirely correct as stated. I should have pointed out that a packet can emerge anywhere at the egress or at an intermediate hop when TTL expired. > Kireeti. > > PS: IP TTL = 1 is already in the draft. IP TTL=1 and dest is in 127/8. No router should forward that except for forwarding to the local loopback, exactly as specified in RFC1812. Curtis From owner-mpls@UU.NET Wed Dec 11 14:31:20 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 OAA17689 for ; Wed, 11 Dec 2002 14:31:20 -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 QQnsuw07034 for ; Wed, 11 Dec 2002 19:33: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 QQnsuw02653; Wed, 11 Dec 2002 19:31:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsuw00833 for mpls-outgoing; Wed, 11 Dec 2002 19:30:51 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 QQnsuw00823 for ; Wed, 11 Dec 2002 19:30:46 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 QQnsuw15421 for ; Wed, 11 Dec 2002 19:30: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 QQnsuw13739 for ; Wed, 11 Dec 2002 19:30:14 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 QQnsuw13711 for ; Wed, 11 Dec 2002 19:30:13 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBBJUcQ8006891 for ; Wed, 11 Dec 2002 14:30:38 -0500 (EST) 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 OAA11114 for ; Wed, 11 Dec 2002 14:30:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBBJU5624430 for mpls@uu.net; Wed, 11 Dec 2002 14:30:05 -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 QQnsuv00721 for ; Wed, 11 Dec 2002 19:28:39 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 QQnsuv03060 for ; Wed, 11 Dec 2002 19:26:19 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 QQnsuv10304 for ; Wed, 11 Dec 2002 19:26:19 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 QQnsuv10297 for ; Wed, 11 Dec 2002 19:26:18 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 OAA45413; Wed, 11 Dec 2002 14:23:40 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212111923.OAA45413@workhorse.fictitious.org> To: jshen@cad.zju.edu.cn cc: Eric Osborne , Venkata.Naidu@Marconi.com, mpls-ops@mplsrc.com, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: [MPLS-OPS]: Jitter and MPLS In-reply-to: Your message of "Wed, 11 Dec 2002 11:23:02 +0800." <3DF6AF96.FD3EECB1@cad.zju.edu.cn> Date: Wed, 11 Dec 2002 14:23:40 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3DF6AF96.FD3EECB1@cad.zju.edu.cn>, Jing Shen writes: > > > What I care about is how may those changes affect the performance. From > your > word I come to see that our experimental result may only stick to our > implementation > and our experimental policy, but I'm still not clear that how could a > ASIC implemention > of MPLS engine compares to a ASIC implementation IP engine? Is there any > measurement data or paper on this? Probably some work has been done but it doesn't make a whole lot of difference. The best modern ASICs forward at full line rate for either MPLS or IP at OC192c rates of roughly 10Gb/s. So figure a few 10s of nsec per table or route lookup. This doesn't amount to a whole lot of time compared to any normal speed of light delay for a real network hop and even exceeds the packet serialization time. For UDP or TCP, the difference is 4 bytes added to the packet for MPLS. For 1500 byte TCP MSS that's under 0.3%. For 552 its about 0.7%. For a 40 byte packet its 10%. If you want traffic engineering it certainly doen't have the overhead of ATM (9-62% overhead). The network is usually not full so the <1% has negligible effect. TCP or UDP performance is typically dominated by window size and only mildly impacted by transient queueing delays until the network fills, then determined by drop characteristics after the network fills. That's why this issue hasn't been a hot topic. Curtis From owner-mpls@UU.NET Wed Dec 11 14:43: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 OAA18099 for ; Wed, 11 Dec 2002 14:43:47 -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 QQnsux01129 for ; Wed, 11 Dec 2002 19:46:37 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 QQnsuw26329; Wed, 11 Dec 2002 19:44:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsuw02056 for mpls-outgoing; Wed, 11 Dec 2002 19:43: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 QQnsuw02051 for ; Wed, 11 Dec 2002 19:43:25 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 QQnsuw20138 for ; Wed, 11 Dec 2002 19:43: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 QQnsuw25632 for ; Wed, 11 Dec 2002 19:43: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 QQnsuw25620 for ; Wed, 11 Dec 2002 19:43:10 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBBJheYJ009044 for ; Wed, 11 Dec 2002 14:43:40 -0500 (EST) 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 OAA12341 for ; Wed, 11 Dec 2002 14:43:09 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBBJh9I26990 for mpls@uu.net; Wed, 11 Dec 2002 14:43:09 -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 QQnsuw01985 for ; Wed, 11 Dec 2002 19:41:43 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 QQnsuw25868 for ; Wed, 11 Dec 2002 19:40: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 QQnsuw16500 for ; Wed, 11 Dec 2002 19:40:36 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 QQnsuw16489 for ; Wed, 11 Dec 2002 19:40: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 OAA45462; Wed, 11 Dec 2002 14:38:17 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212111938.OAA45462@workhorse.fictitious.org> To: Kireeti Kompella cc: Shahram Davari , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Wed, 11 Dec 2002 04:06:29 PST." <20021211033541.L19625-100000@kummer.juniper.net> Date: Wed, 11 Dec 2002 14:38:17 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <20021211033541.L19625-100000@kummer.juniper.net>, Kireeti Kompella writes: > > > 1) Time stamp: Why is the time stamp in both seconds and microseconds? The > microsecond could count up to 71 minutes. Isn't that enough? Why isn't the > > same timestamp used in ICMP not used here which says: > > > > The Timestamp is a right-justified, 32-bit timestamp in > > milliseconds since midnight UT. > > Is there a problem with having both seconds and microseconds? This is a unix time of day, not a time duration. We'd have a lot of timer wrap if our counter was only 71 minutes. This was real annoying with the older 32 bit MIB counters. So please keep as is. > > 12) Section 5 2nd paragraph last sentence I think should be changed to: "No > te that this may not work if some transit LSR does not support IP options" (n > ot 'MPLS ping' as mentioned in the draft) > > No, it is correct as is. A router that doesn't support MPLS ping will not > know how to deal with the MPLS echo reply. It would get this > strange-looking packet and probably discard it. It is UDP with an unrecognized port number. Send ICMP and discard. > > 17) Section 3.2: Why are there multiple downstream labels in the downstream > mapping? do they belong to different LSP levels? Or the figure is simply sho > wing many downstream mapping TLVs? > > That LSR may swap and push. To further clarify - if the LSR was at the ingress to a heirarchical next hop. For example, LDP over a TE hop does this. > > 21) Section 5.1: How is the downstream mapping TLV conveyed in the echo-rep > ly sent over RSVP-TE? it seems no downstream mapping TLV is defined for RSVP- > TE. > > Do you think it should be added? Not sure I understand the question. > Kireeti. Kireeti - I hope you don't mind my attempt to clarify a few points. Just let me know if I get it wrong. Curtis From owner-mpls@UU.NET Wed Dec 11 16:26: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 QAA21427 for ; Wed, 11 Dec 2002 16:26: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 QQnsvd09641 for ; Wed, 11 Dec 2002 21:28: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 QQnsvd02218; Wed, 11 Dec 2002 21:24:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsvd17677 for mpls-outgoing; Wed, 11 Dec 2002 21:24: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 QQnsvd17669 for ; Wed, 11 Dec 2002 21:24: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 QQnsvd02892 for ; Wed, 11 Dec 2002 21: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 QQnsvd01428 for ; Wed, 11 Dec 2002 21:24: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 QQnsvd01423 for ; Wed, 11 Dec 2002 21:24:06 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBBLOaxA024233 for ; Wed, 11 Dec 2002 16:24:36 -0500 (EST) 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 QAA21197 for ; Wed, 11 Dec 2002 16:24:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBBLO5M05067 for mpls@uu.net; Wed, 11 Dec 2002 16:24:05 -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 QQnsvd17627 for ; Wed, 11 Dec 2002 21:23:29 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 QQnsvd22706 for ; Wed, 11 Dec 2002 21:22:50 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 QQnsvd00629 for ; Wed, 11 Dec 2002 21:22:50 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 QQnsvd00624 for ; Wed, 11 Dec 2002 21:22:50 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 gBBLNGhK023991; Wed, 11 Dec 2002 16:23:17 -0500 (EST) Received: from tnadeau-w2k.cisco.com (rtp-vpn1-838.cisco.com [10.82.227.70]) by bucket.cisco.com (Mirapoint) with ESMTP id ACG32955; Wed, 11 Dec 2002 16:22:44 -0500 (EST) Message-Id: <5.2.0.9.2.20021211162143.01b236e8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 11 Dec 2002 16:22:41 -0500 To: jcucchiara@mindspring.com From: "Thomas D. Nadeau" Subject: RE: use of MPLS OID branch Cc: "Wijnen, Bert (Bert)" , "Mpls (E-mail)" , jcucchiara@mindspring.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 06:33 PM 12/6/2002 -0500, jcucchiara@mindspring.com wrote: >On Fri, 06 Dec 2002 17:26:48 -0500 "Thomas D. Nadeau" >wrote: > > > At 11:20 PM 12/6/2002 +0100, Wijnen, Bert > > (Bert) wrote: > > > > At 10:52 PM 12/6/2002 +0100, Wijnen, Bert > > (Bert) wrote: > > > > >What I was worried about when the WG does > > its own administration > > > > >and/or assigments of OIDs has happened. > > > > > > > > > >For example: > > > > > > > > > > mplsFTNMIB MODULE-IDENTITY > > > > > ... > > > > > ::= { mplsMIB 5 } > > > > > > > > > > mplsLdpFrameRelayMIB MODULE-IDENTITY > > > > > ... > > > > > ::= { mplsMIB 5 } -- to be assigned > > > > > > > > Propose we use: > > > > > > > > mplsMIB.1 - MPLS-TC > > > > mplsMIB.2 - MPLS-LSR > > > > mplsMIB.3 - MPLS-TE > > > > mplsMIB.4 - MPLS-FTN > > > > mplsMIB.5 - MPLS-LDP > > > > mplsMIB.6 - MPLS-LDP-GENERIC > > > > mplsMIB.6 - MPLS-LDP-ATM > > > > mplsMIB.7 - MPLS-LDP-FRAME-RELAY > > > > > > >Seems fine > > > > > > > >This is not good... Pls check them all and > > correct. > > > > >And what are we going to do to make sure > > we do not assign > > > > >an overlap in the future and running the > > risk that it gets > > > > >published as RFC ?? > > > > > > > > I thought that IANA would manage > > the mplsMIB space, > > > > no? > > > > > > >Well, if that is what you want (and that is > > fine with me) then > > >you need to do 2 things: > > > > > >- In the MPLS-TC-MIB document you must add an > > IANA Considerations > > > section in which you explain the new OID > > tree for mplsMib > > > and in whcih you explain the > > rules/guidelines for IANA on > > > how to decide on new assignments. It is a > > new namespace > > > for IANA to maintain > > > > > >- In all the MIB Modules you have, use > > > > > > ::= { mplsMib xx } -- xx to be assigned > > by IANA > > > > > > and add an IANA Considerations Section > > where you ask IANA to > > > assign the value. You can suggest to assign > > the value as per > > > your list above. > > > > Cool. > > > > >Now that we are on that topic, the things that > > MPLS-LDP-MIB document > > >imports OID branches in the GENERIC, ATM and > > FRAME_RELAY MIB Modules > > >from the LLLLDP-MIB module and then starts > > assigning underneath them, > > >that worries me in a similar manner. The > > assigments all happen in > > >different MIB mdoules (which can later move > > into separate documents > > >if they do not progress on stds track at same > > speed), and then > > >things may get out of sync. > > > > I will let Joan respond to this. > >The Generic, ATM and FrameRelay MIB modules >IMPORT from the MPLS-TC-MIB for the mplsMIB >number (and IMPORT from the MPLS-LDP-MIB for >some objects), so would agree that the >LDP-MIB document >needs to have IANA Consideration Section >which asks IANA for mplsMIB number >assignments. > >IF these MIB Modules move to different >documents (as Bert suggests above could >happen) then would think that these new >docs would need an IANA Considerations >Section also, right? Yes, I think we would if we want IANA to maintain the OIDs under MplsMIB. If we do not, then only the TC needs the IANA considerations document, and the others probably need some paragraph (common among all other docs) that explains where the MplsMIB OIDs come from (i.e.: you must ask the WG). --Tom >Would this be a reasonable solution? > > Thanks, > -Joan > > > > > > > > --Tom > > > > > > > > >Bert > > > > --Tom > > > > > > > > > > > > > > "The difficult, we do immediately. The impossible takes a little longer." -- Air Force Motto From owner-mpls@UU.NET Wed Dec 11 18:34:02 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 SAA25516 for ; Wed, 11 Dec 2002 18:34:02 -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 QQnsvm08789 for ; Wed, 11 Dec 2002 23:36: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 QQnsvm29705; Wed, 11 Dec 2002 23:31:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsvm05701 for mpls-outgoing; Wed, 11 Dec 2002 23:31: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 QQnsvm05687 for ; Wed, 11 Dec 2002 23:31:11 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 QQnsvm21240 for ; Wed, 11 Dec 2002 23:30:09 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 QQnsvm28148 for ; Wed, 11 Dec 2002 23:30:08 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 QQnsvm28126 for ; Wed, 11 Dec 2002 23:30:08 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBBNUaZu013341 for ; Wed, 11 Dec 2002 18:30:36 -0500 (EST) 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 SAA00801 for ; Wed, 11 Dec 2002 18:30:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBBNU5k16274 for mpls@uu.net; Wed, 11 Dec 2002 18:30:05 -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 QQnsvl05411 for ; Wed, 11 Dec 2002 23:28: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 QQnsvl22098 for ; Wed, 11 Dec 2002 23:28: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 QQnsvl15611 for ; Wed, 11 Dec 2002 23:28:27 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 QQnsvl15606 for ; Wed, 11 Dec 2002 23:28:25 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 SAA46776; Wed, 11 Dec 2002 18:26:05 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212112326.SAA46776@workhorse.fictitious.org> To: "David Allan" cc: curtis@fictitious.org, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: draft-ietf-mpls-lsp-ping-01.txt - ECMP considerations In-reply-to: Your message of "Tue, 10 Dec 2002 20:51:58 EST." <9FBD322B7824D511B36900508BF93C9C06746B4D@zcard031.ca.nortel.com> Date: Wed, 11 Dec 2002 18:26:05 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <9FBD322B7824D511B36900508BF93C9C06746B4D@zcard031.ca.nortel.com>, " David Allan" writes: > Hi Curtis: > > I think what you are proposing illustrates the complexity of the problem, > and highlights that we need a different approach in order for detecting > problems to be tractable. IMHO such constructs cannot be reliably and > proactively tested from a single arbitrary upstream point and what you > describe illustrates the complexity of actually performing meaningful > testing. This is compounded exponentially as load spreading points are > cascaded between the ingress and any point of failure. Suggesting that we throw our hands in the air and give up is not constructive. Fortunately you bring up some useful points below as "food for thought" that does move us forward. Thanks. > IMHO the correct answer is to proactively test from more than one point in > the network and depend on the aggregate effect of the whole, and not try to > produce a protocol that reverse engineers proprietary boxes. There is nothing any more proprietary than slightly differing implementations of OSPF ECMP would be. The world out their has a deployed based. All of the MPLS implementations that I know of allow ECMP to be configured enabled or disabled and ISPs don't have to turn it on but do. One of our customers made it very clear to us that they required that we implement ECMP for LDP. Most indicate MP for TE (split IP traffic at ingress) and LDP are requirements. > Each load spreading point should behave as a set of ingresses (from the POV > of probe injection) for some low frequency of probes. You live with not > necessaraily exercising all aspects of the actual load spreader but that is > true for any approach that is not ICMP monotonically going through the IP > address plan. If there are 24 paths from A to B, and the traceroute step if successfull, will return sufficient information to provide 24 destinations that will exercise all of the paths. > This will provide bounded error detection in the network. Ideally you need > some smarts to locate the probe source closest to and upstream of the point > of failure once somthing goes wrong. > > food for thought > Dave I don't think injecting traffic at each branch point will prove necessary even for multiple branch points. If in a deployment it was determined that it was needed, no change to the MPLS-ping protocol is needed except to note that the traffic can be injected at a midpoint LSR, not just at an ingress LSR. This may already be intended by the authors but not specifically indicated. In such a usage, the ingress would test up to and through the first branch point, including all paths leading out of the first branch point. At the first branch point, each branch would be tested up to and through each second branch point. This would continue until all branches reached the egress. This would still require use of more than one address from 127/8 and would require that the source of the MPLS-ping requests be notified of the means to exercise the one branch point immediately downstream. If we wanted to retain the ability to test from the ingress, then we'd have to include MPLS-ping protocol support to allow a branch point to proxy test the MP LSP further downstream and report back to the ingress. This would not be overly difficult. It also removes any concern about correlating the hash behaviour of multiple branch points to exercise paths further downstream and in doing so completely removes the need to know anything about the algorithm used for MP, other than one or more address to exercise each immediate branch. Curtis From owner-mpls@UU.NET Wed Dec 11 18:44: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 SAA25744 for ; Wed, 11 Dec 2002 18:44:38 -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 QQnsvn04624 for ; Wed, 11 Dec 2002 23:47:32 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 QQnsvn00365; Wed, 11 Dec 2002 23:45:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsvm06746 for mpls-outgoing; Wed, 11 Dec 2002 23:44: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 QQnsvm06738 for ; Wed, 11 Dec 2002 23:44: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 QQnsvm20318 for ; Wed, 11 Dec 2002 23:44:09 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 QQnsvm28029 for ; Wed, 11 Dec 2002 23:44:09 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 QQnsvm28024 for ; Wed, 11 Dec 2002 23:44:08 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 gBBNhsh25361; Wed, 11 Dec 2002 18:43:55 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 11 Dec 2002 18:43:55 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C0674756E@zcard031.ca.nortel.com> From: "David Allan" To: curtis@fictitious.org Cc: curtis@fictitious.org, mpls@UU.NET Subject: RE: draft-ietf-mpls-lsp-ping-01.txt - ECMP considerations Date: Wed, 11 Dec 2002 18:43:53 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Curtis: I'm FAR from throwing my hands up in the air..... ;-) Just trying to move the mountain (and some thinking). If I did not make it clear, for figuring out what went wrong once yoou know somthing is wrong, I bellieve you are on the right path, and I've privately forewarded some suggestions as to how the approach can be improved for the cascaded case. I'd much rather know how to authoriatively test somthing than simply guess. As for knowing somthing is broken in a reasonable time, I still think the aggregate of probe behavior needs to be observed, and I'll bring forward some stuff for SF. Cheers Dave > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: Wednesday, December 11, 2002 6:26 PM > To: Allan, David [CAR:NS00:EXCH] > Cc: curtis@fictitious.org; mpls@UU.NET > Subject: Re: draft-ietf-mpls-lsp-ping-01.txt - ECMP considerations > > > > In message > <9FBD322B7824D511B36900508BF93C9C06746B4D@zcard031.ca.nortel.com>, " > David Allan" writes: > > Hi Curtis: > > > > I think what you are proposing illustrates the complexity > of the problem, > > and highlights that we need a different approach in order > for detecting > > problems to be tractable. IMHO such constructs cannot be > reliably and > > proactively tested from a single arbitrary upstream point > and what you > > describe illustrates the complexity of actually performing > meaningful > > testing. This is compounded exponentially as load spreading > points are > > cascaded between the ingress and any point of failure. > > Suggesting that we throw our hands in the air and give up is not > constructive. Fortunately you bring up some useful points below as > "food for thought" that does move us forward. Thanks. > > > IMHO the correct answer is to proactively test from more > than one point in > > the network and depend on the aggregate effect of the > whole, and not try to > > produce a protocol that reverse engineers proprietary boxes. > > There is nothing any more proprietary than slightly differing > implementations of OSPF ECMP would be. > > The world out their has a deployed based. All of the MPLS > implementations that I know of allow ECMP to be configured enabled or > disabled and ISPs don't have to turn it on but do. One of our > customers made it very clear to us that they required that we > implement ECMP for LDP. Most indicate MP for TE (split IP traffic at > ingress) and LDP are requirements. > > > Each load spreading point should behave as a set of > ingresses (from the POV > > of probe injection) for some low frequency of probes. You > live with not > > necessaraily exercising all aspects of the actual load > spreader but that is > > true for any approach that is not ICMP monotonically going > through the IP > > address plan. > > If there are 24 paths from A to B, and the traceroute step if > successfull, will return sufficient information to provide 24 > destinations that will exercise all of the paths. > > > This will provide bounded error detection in the network. > Ideally you need > > some smarts to locate the probe source closest to and > upstream of the point > > of failure once somthing goes wrong. > > > > food for thought > > Dave > > I don't think injecting traffic at each branch point will prove > necessary even for multiple branch points. If in a deployment it was > determined that it was needed, no change to the MPLS-ping protocol is > needed except to note that the traffic can be injected at a midpoint > LSR, not just at an ingress LSR. This may already be intended by the > authors but not specifically indicated. In such a usage, the ingress > would test up to and through the first branch point, including all > paths leading out of the first branch point. At the first branch > point, each branch would be tested up to and through each second > branch point. This would continue until all branches reached the > egress. This would still require use of more than one address from > 127/8 and would require that the source of the MPLS-ping requests be > notified of the means to exercise the one branch point immediately > downstream. > > If we wanted to retain the ability to test from the ingress, then we'd > have to include MPLS-ping protocol support to allow a branch point to > proxy test the MP LSP further downstream and report back to the > ingress. This would not be overly difficult. It also removes any > concern about correlating the hash behaviour of multiple branch points > to exercise paths further downstream and in doing so completely > removes the need to know anything about the algorithm used for MP, > other than one or more address to exercise each immediate branch. > > Curtis > From owner-mpls@UU.NET Wed Dec 11 19:25:44 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 TAA27057 for ; Wed, 11 Dec 2002 19:25:44 -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 QQnsvp01658 for ; Thu, 12 Dec 2002 00:28: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 QQnsvp20268; Thu, 12 Dec 2002 00:23:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsvp28397 for mpls-outgoing; Thu, 12 Dec 2002 00:22: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 QQnsvp28392 for ; Thu, 12 Dec 2002 00:22:51 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 QQnsvp19690 for ; Thu, 12 Dec 2002 00:22: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 QQnsvp19539 for ; Thu, 12 Dec 2002 00:22:14 GMT Received: from hoemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQnsvp19531 for ; Thu, 12 Dec 2002 00:22:13 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 gBC0MBT06994 for ; Wed, 11 Dec 2002 19:22:12 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Dec 2002 01:22:10 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1551B@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Thomas D. Nadeau" , jcucchiara@mindspring.com Cc: "Mpls (E-mail)" , jcucchiara@mindspring.com Subject: RE: use of MPLS OID branch Date: Thu, 12 Dec 2002 01:22:08 +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 > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: woensdag 11 december 2002 22:23 > To: jcucchiara@mindspring.com > Cc: Wijnen, Bert (Bert); Mpls (E-mail); jcucchiara@mindspring.com > Subject: RE: use of MPLS OID branch > > At 06:33 PM 12/6/2002 -0500, jcucchiara@mindspring.com wrote: > >On Fri, 06 Dec 2002 17:26:48 -0500 "Thomas D. Nadeau" > >wrote: > > .. snip .. > >The Generic, ATM and FrameRelay MIB modules > >IMPORT from the MPLS-TC-MIB for the mplsMIB > >number (and IMPORT from the MPLS-LDP-MIB for > >some objects), so would agree that the > >LDP-MIB document > >needs to have IANA Consideration Section > >which asks IANA for mplsMIB number > >assignments. > > > >IF these MIB Modules move to different > >documents (as Bert suggests above could > >happen) then would think that these new > >docs would need an IANA Considerations > >Section also, right? > > Yes, I think we would if we want IANA > to maintain the OIDs under MplsMIB. If we > do not, then only the TC needs the IANA > considerations document, and the others > probably need some paragraph (common among > all other docs) that explains where the MplsMIB OIDs > come from (i.e.: you must ask the WG). > Well... you are assuming the WG will exist forever here, are you not? And I don;t think that that is a given. Bert > --Tom > From owner-mpls@UU.NET Wed Dec 11 19:39:33 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 TAA27411 for ; Wed, 11 Dec 2002 19:39:33 -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 QQnsvq24667 for ; Thu, 12 Dec 2002 00:42: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 QQnsvq14201; Thu, 12 Dec 2002 00:36:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsvq29294 for mpls-outgoing; Thu, 12 Dec 2002 00:35:57 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 QQnsvq29276 for ; Thu, 12 Dec 2002 00:35: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 QQnsvq05816 for ; Thu, 12 Dec 2002 00:35: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 QQnsvq13131 for ; Thu, 12 Dec 2002 00:35:13 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 QQnsvq13124 for ; Thu, 12 Dec 2002 00:35:13 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBC0ZeWG020226 for ; Wed, 11 Dec 2002 19:35:41 -0500 (EST) 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 TAA04561 for ; Wed, 11 Dec 2002 19:35:10 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBC0ZAQ22414 for mpls@uu.net; Wed, 11 Dec 2002 19:35:10 -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 QQnsvq29199 for ; Thu, 12 Dec 2002 00:34:21 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 QQnsvq12630 for ; Thu, 12 Dec 2002 00:33: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 QQnsvq11957 for ; Thu, 12 Dec 2002 00:33:49 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 QQnsvq11945 for ; Thu, 12 Dec 2002 00:33:49 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 gBC0YCGW020058; Wed, 11 Dec 2002 19:34:12 -0500 (EST) Received: from tnadeau-w2k.cisco.com (rtp-vpn1-838.cisco.com [10.82.227.70]) by bucket.cisco.com (Mirapoint) with ESMTP id ACG36485; Wed, 11 Dec 2002 19:33:40 -0500 (EST) Message-Id: <5.2.0.9.2.20021211193206.0215dda0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 11 Dec 2002 19:33:36 -0500 To: "Wijnen, Bert (Bert)" From: "Thomas D. Nadeau" Subject: RE: use of MPLS OID branch Cc: jcucchiara@mindspring.com, "Mpls (E-mail)" In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1551B@nl0006exch001u.nl.lucen t.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 01:22 AM 12/12/2002 +0100, Wijnen, Bert (Bert) wrote: > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: woensdag 11 december 2002 22:23 > > To: jcucchiara@mindspring.com > > Cc: Wijnen, Bert (Bert); Mpls (E-mail); jcucchiara@mindspring.com > > Subject: RE: use of MPLS OID branch > > > > At 06:33 PM 12/6/2002 -0500, jcucchiara@mindspring.com wrote: > > >On Fri, 06 Dec 2002 17:26:48 -0500 "Thomas D. Nadeau" > > >wrote: > > > > >.. snip .. > > >The Generic, ATM and FrameRelay MIB modules > > >IMPORT from the MPLS-TC-MIB for the mplsMIB > > >number (and IMPORT from the MPLS-LDP-MIB for > > >some objects), so would agree that the > > >LDP-MIB document > > >needs to have IANA Consideration Section > > >which asks IANA for mplsMIB number > > >assignments. > > > > > >IF these MIB Modules move to different > > >documents (as Bert suggests above could > > >happen) then would think that these new > > >docs would need an IANA Considerations > > >Section also, right? > > > > Yes, I think we would if we want IANA > > to maintain the OIDs under MplsMIB. If we > > do not, then only the TC needs the IANA > > considerations document, and the others > > probably need some paragraph (common among > > all other docs) that explains where the MplsMIB OIDs > > come from (i.e.: you must ask the WG). > > >Well... you are assuming the WG will exist forever here, are >you not? And I don;t think that that is a given. I had thought of that, but then I though why would MIBs for MPLS be developed that go under the MPLS branch w/o concent of the MPLS WG (or one responsible for maintaining the OID tree)? I guess the question is how did the WG you cited earlier keep track of them? If you think there will be any problems, I vote we just give the OID maintenance to IANA. --Tom From owner-mpls@UU.NET Wed Dec 11 19:45:00 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 TAA27495 for ; Wed, 11 Dec 2002 19:45:00 -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 QQnsvr22445 for ; Thu, 12 Dec 2002 00:47:54 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 QQnsvr19486; Thu, 12 Dec 2002 00:46:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsvr00687 for mpls-outgoing; Thu, 12 Dec 2002 00:45: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 QQnsvr00655 for ; Thu, 12 Dec 2002 00:45:46 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 QQnsvq27315 for ; Thu, 12 Dec 2002 00:43: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 QQnsvq25904 for ; Thu, 12 Dec 2002 00:43:37 GMT Received: from hoemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQnsvq25887 for ; Thu, 12 Dec 2002 00:43:37 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 gBC0hZT13130 for ; Wed, 11 Dec 2002 19:43:35 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Dec 2002 01:43:34 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15520@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Thomas D. Nadeau" , "Wijnen, Bert (Bert)" Cc: jcucchiara@mindspring.com, "Mpls (E-mail)" Subject: RE: use of MPLS OID branch Date: Thu, 12 Dec 2002 01:43:33 +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 > > > >IF these MIB Modules move to different > > > >documents (as Bert suggests above could > > > >happen) then would think that these new > > > >docs would need an IANA Considerations > > > >Section also, right? > > > > > > Yes, I think we would if we want IANA > > > to maintain the OIDs under MplsMIB. If we > > > do not, then only the TC needs the IANA > > > considerations document, and the others > > > probably need some paragraph (common among > > > all other docs) that explains where the MplsMIB OIDs > > > come from (i.e.: you must ask the WG). > > > > >Well... you are assuming the WG will exist forever here, are > >you not? And I don;t think that that is a given. > > I had thought of that, but then I though why > would MIBs for MPLS be developed that go under > the MPLS branch w/o concent of the MPLS WG (or > one responsible for maintaining the OID tree)? I guess > the question is how did the WG you cited earlier > keep track of them? If you think there will be any problems, > I vote we just give the OID maintenance to IANA. > That WG is the RMON WG. And I am worried baout them too. They are still around for a while. but they will shutdown at some point. I think at that time I also do want them to write an IANA considerations that explains how new assignments will be done. Bert > --Tom > > From owner-mpls@UU.NET Wed Dec 11 20: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 UAA28685 for ; Wed, 11 Dec 2002 20:46:31 -0500 (EST) 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 QQnsul08812; Wed, 11 Dec 2002 16:56:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsul21136 for mpls-outgoing; Wed, 11 Dec 2002 16:56:16 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 QQnsul20870 for ; Wed, 11 Dec 2002 16:55: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 QQnsul26883 for ; Wed, 11 Dec 2002 16:54: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 QQnsul04010 for ; Wed, 11 Dec 2002 16:54:39 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 QQnsul03998 for ; Wed, 11 Dec 2002 16:54:39 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBBGt8ES013018 for ; Wed, 11 Dec 2002 11:55:08 -0500 (EST) 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 LAA26942 for ; Wed, 11 Dec 2002 11:54:37 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBBGsbv29146 for mpls@uu.net; Wed, 11 Dec 2002 11:54:37 -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 QQnsul20496 for ; Wed, 11 Dec 2002 16:51:53 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 QQnsul18456 for ; Wed, 11 Dec 2002 16:51: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 QQnsul29815 for ; Wed, 11 Dec 2002 16:51:21 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 QQnsul29789 for ; Wed, 11 Dec 2002 16:51:21 GMT Received: (qmail 13844 invoked by uid 104); 11 Dec 2002 16:51:20 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4236. . Clean. Processed in 0.942553 secs); 11 Dec 2002 16:51:20 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 11 Dec 2002 16:51:19 -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 gBBGpIQ04407; Wed, 11 Dec 2002 08:51:19 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Wed, 11 Dec 2002 08:51:18 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B81@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Kireeti Kompella'" , Curtis Villamizar Cc: mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Wed, 11 Dec 2002 08:51:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Agree and accepted. -Shahram > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Wednesday, December 11, 2002 6:13 AM > To: Curtis Villamizar > Cc: mpls@UU.NET > Subject: Re: Last call on LSP Ping > > > > > On Mon, 9 Dec 2002, Curtis Villamizar wrote: > > > > First of all I did propose using the egress IP address > and setting the > > > TTL=1 in the IP header. This makes sure that the LSP-ping > packet will > > > not get forwarded after the MPLS labels are poped. > > > > Glad to see this change to a technical discussion. Took a while. > > :-) > > > This proposal has two flaws, 1) when the label gets POPed and the > > egress isn't the router you thought it should be the response is an > > ICMP TTL expired, 2) no way to handle ECMP is proposed. > > Big flaw: there ain't no such thing as *the* egress router. Some > router "at the other end of the network" announces a label mapping > for 9/8, and this mapping makes its way to me. How do I know who > the egress router is? Moreover, there could be many routers > announcing > 9/8 ... > > Kireeti. > > PS: IP TTL = 1 is already in the draft. > From owner-mpls@UU.NET Wed Dec 11 23:19: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 XAA02681 for ; Wed, 11 Dec 2002 23:19:03 -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 QQnswf17966 for ; Thu, 12 Dec 2002 04:21:58 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 QQnswf15949; Thu, 12 Dec 2002 04:20:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQnswf02341 for mpls-outgoing; Thu, 12 Dec 2002 04:20: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 QQnswf02335 for ; Thu, 12 Dec 2002 04:20:29 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 QQnswf01186 for ; Thu, 12 Dec 2002 04:19:56 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 QQnswf15901 for ; Thu, 12 Dec 2002 04:19:56 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 QQnswf15895 for ; Thu, 12 Dec 2002 04:19:55 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 gBC4JtS89019; Wed, 11 Dec 2002 20:19:55 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id gBC4Jta23508; Wed, 11 Dec 2002 20:19:55 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Wed, 11 Dec 2002 20:19:54 -0800 (PST) From: Kireeti Kompella To: David Allan cc: Subject: RE: Last call on LSP Ping In-Reply-To: <9FBD322B7824D511B36900508BF93C9C06565472@zcard031.ca.nortel.com> Message-ID: <20021211201407.Q23475-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Dave, On Wed, 4 Dec 2002, David Allan wrote: > I have a concern with the draft. Embedded in the protocol are a number of > features designed to test proprietary behaviors (load balancing). How these > would be used IMHO is insufficiently well documented to ensure > interoperability. On that basis I do not think the document is ready. I think this has been done sufficiently to death. I'll hunt down and read Curtis's proposed text and comment. > One specific example that come to mind is the description of "downstream > router". I consider to be poorly explained. > > Now the text: > "a packet with outermost label L and TTL n>1 arrives at X"..... OK > > "X must be able to compute which LSRs could receive the packet with TTL=n+1" > whoa, where the packet came from? I thought TTL decremented. I presume the > correct text should be "what LSRs would receive the packet if forwarded from > X with TTL=1". > > "the set of LSRs are the downstream routers....for X with respect to L", > > So what are we discussing here, the LSRs upstream of X, downstream of X, the > specific NHLFE that load balancing resolves to given the specific details of > the packet (src address and 127./8 and whatever else the propretary > implementation considers) or the set that the FTN/ILM maps to prior to any > actual load balancing computations (is it "a" packet or "any" packet mapping > to the FEC associated with the LSP). Explained in reply to Shahram -- does that work for you? > If the intent is to provide a mechanism to fully exercise any and all > potential load balancing configurations and to understand what > configurations were tested, this would appear to come up short. When > attempting to traceroute such a configuration, the LSR originating the trace > either: > - knows there is a problem and knows what specific 127./8 will supposedly > reproduce the problem but knows little else about the network. > - knows there is a problem but may not know what specific 127./8 will > reproduce it, therefore wishes to exercise all possibilities AND needs to be > able to verify that it did so. Therefore there is an element of "topology > discovery" inherent to performing such a traceroute. > - there may not be a problem but the LSR wishes to exercise the whole > downstream construct anyway. > > Given the description, and the ambiguities in the text, it is not clear to > me what I could build and successfully interoperate with the LSR next > door.... MPLS to the kerb (curb)? > BTW it would be useful to explicitly state in 3.2 that the downstream > mapping TLV is only valid in "traceroute mode", and that it is optional in > echo requests, and mandatory in echo replies. See reply to Shahram. > Other minor comments: > > - won't claim to be an expert, would TTL exhaust on an internal loopback > address generate an ICMP message back to the ping originator (which it > should be ignoring)? > > - downstream mapping permits multiple labels per interface to be described > in an echo request, but the reply can only indicate that "it arrived on one > of them" rather than which specific one (which may matter). The "multiple" labels are a stack (see reply to Shahram). > IMHO it would be useful to have the sequence number explicitly correspond to > the LSB of the 127./8 used as I would presume otherwise the echo request > originating LSR would need to remember such details associated with the > sequence number (as the reply would not contain the address). (I'm assuming > that the sequence number is used uniquely with the LSP under test, and the > handle exists as the indexing mechanism for replies independent of the > specific LSP under consideration). T'would also facilitate picking out gaps > due to black holes in load balancing constructs esp. in don't reply mode. I don't see the utility of this. The LSB of the address is in the packet. > - not clear how the example of testing stacked FECs would work in CSC > scenarios, perhaps an author could comment? You'll have to explain, starting with expanding "CSC". Kireeti. From owner-mpls@UU.NET Thu Dec 12 05:09: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 FAA18626 for ; Thu, 12 Dec 2002 05:09:51 -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 QQnsxc03969 for ; Thu, 12 Dec 2002 10:12: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 QQnsxc29019; Thu, 12 Dec 2002 10:10:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsxc17647 for mpls-outgoing; Thu, 12 Dec 2002 10:09:42 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 QQnsxc17642 for ; Thu, 12 Dec 2002 10:09:25 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 QQnsxc05961 for ; Thu, 12 Dec 2002 10:09:08 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 QQnsxc21358 for ; Thu, 12 Dec 2002 10:09:08 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 QQnsxc21350 for ; Thu, 12 Dec 2002 10:09:07 GMT Received: by cbibipnt08.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Thu, 12 Dec 2002 10:08:35 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A35389014CFD04@i2km07-ukbr.domain1.systemhost.net> To: dallan@nortelnetworks.com Cc: mpls@UU.NET Subject: RE: draft-ietf-mpls-lsp-ping-01.txt - ECMP considerations Date: Thu, 12 Dec 2002 10:08:17 -0000 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 Dave, please see below. regards, Neil > -----Original Message----- > From: David Allan [mailto:dallan@nortelnetworks.com] > Sent: 11 December 2002 23:44 > To: curtis@fictitious.org > Cc: curtis@fictitious.org; mpls@UU.NET > Subject: RE: draft-ietf-mpls-lsp-ping-01.txt - ECMP considerations > > > Curtis: > > I'm FAR from throwing my hands up in the air..... ;-) Just > trying to move > the mountain (and some thinking). > > If I did not make it clear, for figuring out what went wrong > once yoou know > somthing is wrong, NH=> This is an important point. The discussion would have a far clearer basis for comment/analysis if we first identified/agreed all the failure conditions we want to detect, and the consequent actions that must be activated on such. Discussing nuances of ECMP and the rights/wrongs of the LSP-Ping protocol without having this clear separation of (i) detection and (ii) diagnostics as a bsis for discussion is not very helpful IMO. From owner-mpls@UU.NET Thu Dec 12 10:20:14 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 KAA27020 for ; Thu, 12 Dec 2002 10:20:14 -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 QQnsxx07454 for ; Thu, 12 Dec 2002 15:23: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 QQnsxx01482; Thu, 12 Dec 2002 15:20:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsxx13796 for mpls-outgoing; Thu, 12 Dec 2002 15:20: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 QQnsxx13787 for ; Thu, 12 Dec 2002 15:20:05 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 QQnsxx15161 for ; Thu, 12 Dec 2002 15:19: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 QQnsxx00014 for ; Thu, 12 Dec 2002 15:19:42 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQnsxx29998 for ; Thu, 12 Dec 2002 15:19:41 GMT Received: from cisco.com (erosen-u10.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBCFJeFp021871; Thu, 12 Dec 2002 07:19:40 -0800 (PST) Message-Id: <200212121519.gBCFJeFp021871@sj-msg-core-1.cisco.com> To: mpls@UU.NET Subject: Minor comment on lsp-ping draft Reply-to: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 12 Dec 2002 10:19:39 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk I think that sections 3.1.7 ("L2 VPN Endpoints") and 3.1.8 ("L2 Circuit ID") should be removed from this document. That material really belongs in the L2VPN and PWE3 documents themselves. By following this suggestion, we eliminate two problems: 1. The risk that the PWE3 and L2VPN documents will be interpreted as normative references. 2. The delay that will occur while we make sure that everybody's favorite L2VPN scheme is represented in the document, rather than just one particular scheme. From owner-mpls@UU.NET Thu Dec 12 11:08: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 LAA29153 for ; Thu, 12 Dec 2002 11:08:48 -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 QQnsya25736 for ; Thu, 12 Dec 2002 16:11: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 QQnsya20116; Thu, 12 Dec 2002 16:08:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsya06400 for mpls-outgoing; Thu, 12 Dec 2002 16:07:53 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 QQnsya06348 for ; Thu, 12 Dec 2002 16:07:36 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 QQnsya17823 for ; Thu, 12 Dec 2002 16:07: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 QQnsya19110 for ; Thu, 12 Dec 2002 16:07:07 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 QQnsya19102 for ; Thu, 12 Dec 2002 16:07:06 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBCG7a0T000192 for ; Thu, 12 Dec 2002 11:07:36 -0500 (EST) 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 LAA21128 for ; Thu, 12 Dec 2002 11:07:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBCG75X17535 for mpls@uu.net; Thu, 12 Dec 2002 11:07:05 -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 QQnsya06004 for ; Thu, 12 Dec 2002 16:05:46 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 QQnsya04561 for ; Thu, 12 Dec 2002 16:02: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 QQnsya15731 for ; Thu, 12 Dec 2002 16:02:48 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 QQnsya15726 for ; Thu, 12 Dec 2002 16:02:48 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 gBCG2uhA029237; Thu, 12 Dec 2002 11:02:57 -0500 (EST) Received: from tnadeau-w2k.cisco.com (rtp-vpn1-838.cisco.com [10.82.227.70]) by bucket.cisco.com (Mirapoint) with ESMTP id ACG44481; Thu, 12 Dec 2002 11:02:24 -0500 (EST) Message-Id: <5.2.0.9.2.20021212110109.02367238@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 12 Dec 2002 11:02:18 -0500 To: "Wijnen, Bert (Bert)" From: "Thomas D. Nadeau" Subject: RE: use of MPLS OID branch Cc: "Wijnen, Bert (Bert)" , jcucchiara@mindspring.com, "Mpls (E-mail)" In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15520@nl0006exch001u.nl.lucen t.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 01:43 AM 12/12/2002 +0100, Wijnen, Bert (Bert) wrote: > > > > >IF these MIB Modules move to different > > > > >documents (as Bert suggests above could > > > > >happen) then would think that these new > > > > >docs would need an IANA Considerations > > > > >Section also, right? > > > > > > > > Yes, I think we would if we want IANA > > > > to maintain the OIDs under MplsMIB. If we > > > > do not, then only the TC needs the IANA > > > > considerations document, and the others > > > > probably need some paragraph (common among > > > > all other docs) that explains where the MplsMIB OIDs > > > > come from (i.e.: you must ask the WG). > > > > > > >Well... you are assuming the WG will exist forever here, are > > >you not? And I don;t think that that is a given. > > > > I had thought of that, but then I though why > > would MIBs for MPLS be developed that go under > > the MPLS branch w/o concent of the MPLS WG (or > > one responsible for maintaining the OID tree)? I guess > > the question is how did the WG you cited earlier > > keep track of them? If you think there will be any problems, > > I vote we just give the OID maintenance to IANA. > > >That WG is the RMON WG. >And I am worried baout them too. They are still around for a >while. but they will shutdown at some point. I think at that >time I also do want them to write an IANA considerations >that explains how new assignments will be done. I cannot speak for Joan and the other co-authors, but given your description, I personally don't want to have to be involved in policing the OID space, so I vote that we just go with an IANA management of the MplsMIB OID space. --Tom "The difficult, we do immediately. The impossible takes a little longer." -- Air Force Motto From owner-mpls@UU.NET Thu Dec 12 11: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 LAA01476 for ; Thu, 12 Dec 2002 11:50:36 -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 QQnsyd08976 for ; Thu, 12 Dec 2002 16:53: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 QQnsyd05778; Thu, 12 Dec 2002 16:51:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsyd11281 for mpls-outgoing; Thu, 12 Dec 2002 16:50: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 QQnsyd11272 for ; Thu, 12 Dec 2002 16:50:41 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 QQnsyd24789 for ; Thu, 12 Dec 2002 16:50: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 QQnsyd26092 for ; Thu, 12 Dec 2002 16:50:08 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 QQnsyd26077 for ; Thu, 12 Dec 2002 16:50:08 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBCGoa4G007333 for ; Thu, 12 Dec 2002 11:50:36 -0500 (EST) 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 LAA25106 for ; Thu, 12 Dec 2002 11:50:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBCGo5a21595 for mpls@uu.net; Thu, 12 Dec 2002 11:50:05 -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 QQnsyd11055 for ; Thu, 12 Dec 2002 16:48:38 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 QQnsyd20716 for ; Thu, 12 Dec 2002 16:48: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 QQnsyd24811 for ; Thu, 12 Dec 2002 16:48:29 GMT Received: from fythlt by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: [213.181.66.226]) id QQnsyc21030 for ; Thu, 12 Dec 2002 16:43:23 GMT From: Monte Marti To: Subject: Increase energy and cardiac output e Date: Fri, 13 Dec 2002 00:41:27 -0800 Mime-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: base64 Message-Id: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5BbnRpLUFnaW5nIFBvd2VyIC0gSEdIIFByb2R1Y3Rz PC90aXRsZT4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4 dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPC9oZWFkPg0KDQo8Ym9keT4NCjx0YWJs ZSB3aWR0aD0iNjAwIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSI0IiBjZWxsc3BhY2luZz0i MCI+DQogIDx0cj4NCiAgICA8dGQgcm93c3Bhbj0iMiIgdmFsaWduPSJ0b3AiPjxhIGhyZWY9 Imh0dHA6Ly93d3cuc2hvcHBpbmdhbGx0aGV3YXkuY29tL2hnaC93ZWxjb21lMi5odG1sP2Fm ZmlkPW84ODgmZT1tcGxzQHV1Lm5ldCZuMDI9eGV2Znhmb2ZoaWlhZWJ0YnZ3aXV0cXJ3dmRx ZHJocnFubnhsIj48aW1nIHNyYz0iaHR0cDovLzYxLjE3Mi4yNDUuMzkvZW1haWwuanBnIiBi b3JkZXI9MD48L2E+PC90ZD4NCiAgICA8dGQgdmFsaWduPSJ0b3AiIGFsaWduPSJjZW50ZXIi Pjxmb250IGNvbG9yPSIjRkYwMDAwIiBzaXplPSI0IiBmYWNlPSJHZW5ldmEsIEFyaWFsLCBI ZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPjxlbT48c3Ryb25nPlRoZSANCiAgICAgIEFudGktQWdp bmcgUG93ZXI6IEhHSCBQcm9kdWN0czwvc3Ryb25nPjwvZW0+PC9mb250PjwvdGQ+DQogIDwv dHI+DQogIDx0cj4NCiAgCTx0ZD48dGFibGUgYm9yZGVyPSIyIiBib3JkZXJjb2xvcj0iIzAw MzM5OSIgY2VsbHBhZGRpbmc9IjMiIGNlbGxzcGFjaW5nPSIwIj4NCgkJICA8dHI+CQkJDQog ICAgICAgICAgPHRkIGJnY29sb3I9IiMwMDMzNjYiPjxkaXYgYWxpZ249ImNlbnRlciI+PGZv bnQgY29sb3I9IiNGRkZGRkYiIGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYi PjxzdHJvbmc+PGZvbnQgc2l6ZT0iMyI+Q2xpbmljYWxseSANCiAgICAgICAgICAgICAgVGVz dGVkIE5hdHVyYWwgSEdIIE9yYWwgU3ByYXkgQm9vc3RzIEVuZXJneSBhbmQgSW1tdW5pdHk8 L2ZvbnQ+PC9zdHJvbmc+PC9mb250PjwvZGl2PjwvdGQ+DQoJCSAgPC90cj4NCgkJICA8dHI+ CQkJDQogICAgICAgICAgPHRkIGJnY29sb3I9IiNGRkZGOTkiIHZhbGlnbj0idG9wIj48Zm9u dCBzaXplPSIxIiBmYWNlPSJWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlm Ij5JbiANCiAgICAgICAgICAgIEFwcmlsIDIwMDIsIHRoZSBmaXJzdCBwbGFjZWJvLWNvbnRy b2xsZWQgc3R1ZHkgb2YgYSBuYXR1cmFsIEhHSCBvcmFsIA0KICAgICAgICAgICAgc3ByYXkg YXBwZWFyZWQgaW4gdGhlIEpvdXJuYWwgb2YgTG9uZ2V2aXR5LiBUaGlzIHN0dWR5IHJldmVh bGVkIHRoYXQgDQogICAgICAgICAgICB0aGUgc3ByYXkgZW5jb3VyYWdlcyBwcm9kdWN0aW9u IG9mIHRoZSBib2R5J3MgIm1hc3RlciBob3Jtb25lIiwgYWxzbyANCiAgICAgICAgICAgIGtu b3duIGFzIEhHSCBvciBIdW1hbiBHcm93dGggSG9ybW9uZS4gSW4gY29uY2x1c2lvbiwgdGhl IHJlc2VhcmNoZXJzIA0KICAgICAgICAgICAgZGlzY292ZXJlZCB0aGF0IHRoZSBoaWdoIGFi c29ycHRpb24gcmF0ZSBwcm92aWRlZCBieSB0aGUgb3JhbCBzcHJheSANCiAgICAgICAgICAg IHN5c3RlbSBpbmNyZWFzZWQgSEdIIGluIHRoZSBib2R5IGJ5IDMwJSBpbiBvbmx5IHRocmVl IHdlZWtzLiBBbiBpbmNyZWFzZSANCiAgICAgICAgICAgIG9mIEhHSCBwcm9kdWN0aW9uIHBy b3ZlcyB0byBib29zdCBlbmVyZ3kgYW5kIHN0cmVuZ3RoZW4gaW1tdW5pdHkuIDwvZm9udD48 L3RkPg0KCQkgIDwvdHI+DQoJCTwvdGFibGU+DQoJPC90ZD4NCiAgPC90cj4NCiAgPHRyPg0K ICAgIDx0ZCBjb2xzcGFuPSIiPjxkaXYgYWxpZ249ImNlbnRlciI+PHN0cm9uZz48Zm9udCBj b2xvcj0iI0ZGMDAwMCIgc2l6ZT0iMyIgZmFjZT0iVmVyZGFuYSwgQXJpYWwsIEhlbHZldGlj YSwgc2Fucy1zZXJpZiI+PGVtPlNwZWNpYWwhIA0KICAgICAgICA8YnI+DQogICAgICAgIEZv ciBsaW1pdGVkIHRpbWUgb25seSE8L2VtPjwvZm9udD48Zm9udCBjb2xvcj0iI0ZGMDAwMCIg c2l6ZT0iMyIgZmFjZT0iVmVyZGFuYSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiI+ PGJyPg0KICAgICAgICA8Zm9udCBzaXplPSI0Ij48YSBocmVmPSJodHRwOi8vd3d3LnNob3Bw aW5nYWxsdGhld2F5LmNvbS9oZ2gvd2VsY29tZTIuaHRtbD9hZmZpZD1vODg4JmU9bXBsc0B1 dS5uZXQmbjAyPXhldmZ4Zm9maGlpYWVidGJ2d2l1dHFyd3ZkcWRyaHJxbm54bCI+QlVZIDIg R0VUIDEgRlJFRSE8L2E+PC9mb250PjwvZm9udD48L3N0cm9uZz48L2Rpdj48L3RkPg0KCTx0 ZCBhbGlnbj0iY2VudGVyIiB2YWxpZ249Im1pZGRsZSI+PGEgaHJlZj0iaHR0cDovL3d3dy5z aG9wcGluZ2FsbHRoZXdheS5jb20vaGdoL3dlbGNvbWUyLmh0bWw/YWZmaWQ9bzg4OCZlPW1w bHNAdXUubmV0Jm4wMj14ZXZmeGZvZmhpaWFlYnRidndpdXRxcnd2ZHFkcmhycW5ueGwiPjxp bWcgc3JjPSJodHRwOi8vNjEuMTcyLjI0NS4zOS9lbWFpbC1vcmRlci5qcGciIHdpZHRoPSIy MDAiIGhlaWdodD0iODEiIGJvcmRlcj0wPjwvYT48L3RkPg0KICA8L3RyPg0KICA8dHI+DQog IAk8dGQ+PHRhYmxlIHdpZHRoPSIxMDAlIiBib3JkZXI9IjIiIGJvcmRlcmNvbG9yPSIjNjY5 OUZGIiBiZ2NvbG9yPSIjRkZGRkNDIiBjZWxscGFkZGluZz0iNSIgY2VsbHNwYWNpbmc9IjAi Pg0KICAgICAgICA8dHI+DQogICAgICAgICAgPHRkPjxkaXYgYWxpZ249ImNlbnRlciI+PGZv bnQgY29sb3I9IiMwMDMzOTkiIHNpemU9IjIiIGZhY2U9IlZlcmRhbmEsIEFyaWFsLCBIZWx2 ZXRpY2EsIHNhbnMtc2VyaWYiPjxzdHJvbmc+PGZvbnQgc2l6ZT0iMSI+TWFkZSANCiAgICAg ICAgICAgICAgZnJvbSBhbWlubyBhY2lkcyBhbmQgaGVyYnMsIG5hdHVyYWwgSEdIIGNhbiBo ZWxwIHlvdTogPC9mb250Pjwvc3Ryb25nPjwvZm9udD48L2Rpdj4NCiAgICAgICAgICAgIDx1 bD4NCiAgICAgICAgICAgICAgPGxpPjxmb250IGNvbG9yPSIjMzM2NjAwIiBzaXplPSIxIj48 c3Ryb25nPjxmb250IGZhY2U9IlZlcmRhbmEsIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2Vy aWYiPjxlbT5JbmNyZWFzZSANCiAgICAgICAgICAgICAgICBFbmVyZ3k8L2VtPjwvZm9udD48 L3N0cm9uZz48L2ZvbnQ+PC9saT4NCiAgICAgICAgICAgICAgPGxpPjxlbT48Zm9udCBjb2xv cj0iIzMzNjYwMCIgc2l6ZT0iMSI+PHN0cm9uZz48Zm9udCBmYWNlPSJWZXJkYW5hLCBBcmlh bCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIj5TdHJlbmd0aGVuIA0KICAgICAgICAgICAgICAg IEltbXVuaXR5IDwvZm9udD48L3N0cm9uZz48L2ZvbnQ+IDwvZW0+DQogICAgICAgICAgICAg IDxsaT48ZW0+PGZvbnQgY29sb3I9IiMzMzY2MDAiIHNpemU9IjEiPjxzdHJvbmc+PGZvbnQg ZmFjZT0iVmVyZGFuYSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiI+R2FpbiANCiAg ICAgICAgICAgICAgICBMZWFuIE11c2NsZSA8L2ZvbnQ+PC9zdHJvbmc+PC9mb250PiA8L2Vt Pg0KICAgICAgICAgICAgICA8bGk+PGVtPjxmb250IGNvbG9yPSIjMzM2NjAwIiBzaXplPSIx Ij48c3Ryb25nPjxmb250IGZhY2U9IlZlcmRhbmEsIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMt c2VyaWYiPkltcHJvdmUgDQogICAgICAgICAgICAgICAgU2xlZXAgUXVhbGl0eSA8L2ZvbnQ+ PC9zdHJvbmc+PC9mb250PiA8L2VtPg0KICAgICAgICAgICAgICA8bGk+PGVtPjxmb250IGNv bG9yPSIjMzM2NjAwIiBzaXplPSIxIj48c3Ryb25nPjxmb250IGZhY2U9IlZlcmRhbmEsIEFy aWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPlRyaW0gDQogICAgICAgICAgICAgICAgWW91 ciBXYWlzdGxpbmUgPC9mb250Pjwvc3Ryb25nPjwvZm9udD4gPC9lbT4NCiAgICAgICAgICAg ICAgPGxpPjxlbT48Zm9udCBjb2xvcj0iIzMzNjYwMCIgc2l6ZT0iMSI+PHN0cm9uZz48Zm9u dCBmYWNlPSJWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIj5TbW9vdGgg DQogICAgICAgICAgICAgICAgWW91ciBTa2luIDwvZm9udD48L3N0cm9uZz48L2ZvbnQ+IDwv ZW0+DQogICAgICAgICAgICAgIDxsaT48ZW0+PGZvbnQgY29sb3I9IiMzMzY2MDAiIHNpemU9 IjEiPjxzdHJvbmc+PGZvbnQgZmFjZT0iVmVyZGFuYSwgQXJpYWwsIEhlbHZldGljYSwgc2Fu cy1zZXJpZiI+U3RyZW5ndGhlbiANCiAgICAgICAgICAgICAgICBIYWlyICYgTmFpbHMgPC9m b250Pjwvc3Ryb25nPjwvZm9udD48L2VtPiANCiAgICAgICAgICAgIDwvdWw+PC90ZD4NCiAg ICAgICAgPC90cj4NCiAgICAgIDwvdGFibGU+PC90ZD4NCgk8dGQgdmFsaWduPSJ0b3AiIGFs aWduPSJjZW50ZXIiPjxwPjxmb250IHNpemU9IjEiIGZhY2U9IlZlcmRhbmEsIEFyaWFsLCBI ZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPjxzdHJvbmc+UmVhZCANCiAgICAgICAgdGhlc2UgdGVz dGltb25pYWxzOjxicj48YnI+DQogICAgICAgIDxlbT6TSSBhbSBoYXZpbmcgdGhlIG1vc3Qg aW5jcmVkaWJsZSByZXN1bHRzIHdpdGggSEdIIC4gLiAulDwvZW0+PGJyPg0KICAgICAgICA8 Zm9udCBjb2xvcj0iIzMzNjY5OSI+Qy4gQy4gKEZlbWFsZSwgNTgpPGJyPg0KICAgICAgICBE ZXMgTW9pbmVzLCBJQTwvZm9udD48YnI+DQogICAgICAgIDxicj4NCiAgICAgICAgPGVtPpNI R0ggaGFzIGdpdmVuIG1lIGVuZXJneSwgaW1wcm92ZWQgbWVtb3J5LCBlbmR1cmFuY2UuLi4g a2VwdCB3ZWlnaHQgDQogICAgICAgIG9mZiBhbmQgY29udHJvbGxlZCBteSBhcHBldGl0ZS4g SXSScyBoZWxwZWQgbWUgYSBsb3QhlCA8L2VtPjxicj4NCiAgICAgICAgPGZvbnQgY29sb3I9 IiMzMzY2OTkiPlJvYiBTbWl0aCAoTWFsZSwgMzQpPGJyPg0KICAgICAgICBOZXcgWW9yaywg Tlk8L2ZvbnQ+PGJyPg0KICAgICAgICA8YnI+DQogICAgICAgIDxlbT6TSSBoYXZlIGVuZXJn eSwgZ3JlYXQgd2VsbC1iZWluZywgSZJ2ZSBsb3N0IHdlaWdodCBhbmQgaW5jaGVzIGFuZCAN CiAgICAgICAgbXkgbXVzY2xlcyBhcmUgdG9uZWQuIFByaW9yIHRvIEhHSCwgSSBjb3VsZG6S dCBsb3NlIHdlaWdodCBub3IgZW5kdXJlIA0KICAgICAgICB3b3Jrb3V0cy4gSSBmZWVsIHdv bmRlcmZ1bCBhbGwgdGhlIHRpbWUhlDwvZW0+PGJyPg0KICAgICAgICA8Zm9udCBjb2xvcj0i IzMzNjY5OSI+TC4gUy4gKEZlbWFsZSwgNTEpPGJyPg0KICAgICAgICBXYWxkb3JmLCBNRDwv Zm9udD48L3N0cm9uZz48L2ZvbnQ+PC9wPg0KPHAgYWxpZ249ImNlbnRlciI+PGEgaHJlZj0i aHR0cDovL3d3dy5zaG9wcGluZ2FsbHRoZXdheS5jb20vaGdoL3dlbGNvbWUyLmh0bWw/YWZm aWQ9bzg4OCZlPW1wbHNAdXUubmV0Jm4wMj14ZXZmeGZvZmhpaWFlYnRidndpdXRxcnd2ZHFk cmhycW5ueGwiPjxoMz48Zm9udCBmYWNlPVZlcmRhbmE+SSB3YW50IHRvIHN0YXJ0IGZlZWwg YmV0dGVyIHRvZGF5ITwvZm9udD48L2gzPjwvYT4NCiAgICAgIDwvdGQ+DQogIDwvdHI+DQog IDx0cj48dGQgY29sc3Bhbj0iMiI+PGhyIHdpZHRoPSI5OSUiIHNpemU9IjEiPg0KDQogIDwv dGQ+PC90cj4NCjwvdGFibGU+DQo8cD48Zm9udCBmYWNlPUFyaWFsIHNpemU9MT5Zb3UgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBiZWNhdXNlIHlvdSBzaWduZWQgdXAgd2l0aCBvbmUgb2YgUm9j a2V0IE1lZGlhJ3Mgd2Vic2l0ZXMgb3IgeW91IHNpZ25lZCB1cCB3aXRoIGEgcGFydHkgdGhh dCBoYXMgY29udHJhY3RlZCB3aXRoIFJvY2tldCBNZWRpYS4gVG8gdW5zdWJzY3JpYmUNCiBm cm9tIG91ciBmdXR1cmUgbWFpbGluZywgcGxlYXNlIDxhIGhyZWY9Imh0dHA6Ly93d3cuc2hv cHBpbmdhbGx0aGV3YXkuY29tL3IvIj5jbGljayBoZXJlPC9hPg0KPGJyPkEgam9iIGFwcGxp Y2FudCBjaGFsbGVuZ2VkIHRoZSBpbnRlcnZpZXdlciB0byBhbiBhcm0gd3Jlc3RsZS4NCjwv Zm9udD4NCjwvYm9keT4NCjwvaHRtbD4NCg== From owner-mpls@UU.NET Thu Dec 12 12:34: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 MAA03508 for ; Thu, 12 Dec 2002 12:34:55 -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 QQnsyg13624 for ; Thu, 12 Dec 2002 17:37: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 QQnsyg10377; Thu, 12 Dec 2002 17:35:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsyg03512 for mpls-outgoing; Thu, 12 Dec 2002 17:35: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 QQnsyg03503 for ; Thu, 12 Dec 2002 17:34:58 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 QQnsyg21916 for ; Thu, 12 Dec 2002 17:34: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 QQnsyg15958 for ; Thu, 12 Dec 2002 17:34:24 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 QQnsyg15946 for ; Thu, 12 Dec 2002 17:34:23 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBCHYqlP013590 for ; Thu, 12 Dec 2002 12:34:53 -0500 (EST) 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 MAA29122 for ; Thu, 12 Dec 2002 12:34:21 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBCHYLV24962 for mpls@uu.net; Thu, 12 Dec 2002 12:34:21 -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 QQnsyg03385 for ; Thu, 12 Dec 2002 17:32:50 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 QQnsyg20693 for ; Thu, 12 Dec 2002 17:32: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 QQnsyg14390 for ; Thu, 12 Dec 2002 17:32:04 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 QQnsyg14346 for ; Thu, 12 Dec 2002 17:32:02 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 MAA48544; Thu, 12 Dec 2002 12:29:23 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212121729.MAA48544@workhorse.fictitious.org> To: neil.2.harrison@bt.com cc: dallan@nortelnetworks.com, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: draft-ietf-mpls-lsp-ping-01.txt - ECMP considerations In-reply-to: Your message of "Thu, 12 Dec 2002 10:08:17 GMT." <0536FC9B908BEC4597EE721BE6A35389014CFD04@i2km07-ukbr.domain1.systemhost.net> Date: Thu, 12 Dec 2002 12:29:23 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <0536FC9B908BEC4597EE721BE6A35389014CFD04@i2km07-ukbr.domain1.system host.net>, neil.2.harrison@bt.com writes: > Dave, please see below. > > regards, Neil > > > -----Original Message----- > > From: David Allan [mailto:dallan@nortelnetworks.com] > > Sent: 11 December 2002 23:44 > > To: curtis@fictitious.org > > Cc: curtis@fictitious.org; mpls@UU.NET > > Subject: RE: draft-ietf-mpls-lsp-ping-01.txt - ECMP considerations > > > > > > Curtis: > > > > I'm FAR from throwing my hands up in the air..... ;-) Just > > trying to move > > the mountain (and some thinking). > > > > If I did not make it clear, for figuring out what went wrong > > once yoou know > > somthing is wrong, > NH=> This is an important point. The discussion would have a far clearer > basis for comment/analysis if we first identified/agreed all the failure > conditions we want to detect, and the consequent actions that must be > activated on such. Discussing nuances of ECMP and the rights/wrongs of the > LSP-Ping protocol without having this clear separation of (i) detection and > (ii) diagnostics as a bsis for discussion is not very helpful IMO. > OK. I think the following summarizes the intent. MPLS-ping is intended to detect forwarding faults in an MPLS LSP and isolate the fault to the LSR at which traffic stops flowing. No attempt is made to determine that cause of the fault or diagnose problems any further. Since MPLS-ping "echo request" packets are injected no further upstream than the ingress LSR, faults at the ingress related to classifying and directing packets and encapsulating them for placement in the LSP are not detected. Since the MPLS-ping "echo request" packets are extracted no further downstream than the egress LSR, faults at the egress in decapsulating and directing traffic further are not detected. Persistent faults in transiting the LSP, regardless of their cause, can be detected and isolated to one or two LSR. The document doesn't explicitly state what I have above but it only talks about detection and isolation. For example: 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. If Kireeti adds this to the document we don't need to enumerate all possible faults before getting started. I personally think it is obvious enough that it doesn't need to be stated but it won't hurt to add it. If this doesn't satisfy you, please explain in greater detail what you would like to see discussed or in the document. Curtis From owner-mpls@UU.NET Thu Dec 12 13:50: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 NAA06897 for ; Thu, 12 Dec 2002 13:50:53 -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 QQnsyl00467 for ; Thu, 12 Dec 2002 18:53:43 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 QQnsyl22535; Thu, 12 Dec 2002 18:49:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsyl28090 for mpls-outgoing; Thu, 12 Dec 2002 18:49: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 QQnsyl28075 for ; Thu, 12 Dec 2002 18:49:06 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 QQnsyl23294 for ; Thu, 12 Dec 2002 18:48: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 QQnsyl05316 for ; Thu, 12 Dec 2002 18:48:00 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 QQnsyl05299 for ; Thu, 12 Dec 2002 18:48:00 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 gBCIlmx02576; Thu, 12 Dec 2002 13:47:48 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Dec 2002 13:47:48 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C067C2C78@zcard031.ca.nortel.com> From: "David Allan" To: Kireeti Kompella Cc: mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Thu, 12 Dec 2002 13:47:46 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Hi Kireeti: > > I have a concern with the draft. Embedded in the protocol > are a number of > > features designed to test proprietary behaviors (load > balancing). How these > > would be used IMHO is insufficiently well documented to ensure > > interoperability. On that basis I do not think the document > is ready. > > I think this has been done sufficiently to death. I'll hunt down and > read Curtis's proposed text and comment. OK > > > One specific example that come to mind is the description > of "downstream > > router". I consider to be poorly explained. > > > > Now the text: > > "a packet with outermost label L and TTL n>1 arrives at X"..... OK > > > > "X must be able to compute which LSRs could receive the > packet with TTL=n+1" > > whoa, where the packet came from? I thought TTL > decremented. I presume the > > correct text should be "what LSRs would receive the packet > if forwarded from > > X with TTL=1". > > > > "the set of LSRs are the downstream routers....for X with > respect to L", > > > > So what are we discussing here, the LSRs upstream of X, > downstream of X, the > > specific NHLFE that load balancing resolves to given the > specific details of > > the packet (src address and 127./8 and whatever else the propretary > > implementation considers) or the set that the FTN/ILM maps > to prior to any > > actual load balancing computations (is it "a" packet or > "any" packet mapping > > to the FEC associated with the LSP). > > Explained in reply to Shahram -- does that work for you? I think when Curtis is finishes his proposal, we'll have somthing I'm happy with. > > > Given the description, and the ambiguities in the text, it > is not clear to > > me what I could build and successfully interoperate with > the LSR next > > door.... > > MPLS to the kerb (curb)? You're having too much fun ;-) > > > BTW it would be useful to explicitly state in 3.2 that the > downstream > > mapping TLV is only valid in "traceroute mode", and that it > is optional in > > echo requests, and mandatory in echo replies. > > See reply to Shahram. OK > > > Other minor comments: > > > > - won't claim to be an expert, would TTL exhaust on an > internal loopback > > address generate an ICMP message back to the ping > originator (which it > > should be ignoring)? At the moment there is no mention of what the ingress should do with the extra ICMP TTL exhaust messages it will receive when running traceroute mode. > > > > - downstream mapping permits multiple labels per interface > to be described > > in an echo request, but the reply can only indicate that > "it arrived on one > > of them" rather than which specific one (which may matter). > > The "multiple" labels are a stack (see reply to Shahram). Couldn't find anything relevant, but noting it is a stack helps and explains a lot. Presumably when an LSR returning a downstream mapping TLV has knowledge to return a stack, it does so in response to what is in the FEC TLV. 3.2 would be better worded if the statement was that the length of the TLV was "12+4*N octets where N is the depth of the stack returned". The "number of downstream labels" is somewhat misleading. As an aside, it would be most useful if implicit null was how PHP appeared in the downstream mapping TLV. If you agree some text to explicitly mention this should be there. > > > IMHO it would be useful to have the sequence number > explicitly correspond to > > the LSB of the 127./8 used as I would presume otherwise the > echo request > > originating LSR would need to remember such details > associated with the > > sequence number (as the reply would not contain the > address). (I'm assuming > > that the sequence number is used uniquely with the LSP > under test, and the > > handle exists as the indexing mechanism for replies > independent of the > > specific LSP under consideration). T'would also facilitate > picking out gaps > > due to black holes in load balancing constructs esp. in > don't reply mode. > > I don't see the utility of this. The LSB of the address is in the > packet. Not in a reply, although I suppose the originating LSR could maintain associated with sequence number the actual address used. I was looking to minimize the state maintained at the origin. > > > - not clear how the example of testing stacked FECs would > work in CSC > > scenarios, perhaps an author could comment? > > You'll have to explain, starting with expanding "CSC". Carrier supporting carrier. Although traceroute with downstream mapping containing a stack would appear to address some of this. cheers Dave From owner-mpls@UU.NET Thu Dec 12 14:19:33 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 OAA08213 for ; Thu, 12 Dec 2002 14:19:33 -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 QQnsyn18098 for ; Thu, 12 Dec 2002 19:22: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 QQnsyn13651; Thu, 12 Dec 2002 19:19:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsyn19046 for mpls-outgoing; Thu, 12 Dec 2002 19:19: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 QQnsyn19031 for ; Thu, 12 Dec 2002 19:18:48 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 QQnsyn11749 for ; Thu, 12 Dec 2002 19:18: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 QQnsyn12639 for ; Thu, 12 Dec 2002 19:18:08 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 QQnsyn12632 for ; Thu, 12 Dec 2002 19:18:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBCJIbmu029888 for ; Thu, 12 Dec 2002 14:18:37 -0500 (EST) 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 OAA10991 for ; Thu, 12 Dec 2002 14:18:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBCJI5k02531 for mpls@uu.net; Thu, 12 Dec 2002 14:18: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 QQnsyn18983 for ; Thu, 12 Dec 2002 19:17:15 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 QQnsyn19449 for ; Thu, 12 Dec 2002 19:15: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 QQnsyn10827 for ; Thu, 12 Dec 2002 19:15:27 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 QQnsyn10817 for ; Thu, 12 Dec 2002 19:15:26 GMT Received: (qmail 24838 invoked by uid 104); 12 Dec 2002 19:15:20 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4237. . Clean. Processed in 1.405053 secs); 12 Dec 2002 19:15:20 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 12 Dec 2002 19:15:18 -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 gBCJFIQ22819 for ; Thu, 12 Dec 2002 11:15:18 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Thu, 12 Dec 2002 11:15:17 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B8C@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Thu, 12 Dec 2002 11:15:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi, Would the authors comment on how the MPLS-ping applies when Fast Reroute scheme exists? In other words how is the backup path and/or detour paths tested from the ingress? Thanks, -Shahram From owner-mpls@UU.NET Thu Dec 12 18:13: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 SAA17084 for ; Thu, 12 Dec 2002 18:13:50 -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 QQnsxw17322 for ; Thu, 12 Dec 2002 15:07:04 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 QQnsxw15781; Thu, 12 Dec 2002 15:06:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQnsxw11572 for mpls-outgoing; Thu, 12 Dec 2002 15:05:53 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 QQnsxw11564 for ; Thu, 12 Dec 2002 15:05: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 QQnsxw03591 for ; Thu, 12 Dec 2002 15:05:14 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 QQnsxw14689 for ; Thu, 12 Dec 2002 15:05:14 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQnsxw14685 for ; Thu, 12 Dec 2002 15:05:13 GMT Received: from cisco.com (erosen-u10.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBCF55Fp014855; Thu, 12 Dec 2002 07:05:05 -0800 (PST) Message-Id: <200212121505.gBCF55Fp014855@sj-msg-core-1.cisco.com> To: Kireeti Kompella cc: George Swallow , mpls@UU.NET Subject: Re: Last call on LSP Ping In-reply-to: Your message of Wed, 11 Dec 2002 04:31:04 -0800. <20021211042517.U19625-100000@kummer.juniper.net> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 12 Dec 2002 10:05:05 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Eric> Although this suggests that the MPLS echo request might be sent as an Eric> unlabeled UDP datagram, that doesn't actually seem possible. Kireeti> As I said in an earlier reply, what if the LSP is a one-hopper, Kireeti> with PHP? Yes, correct. I would suggest adding two clarifications to the document: - The packet is only sent unlabeled if the LSP is a one-hopper, and PHP is used. - The LSP ingress must not pass the packet though the "ordinary" forwarding procedures, else the packet will be consumed by the egress due to its 127/8 destination address. Kireeti> Say you're testing prefix 10/8 in VPN foo, and it so happens that Kireeti> you go over LSP bar. You don't really care, you create a ping Kireeti> packet with target FEC "10/8 in VPN foo", slap a label stack on it, Kireeti> and off it goes. I agree with this as far as it goes, but I think some clarification is needed with respect to the label stack that is slapped on. For testing VPN routes, you must be sure that the bottom label is not one which will cause the packet to be sent to the CE. Thus you would generally have to omit the VPN route label from the "slapped on" label stack. From owner-mpls@UU.NET Thu Dec 12 18:50:20 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 SAA17806 for ; Thu, 12 Dec 2002 18:50:20 -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 QQnszf11904 for ; Thu, 12 Dec 2002 23:53:12 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 QQnszf07288; Thu, 12 Dec 2002 23:50:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQnszf20964 for mpls-outgoing; Thu, 12 Dec 2002 23:50:03 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 QQnszf20953 for ; Thu, 12 Dec 2002 23:49: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 QQnszf25308 for ; Thu, 12 Dec 2002 23:46:01 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 QQnsyz14152 for ; Thu, 12 Dec 2002 22:26:30 GMT Received: from mail.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc250.alcatel.be [195.207.101.250]) id QQnsyz13784 for ; Thu, 12 Dec 2002 22:25:54 GMT Received: from bemail05.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id gBCMPN015662; Thu, 12 Dec 2002 23:25:23 +0100 Received: from alcatel.be ([138.203.67.224]) by bemail05.net.alcatel.be (Lotus Domino Release 5.0.9a) with ESMTP id 2002121223252073:56 ; Thu, 12 Dec 2002 23:25:20 +0100 Message-ID: <3DF90CCC.835A3C88@alcatel.be> Date: Thu, 12 Dec 2002 23:25:16 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: Optical Network Architecture (NTA - Antwerpen) X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jean Philippe Vasseur Cc: Cheng-Yin.Lee@alcatel.com, sachin laddha , mpls@UU.NET, ccamp@ops.ietf.org Subject: Re: Multi-Area TE Protocol Extensions References: <4.3.2.7.2.20021210090846.06284110@paris.cisco.com> <4.3.2.7.2.20021210123021.0382fe10@paris.cisco.com> <3DF643DF.4F8AC12C@alcatel.be> <4.3.2.7.2.20021211114607.0513d0a0@paris.cisco.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.9a |January 7, 2002) at 12/12/2002 23:25:20, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.9a |January 7, 2002) at 12/12/2002 23:25:23, Serialize complete at 12/12/2002 23:25:23 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit your impression is too affirmative wrt to my next reply (i've never said that the xro mechanisms are restricted to ma-te or that this i-d should be entirely dedicated to it) also the intention of opening a charter item implies imho structuring the content of proposals that are on the table and that may further come in, this in order to achieve common mechanisms in the scope of the ccamp wg - in whatever i-d btw as long as it reproduces the consensus of the wg (taking a look back at gmpls signalling for instance you will see that it is the concatenation of many individual submissions coming from various horizons) as said before, we have currently two methods on the table 1) constraint passing and 2) path queries, the first beneficiate from the fact it is the logical evolution from loose routing (the next step) the other uses signalling for querying a server, as such there is one fundamental question underlying the latter: moving features from distributed entities to the centralized ones for path computation purposes solves an intermediate problem (when a unique server is available) that comes back when several centralized systems have to interoperate but also one fundamental protocol aspect (which is due to the methods currently proposed) using a signalling protocol like rsvp to explicitly query a server is clearly questionable (*) - i think this should be clarified in the kompella i-d since this is independent from the fact that the server is collocated on an abr or along the lsp path - back to previous method using constraint passing i would say constraint-passing keeps the current philosophy of rsvp-te since based on the implicit assumption that each hop (in particular abr in ma-te context) are capable to respond to the incoming request; is the latter optimal, no of course; but i would say that at the end the "simplest solution to this complex problem will remain", well i think that rfc 3439 phrases this principle much better than i do; (*) understand this as a general remark people have the tendency to overload/over-generalize the features supported by a protocol and its applicability scope thanks, - dimitri. Jean Philippe Vasseur wrote: > > Hi, > > At 10:43 11/12/2002 -0500, Cheng-Yin Lee wrote: > >Dimitri, JP, > >While I think an applicability section/statement is fine, I'm not sure > >if a mechanism > >to compute inter-area TE path belong in this ID. > > This was exactly my impression. > > JP. > > >We did include applications in the first discussion of this ID and in the > >slides > >http://www.ietf.org/proceedings/02mar/slides/ccamp-6/index.html and in > >addressing > >Kireeti's suggestion to include a discussion on the impact of message > >size, we provided > >an inter-area example for illustration purposes. However, there have also > >been > >suggestions in the past to not discuss applications specifically in the > >draft itself. > >I am fine with either way. > > > >thanks > >cheng-yin > > > >Dimitri.Papadimitriou@alcatel.be wrote: > > > > > jp, > > > > > > > this ID does not propose a mechanism to compute inter-area TE path > > > > > > well i would say that either none of them does it, or all of > > > them, more accurately route exclusions are applicable to any > > > mpls network where full computation of the ero is not performed > > > before the LSP is signaled, implying thus a "scope" for computed > > > path thus among other applicable to multiple areas - nevertheless > > > i agree that a next version of this i-d should probably include > > > an applicability section covering this in a bit more details (see > > > also section 4.1 for an example - > > > > > > this said and as for any other input or i-d provided on constraint- > > > passing (as well as path query, btw) lot of work is still needed to > > > achieve a decent first step in this effort; > > > > > > thanks, > > > - dimitri. > > > > > > Jean Philippe Vasseur wrote: > > > > > > > > Hi Dimitri, > > > > > > > > cc'ing CCAMP - see in line, > > > > > > > > At 17:45 10/12/2002 +0100, Dimitri.Papadimitriou@alcatel.be wrote: > > > > >jp, > > > > > > > > > >in fact the below list should simply be as follows for > > > > >signalling-based methods: 1) constraint-passing 2) loose > > > > >routing and 3) path query; > > > > > > > > > >and the for constraint-passing we have a several i-d's > > > > >such as, > > > > > > > > > >http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclude-r > > oute-01.txt > > > > > > > > > > > > > this ID does not propose a mechanism to compute inter-area TE path > > > > > > > > >constraint passing may also be extended using the crank- > > > > >back as listed below; the usage scenarios of these methods > > > > >are described in the following: > > > > > > > > > >http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te- > > 03.txt > > > > > > > > > >now probably it is worth spending some time in considering > > > > >input coming from the tewg wrt to this effort, most of the > > > > >input that you see listed above has been produced over the > > > > >past year (and more) i can't imagine stepping in the protocol > > > > >details without a clear consensus on what do we want to cover > > > > >within the ccamp wg & w/o taking into account the tewg rec's > > > > >(probably better to discuss this on the ccamp mailing list) > > > > > > > > Fully agree with you. Hopefully multi-area TE should be soon part of the > > > > CCAMP charter. > > > > > > > > JP. > > > > > > > > >thanks, > > > > >- dimitri. > > > > > > > > > >Jean Philippe Vasseur wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > At 13:53 10/12/2002 +0530, sachin laddha wrote: > > > > > > >Hi, > > > > > > >'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as > > > > > > >"Initial requirements are given here for protocol support of the > > > > > multi-area > > > > > > >TE methods, which include needs to support > > > > > > > > > > > > > >* path-computation-server (PCS) functionality [kompella, lee, > > > > > vasseur, > > > > > > >te-qos-routing], > > > > > > >* query functionality [query, vasseur], > > > > > > >* crankback functionality [crankback], > > > > > > > > > > > > > >and, optionally, > > > > > > > > > > > > > >* TE feedback functionality [feedback], and > > > > > > >* summary-LSA functionality [summary_lsa]." > > > > > > >. > > > > > > >I want to know whether cisco/juniper routers (standard ones) > > supports > > > > > all of > > > > > > >the above extension. > > > > > > >or if not,how many.......or Whether router is supposed to > > support how many > > > > > > >... > > > > > > > > > > > > I do not think any vendor supports all the method mentioned > > above, but just > > > > > > a subset. If you are running a network, your feed-backs on your > > preferred > > > > > > method is very welcome. > > > > > > > > > > > > JP. > > > > > > > > > > > > >Regards, > > > > > > >---Sachin > > > > > > > > > >-- > > > > >Papadimitriou Dimitri > > > > >E-mail : dimitri.papadimitriou@alcatel.be > > > > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > > > >E-mail : dpapadimitriou@psg.com > > > > >Public : http://psg.com/~dpapadimitriou/ > > > > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > > > >Phone : Work: +32 3 2408491 - Home: +32 2 3434361 > > > > > > -- > > > Papadimitriou Dimitri > > > E-mail : dimitri.papadimitriou@alcatel.be > > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > > E-mail : dpapadimitriou@psg.com > > > Public : http://psg.com/~dpapadimitriou/ > > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > > Phone : Work: +32 3 2408491 - Home: +32 2 3434361 -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : Work: +32 3 2408491 - Home: +32 2 3434361 From owner-mpls@UU.NET Fri Dec 13 06:23: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 GAA20596 for ; Fri, 13 Dec 2002 06:23:55 -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 QQntaz01255 for ; Fri, 13 Dec 2002 11:26: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 QQntaz26322; Fri, 13 Dec 2002 11:23:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQntaz18851 for mpls-outgoing; Fri, 13 Dec 2002 11:23: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 QQntaz18840 for ; Fri, 13 Dec 2002 11:23: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 QQntaz10409 for ; Fri, 13 Dec 2002 11:22: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 QQntaz05106 for ; Fri, 13 Dec 2002 11:22:52 GMT Received: from tokyo.ccrle.nec.de by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tokyo.ccrle.nec.de [195.37.70.2]) id QQntaz05096 for ; Fri, 13 Dec 2002 11:22:51 GMT Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gBDBL4F19559; Fri, 13 Dec 2002 12:21:44 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 4DA14459F6; Fri, 13 Dec 2002 12:18:35 +0100 (CET) Date: Fri, 13 Dec 2002 12:18:35 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Thomas Nadeau , Adrian Farrel Cc: "Mpls (E-mail)" Subject: LSR-MIB XC table indexing Message-ID: <8621977.1039781915@[192.168.102.207]> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit At the MIB review meeting in Atlanta, we discussed the issue of indexing the XCTable. Is there a resolution now how this should work? Additionally, I tried to explain the problem again to some people here, but was not able anymore to recall what the problem really was. They ask me why we need mplsXCInSegmentIfIndex, mplsXCInSegmentLabel as index instead of mplsInSegmentIndex. The explanation might be added to the description as well. Marcus -------------------------------------- Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus From owner-mpls@UU.NET Fri Dec 13 06:45: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 GAA20922 for ; Fri, 13 Dec 2002 06:45:13 -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 QQntbb20820 for ; Fri, 13 Dec 2002 11:48: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 QQntbb18849; Fri, 13 Dec 2002 11:47:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQntbb21516 for mpls-outgoing; Fri, 13 Dec 2002 11:46:48 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 QQntbb21508 for ; Fri, 13 Dec 2002 11:46: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 QQntba22408 for ; Fri, 13 Dec 2002 11:44:11 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 QQnszl10797 for ; Fri, 13 Dec 2002 01:24:07 GMT Received: from bridge.axiowave.com by cmr1.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 QQnszl10777 for ; Fri, 13 Dec 2002 01:24:06 GMT Message-ID: From: Ling Li To: "'mpls@UU.NET'" Cc: Ling Li Subject: RE: Last Call on Fast Reroute Date: Thu, 12 Dec 2002 20:23:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk The following are my comments and questions on the draft. Your clarifications are appreciated. --Ling 1. The assumptions made in the draft: 1). From Section 7: "Therefore, an LSR which is on the path of a protected LSP SHOULD always assume that it is a merge point" 2). From Section 8: "if a DETOUR object is included in the backup LSP's path message for the sender-template-specific method, the LSRs in the traffic-engineered network should support the DETOUR object. Second, if the Path-Specific Method is to be supported for the one-to-one backup technique, it is necessary that the LSRs in the traffic-engineered network be capable of merging detours " These are very important assumptions. Could these assumptions be mentioned in the Introduction section to avoid confusion when reading the first several sections? For example, the hop-limit constraint in Section 4.1 is very confusing without assumption 1). Questions: 1. Is the following assumption implied by the draft: an LSR which is on the path of a protected LSP SHOULD always assume that it is a PLR. Without this assumption, the NHOP or NNHop bypass may not work as expected. That is because NHOP bypass can only protect a downstream neighbor link. If the downstream neighbor node is not a PLR, a failure of the remote downstream link is going to be propagated to the current node. If the current node knows that its downstream neighbor is not a PLR, it may use NNHop to protect the neighbor node and the remote downstream links. Since the current node has no way to know if the downstream neighbor is PLR, I guess it is assumed. 2. I think the following statements in Section 4.2 is not needed because of assumption 2). "LSRs that do not support the DETOUR objects MUST reject any Path message containing a DETOUR object and send a PathErr to notify the PLR." If really needed, please provide Error Code and Value. Hard to imagine anyone will upgrade their code for not supporting a feature. Some general comments: 1. in Section 6.2, "For detour LSPs, the destination MUST be the tail-end of the protected LSP". However the hop-limit constraint is "from current node (a PLR) to a MP". It is not easy to enhance cspf to support this constraint if it is defined this way. I would prefer not setting constraint to MP, but to the destination, such as what is de fined in Juniper product: "For fast reroute, how many more routers a detour is allowed to traverse compared to the LSP itself" at http://www.juniper.net/techpubs/software/junos52/swconfig52- mpls-apps/html/mpls-summary18.html#1014333. 2. The following statement is not very clear in Section 5: "If node protection is desired, the head-end LSR should set the "node protection desired" flag in the SESSION_ATTRIBUTE object; if only link protection is desired, this flag should be cleared. " Could it be changed to use Otherwise after the first half of the statement, jus as what is said for "bandwidth protection desired" flag after the statement. 3. The following statement is made is Section 6: " If the "node protection desired" flag is set, the PLR SHOULD try to provide node protection; if this is not feasible, the PLR SHOULD then try to provide link protection." Can we say the same for "bandwidth protection desired" flag? " If the "bandwidth protection desired" flag is set, the PLR SHOULD try to provide bandwidth protection; if this is not feasible, the PLR SHOULD set the bandwidth constraint to 0 then try to provide protection." > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Tuesday, December 03, 2002 5:50 PM > To: mpls@UU.NET > Subject: Last Call on Fast Reroute > > > This message begins a workgroup last call on: > > Fast Reroute Extensions to RSVP-TE for LSP Tunnels > > draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt > > The last call ends on Dec 16, 2002 2400H GMT. > > George & Loa > > ====================================================================== > George Swallow Cisco Systems (978) 497-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > > > From owner-mpls@UU.NET Fri Dec 13 06:47: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 GAA20948 for ; Fri, 13 Dec 2002 06:47:02 -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 QQntbb22683 for ; Fri, 13 Dec 2002 11:49: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 QQntbb16968; Fri, 13 Dec 2002 11:46:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQntbb21229 for mpls-outgoing; Fri, 13 Dec 2002 11:45:48 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 QQntbb21224 for ; Fri, 13 Dec 2002 11:45:38 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 QQntbb25057 for ; Fri, 13 Dec 2002 11:45: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 QQntbb17633 for ; Fri, 13 Dec 2002 11:45:09 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 QQntbb17626 for ; Fri, 13 Dec 2002 11:45:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBDBjbQ2025506 for ; Fri, 13 Dec 2002 06:45:37 -0500 (EST) 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 GAA07974 for ; Fri, 13 Dec 2002 06:45:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBDBj5x20106 for mpls@uu.net; Fri, 13 Dec 2002 06:45: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 QQntba20827 for ; Fri, 13 Dec 2002 11:43:58 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 QQntba26506 for ; Fri, 13 Dec 2002 11:41: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 QQnsyr03856 for ; Thu, 12 Dec 2002 20:23:19 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 QQnsyr03839 for ; Thu, 12 Dec 2002 20:23:19 GMT Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBCKL10A018858; Thu, 12 Dec 2002 21:21:02 +0100 (MET) Received: from JVASSEUR-W2K.cisco.com (sjc-vpn3-480.cisco.com [10.21.65.224]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id VAA24601; Thu, 12 Dec 2002 21:22:18 +0100 (MET) Message-Id: <4.3.2.7.2.20021211114607.0513d0a0@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 12 Dec 2002 15:22:14 -0500 To: Cheng-Yin.Lee@alcatel.com From: Jean Philippe Vasseur Subject: Re: Multi-Area TE Protocol Extensions Cc: Dimitri.Papadimitriou@alcatel.be, "sachin laddha" , mpls@UU.NET, ccamp@ops.ietf.org In-Reply-To: <3DF75D2D.4BE2F8BF@alcatel.com> References: <4.3.2.7.2.20021210090846.06284110@paris.cisco.com> <4.3.2.7.2.20021210123021.0382fe10@paris.cisco.com> <3DF643DF.4F8AC12C@alcatel.be> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, At 10:43 11/12/2002 -0500, Cheng-Yin Lee wrote: >Dimitri, JP, >While I think an applicability section/statement is fine, I'm not sure >if a mechanism >to compute inter-area TE path belong in this ID. This was exactly my impression. JP. >We did include applications in the first discussion of this ID and in the >slides >http://www.ietf.org/proceedings/02mar/slides/ccamp-6/index.html and in >addressing >Kireeti's suggestion to include a discussion on the impact of message >size, we provided >an inter-area example for illustration purposes. However, there have also >been >suggestions in the past to not discuss applications specifically in the >draft itself. >I am fine with either way. > >thanks >cheng-yin > >Dimitri.Papadimitriou@alcatel.be wrote: > > > jp, > > > > > this ID does not propose a mechanism to compute inter-area TE path > > > > well i would say that either none of them does it, or all of > > them, more accurately route exclusions are applicable to any > > mpls network where full computation of the ero is not performed > > before the LSP is signaled, implying thus a "scope" for computed > > path thus among other applicable to multiple areas - nevertheless > > i agree that a next version of this i-d should probably include > > an applicability section covering this in a bit more details (see > > also section 4.1 for an example - > > > > this said and as for any other input or i-d provided on constraint- > > passing (as well as path query, btw) lot of work is still needed to > > achieve a decent first step in this effort; > > > > thanks, > > - dimitri. > > > > Jean Philippe Vasseur wrote: > > > > > > Hi Dimitri, > > > > > > cc'ing CCAMP - see in line, > > > > > > At 17:45 10/12/2002 +0100, Dimitri.Papadimitriou@alcatel.be wrote: > > > >jp, > > > > > > > >in fact the below list should simply be as follows for > > > >signalling-based methods: 1) constraint-passing 2) loose > > > >routing and 3) path query; > > > > > > > >and the for constraint-passing we have a several i-d's > > > >such as, > > > > > > > >http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclude-r > oute-01.txt > > > > > > > > > > this ID does not propose a mechanism to compute inter-area TE path > > > > > > >constraint passing may also be extended using the crank- > > > >back as listed below; the usage scenarios of these methods > > > >are described in the following: > > > > > > > >http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te- > 03.txt > > > > > > > >now probably it is worth spending some time in considering > > > >input coming from the tewg wrt to this effort, most of the > > > >input that you see listed above has been produced over the > > > >past year (and more) i can't imagine stepping in the protocol > > > >details without a clear consensus on what do we want to cover > > > >within the ccamp wg & w/o taking into account the tewg rec's > > > >(probably better to discuss this on the ccamp mailing list) > > > > > > Fully agree with you. Hopefully multi-area TE should be soon part of the > > > CCAMP charter. > > > > > > JP. > > > > > > >thanks, > > > >- dimitri. > > > > > > > >Jean Philippe Vasseur wrote: > > > > > > > > > > Hi, > > > > > > > > > > At 13:53 10/12/2002 +0530, sachin laddha wrote: > > > > > >Hi, > > > > > >'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as > > > > > >"Initial requirements are given here for protocol support of the > > > > multi-area > > > > > >TE methods, which include needs to support > > > > > > > > > > > >* path-computation-server (PCS) functionality [kompella, lee, > > > > vasseur, > > > > > >te-qos-routing], > > > > > >* query functionality [query, vasseur], > > > > > >* crankback functionality [crankback], > > > > > > > > > > > >and, optionally, > > > > > > > > > > > >* TE feedback functionality [feedback], and > > > > > >* summary-LSA functionality [summary_lsa]." > > > > > >. > > > > > >I want to know whether cisco/juniper routers (standard ones) > supports > > > > all of > > > > > >the above extension. > > > > > >or if not,how many.......or Whether router is supposed to > support how many > > > > > >... > > > > > > > > > > I do not think any vendor supports all the method mentioned > above, but just > > > > > a subset. If you are running a network, your feed-backs on your > preferred > > > > > method is very welcome. > > > > > > > > > > JP. > > > > > > > > > > >Regards, > > > > > >---Sachin > > > > > > > >-- > > > >Papadimitriou Dimitri > > > >E-mail : dimitri.papadimitriou@alcatel.be > > > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > > >E-mail : dpapadimitriou@psg.com > > > >Public : http://psg.com/~dpapadimitriou/ > > > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > > >Phone : Work: +32 3 2408491 - Home: +32 2 3434361 > > > > -- > > Papadimitriou Dimitri > > E-mail : dimitri.papadimitriou@alcatel.be > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > E-mail : dpapadimitriou@psg.com > > Public : http://psg.com/~dpapadimitriou/ > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > Phone : Work: +32 3 2408491 - Home: +32 2 3434361 From owner-mpls@UU.NET Fri Dec 13 08:50: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 IAA23127 for ; Fri, 13 Dec 2002 08:50:11 -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 QQntbj17278 for ; Fri, 13 Dec 2002 13:53:01 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 QQntbj14697; Fri, 13 Dec 2002 13:51:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQntbj10528 for mpls-outgoing; Fri, 13 Dec 2002 13:51: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 QQntbj10507 for ; Fri, 13 Dec 2002 13:51:15 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 QQntbj28937 for ; Fri, 13 Dec 2002 13:50:00 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 QQntbj13587 for ; Fri, 13 Dec 2002 13:50:00 GMT Received: from ihemail2.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQntbj13580 for ; Fri, 13 Dec 2002 13:49:59 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 gBDDnwA20292 for ; Fri, 13 Dec 2002 08:49:58 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Dec 2002 14:49:57 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550488@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Thomas D. Nadeau" Cc: "Mpls (E-mail)" Subject: RE: review of draft-ietf-mpls-te-mib-09.txt Date: Fri, 13 Dec 2002 14:49:54 +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 Inline > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: maandag 9 december 2002 17:33 > To: Wijnen, Bert (Bert) > Cc: Mpls (E-mail) > Subject: Re: review of draft-ietf-mpls-te-mib-09.txt > > >Seems that a lot of earlier comments I had made to the authors > >half a year or so ago, have not been addressed. Oh well. > >Here we go (mix of nits, and more serious things) > > > >- missing IPR section > >- Security considerations probably needs more work > > Security ADs want you to explain what the vulnerabilities/risks > > are and what to do against them. > > Also for read only objects, pls list each (group of) object(s) > > and explain what sensitivity attributes they have > >- RowStatus and STorageType objects need better text as per my comments > > to the other MIB modules. > > Well, it is not from lack of trying. In many cases, > I would ask that you make suggestions as to what > exact text you would like to see. In particular, things like > the examples and security sections have been updated > to what we thought addressed your comments. For this > and the other MIBs you have returned comments on > you have stated that they are not up to snuff. Please > instead of going back and forth 50 times on this via > email, please just propose some text as you have > done in other DESCRIPTION clause fixes, which will > greatly speed things along. > OK, so here we go. I thought I had passed this on before. First, I'd like to see an answer to the following piece of text that is in every StorageType TC. What does this mean? " If this variable is set to readOnly(5), and the corresponding entry is removed, then the agent must remove this row shortly thereafter [RFC2579]." What does that mean? What is the "corresponding entry"? That is this row, is it not? Anyway, let us look at how the STorageType TC is defined (RFC2579): StorageType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Describes the memory realization of a conceptual row. A row which is volatile(2) is lost upon reboot. A row which is either nonVolatile(3), permanent(4) or readOnly(5), is backed up by stable storage. A row which is permanent(4) can be changed but not deleted. A row which is readOnly(5) cannot be changed nor deleted. If the value of an object with this syntax is either permanent(4) or readOnly(5), it cannot be written. Conversely, if the value is either other(1), volatile(2) or nonVolatile(3), it cannot be modified to be permanent(4) or readOnly(5). (All illegal modifications result in a 'wrongValue' error.) Every usage of this textual convention is required to specify the columnar objects which a permanent(4) row must at a minimum allow to be writable." SYNTAX INTEGER { other(1), -- eh? volatile(2), -- e.g., in RAM nonVolatile(3), -- e.g., in NVRAM permanent(4), -- e.g., partially in ROM readOnly(5) -- e.g., completely in ROM } It says that a row which is either nonVolatile(3), permanent(4) or readOnly(5), is backed up by stable storage. That means that after a reboot (or restart of SNMP agent) such a row should re-appear. If for other reasons such a row needs to go away (for example since the LSP is removed via some LDP protocol mechanism), then the row of course can and should be removed. If the row is readOnly, the SNMP SET command cannot change or delete the row. So not SET command for that row succeeds. To me it means that there is no need to say anything about readOnly storageType in your descrition clauses, or there must be something special that I do not understand. Now, if the row is permanent, then you cannot delete it (via SNMP SET). But the row can be changed. That is if such is wanted/needed. Since some people may interpret "permanent" as "cannot be changed", the last para tells you that a DESCRIPTION clause (for an object with syntax of StoraggeType) MUST (is required to) specify which columns must be writable for such a permanent row. If you do not "require" any write access, then a simple DESCRIPTION clause for all your StorageType objects could be: DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." RFC2574 has example of STorageType where some (special) columns DO need to be writable, even for permanent rows. Hope this helps. For the RowStatus, Good examples are again in for example rfc3289 DESCRIPTION "The status of this conceptual row. All writable objects in this row may be modified at any time." But then I see that in many cases you do NOT allow changes while the row is active, so then it could be something aka: DESCRIPTION "The status of this conceptual row. None of the writable objects in this row may be modified when this row is 'active'." Or if some can and some otehrs cannot, then for example something like DESCRIPTION "The status of this conceptual row. Writable objects a and b in this row may be modified at any time, but other wrietable objects in this row may not be modified when this row is 'active'." Now, be carefull, because when objects are not allowed to be modified when the row is 'active', and when you specify (in MODULE COMPLIANCE) that one only has to support createAndGo for the WRITE-SYNTAX, then people cannot (in such an implementation) set the row to notInService, and so that then means that changes to the row can only be made by deleting (destroy) and recreating the rows. Does this help? > >- References need to be split in normative and informative > > I thought Arun did this. Which ones do you think > are not? > Comon Tom, this is easy to find, and I did mention it for each doc. But here is the summary, these docs do not have them split: draft-ietf-mpls-tc-mib-05.txt draft-ietf-mpls-ftn-mib-05.txt draft-ietf-mpls-lsr-mib-09.txt draft-ietf-mpls-te-mib-09.txt these are OK w.r.t. reference split draft-ietf-mpls-ldp-mib-09.txt draft-ietf-mpls-mgmt-overview-02.txt draft-ietf-mpls-bundle-mib-04.txt Although the SNMP references are not split properly, see my other emails about how to split those. > >- mplsXxxxNext, see my comments in my review of other mpls > MIB modules > > Will use the description in the FTN MIB. > Well, note that - I had pointed out some conflicts in the description clauses in those objects and TCs in that MIB - I had suggested to use a common approach (similar as in diffserv MIB module (rfc3289). So that means taking the TCs out into the mpls TC MIB and using the same TC in all objects of that type. Hope I was clear on that. If not, let me know and I can propose exact text and TCs to be specified and used. > >- last bullet sect 4 talks about (non-)persistent tunnels. > > as does the DESCRIPTION clause of mplsTunnelGroup... > > but I don't get a good picture of what makes a persistent > > or a non-persistent tunnel and what the MIB offers for that. > >- section 9, the example > > includes mplsTunnelOwner... but it claims that those things > > are to be part of a SET request. But... in the MIB module I see > > the mplsTunnelOwner is read-only, so it cannot be part > > of a SET > > Right. Need to clarify. The owner is gleaned from > who creates the entry, as is described in the TC. > Well.. try to be very clear. When you say that you are listing objects as they would be passed in a SET request, then it seems incorrect to specify any read-only objects. Also... you have the index (indices) included too. I udnerstand you want to do that... maybe you want to mark them with an asterisk or such and then explain they are index/indices and so that they are not separate varBinds in the SET PDU but that they make up the index part of each object in the varBinds in the SET PDU. Or some such. > >- section 9 example > > inlcudes mplsTunnelResourcePointer and syas that it should > > be SET to mplsTunnelResourceIndex.5 > > I think that should be mplsResourceMaxRate.5 because that > > is the first accessible columnar object in a row that table > > Yes. > > >- section 10, > > first sentence > > s/to one of its objetcs/to the first accesible object in a row/ > > last sentence > > s/to the first column/to the first accessible column/ > >- I wonder if mplsTunnelConfigured would be better named > > mplsTunnelsConfigured and mplsTunnelActive better be named > > mplsTunnelsActive > >- I ownder if mplsTunnelNotiMaxRate would be better named > > mplsTunnelNotiInterval > > May want to add a UNITS clause to this object anyway > > and why is it not named mplsTunnerNotificationInterval? > > Looks like a typo. > > >- mplsTunnelIndexNext > > well, same comment as to all the mplsXxxNext objects in the > > other MIB modules. > > But this one has even another strange thing, namely it is > > a Interger32 (as opposed to a Unsigned32) and it has a pretty > > limited range and for all I can tell for no good reason. > > In fact I see no reason for a upper limit. > > It is supposed to match the indexing of the tunnel table. > > >- mplsTunnelEntry > > Why is there a reference to RFC1700 ??? That RFC has been > > obsoleted anyway... > >- Can someone explain to me why you use the complex indexing > > scheme for the mplsTunnelTable, namely: > > INDEX { > > mplsTunnelIndexIndex, > > mplsTunnelInstance, > > mplsTunnelIngressLSRId, > > mplsTunnelEgressLSRId > > } > > > > - first, I do not understand why it the 1st one is named > > mplsTunnelIndexIndex instead of just mplsTunnelIndex > > Compiler complained because the type is MplsTunnelIndex. > > > - 2nd, mplsTunnelIndexIndex claims to "uniquely" identify a row > > so then no more index objects seem needed > > - but mplsTunnelInstance seems to also "uniquely" identify a row?? > > - and then there are yet more index objects. > > - mplsTunnelIngresLSRId, description talks about "this value". > > but the index object does not really have a value. It is part > > of the OID that identifies instances in the table. > > Why do I not understand this indexing scheme? > > We went over this during the MIB meeting. This is basically > just the RSVP-TE indexing required. > > > I think it would be good to include in the DESCRIPTION clause of > > either the mplsTunnleEntry or of the indices a very good > explanation > > as to how the indexing works here. > > Yes. We agreed to improve the description as an action > from the MIB meeting. > OK, looking forward to that, hopefully I then understand. Is it just me who does not understand? I doubt it in fact. > >- I have trouble with the use of DisplaySTring (as mentioned > half a year > > ago). These days we want people to use UTF8 based strings > if the strings > > are intended for human use. So either SnmpAdminString or > some other > > UTF8-based string. Several TCs have been defined to > replace DisplayString > > Yes, will use SnmpAdminString. > > >- I wonder why the mplsTunnelName is ever to be equal to ifName. > > The link between an entry in the mplsTunnelTable and the > ifTable is > > made by the mplsIfTunnelIndex which is the better way > indeed to make > > the link. > > The idea is that in cases where the tunnel is an ifEntry too, > this makes sense so they are associated. > And so when people do SET on ifName or on mplsTunnelName, then the agent needs to make sure they stay in sync? What if in one SET request (I will admit it is kind of stupid) one send a SET for ifName of "abcd" and a SET for mplsTunnelName of "efgh" I see all sorts of potential problems with this. And is it the MIB who wants to presrcibe this? I know thay ifName was meant for operators to use. So you are forcing them to use same name for mplsTunnel, why can they not use ifName : Interface1 for MPLS mplsTunnelName : mpls Tunnel to Linschoten (this is where I live ;-)) Oh well... I won't loose sleep over it.... I just wonder about the complexities it may cause (for in mu view no good reason) > >- It seems to me that mplsIfTunnelDescription could have a DEFVAL > > of the empty (zero lenght) string > >- It seems to me that mplsTunnelIsIf and mplsTunnelIfIndex > are overlapping. > > A value of zero in the mplsTunnelIfIndex means that this > tunnel does > > not correspond to an interface. A nonzero value means that it does > > correspond to an interface. So why is mplsTunnelIsIf > needed? So that > > people can have conflicting stuff that needs to be > chacked and all that? > > The idea is that you can quickly determine the type of > tunnel. I suppose that we could eliminate this object and just > state that if ifIndex = 0 that it is NOT an ifIndex. > Having 2 objects to represnt kind of the same thing always adds complexity in terms of "what to do when they conflict" or "how to make sure they stay in sync". Is it just me who sees these type of concerns? > >- mplsTunnelSessionAttributes > > you may want to check the formatting in the DESCRIPTION clause > >- mplsTunnelOwner is a read-only object and yet the > description clause > > talks about that it cannot be modified when RowStatus is active. > > That seems redundant text. A read-only object can NEVER be changed > > Again, this should be the same as that in the TC that we > discussed (the agent sets this value). > Right... but pls remove the piece of text that says that it cannot be changed when row is active, because that piece if nonsense and confusing. > >- I see mplsTunnelHopTableIndex to be read-create while > > mplsTunnelARHopTableIndex and mplsTunnelCHopTableIndex > are read-only > > Is that not strange? > > Nope. The actual route hop table is what is spit out > by the CSPF computation; not operator programmable. > Got you. Maybe say something about how it gets filled in, and then people (like myself) might not need to wonder as much Not everyone is an MPLS expert on all these things (think about the (generic) apps developers we talked about in Atlanta. They want to quickly understand it too. > >- I do not understand mplsTunnelPrimaryInstance, but that is > probably linked > > to me not understanding the indexing scheme. > >- mplsTunnelPathChanges > > s/paths has changed/path has changed/ or > > s/path has changed/paths have changed/ ?? > >- mplsTunnelTotalUptime > > so is this an aggregate value of multiple entries in this table? > > This is the up time of all LSP instances of the tunnel. > That is not a clear answer to my question My interpreation of your answer is that the answer is: YES > > and if so of how many? Is that of all entries with the same > > mplsTunnelIndexIndex, or what? > > Yes, the same group of tunnel instances (the same primary > tunnel index). > First of all, it would be good to make that very clear in the DESCRIPTION clauses. One can kind of conclude that, but it is a very strange thing to see in a MIB table, so make it clear that it is intentional. But it seems BAD to me. > > And then... if there are 4 entries aggregated, do all 4 entries then > > have the same value? > > And what is the upTime of each entry? > > mplsTunnelPrimaryTimeUp shows the time of the primary > instance that this tunnel > > mplsTunnelTotalUpTime is the aggregate time of all > instances of this tunnel (head). > > mplsTunnelInstanceUpTime is the time this instance has > been up. > So you are again not answering my first question: do all 4 entries have the same value? And if so that looks BAD to me. But maybe it is just me. Any other opinions? > > I am confused here as to what the purpose of this object > is and how > > it is computed. Under what circumstances would it "not be > available"? > > It might not be available if no instances exist for > the tunnel. I suppose it might be simpler to just remove this > text, but the thinking was that we specified an initial value > for when no tunnel instances (other than 0) existed. > Or add the explanation as to when the condition can occur. In general, whenever a independent (that is someone who was not involved in the devlopment of the protocol and/or the MIB) reviewer has a question in the form of "how does that work?" or "Do I understand this and that (in)correctly?", then that often indicates that it is a good idea to add explanatory text in some of the DESCRIPTION clauses. So that not every new reader needs to go to the mailing lists to ask the same questions > >- mplsTunnelHopListIndexNext > > well, same comment as to all the mplsXxxNext objects in the > > other MIB modules. > > But this one has even another strange thing, namely it is > > a Interger32 (as opposed to a Unsigned32) and it has a pretty > > limited range and for all I can tell for no good reason. > > In fact I see no reason for a upper limit. > >- mplsTunnelHopTable. > > again I do not (from the DESCRIPTION clauses) understand > the indexing > > scheme. It seems to have two "seconday" indices. Should > that be a secondary > > and a tertiary? Must be me, since I am not an mpls expert ;-) > >- I assume that the mplsTunnelHopAddrType and related > objects get replaced > > with a common new TC as discussed at the MPLS MIB meeting > in Atlanta > > Yes. > > >- mplsTunnelHopType > > this sort of ENUMERATION seems to occur a few times, so > that it seems to > > me that you want to create a TC for it. > > Okay. > > >- mplsTunnelHopPathOptionName should be UTF8 based and not > DisplayString > > SnmpAdminString okay? > Yep. > >- mplsTunnelResourceIndexNext > > well, same comment as to all the mplsXxxNext objects in the > > other MIB modules. > > But this one has even another strange thing, namely it is > > a Interger32 (as opposed to a Unsigned32) and it has a pretty > > limited range and for all I can tell for no good reason. > > In fact I see no reason for a upper limit. > >- mplsTunnelResourceMaxRate and mplsTunnelResourceMeanRate > > could use a UNITS clause > > And... you say it is bits per second, while the > MplsBitRate TC claims > > that it is Kbps... oh well > >- mplsTunnelResourceMaxRate and mplsTunnelResourceMeanRate > > I don't think I udnerstand what the OID copying is all about and > > how an agent determines what to do? Or is it the > management station > > who does this? > > The text you are referring to is: > > This object is copied to an instance of > mplsTrafficParamMaxRate in mplsTrafficParamTable > the OID of which is copied into the corresponding > mplsInSegmentTrafficParamPtr. > > this refers to the fact the values should be copied down > to those see in the LSR MIB's resource table. This is now > moot, as we are removing the LSR MIB's table. I will > remove the aforementioned text. In fact, this text appears > all over the place in the resource table, so I will fix. > OK, thanks > >- mplsTunnelResourceFrequency OBJECT-TYPE > > SYNTAX INTEGER { > > unspecified(1), > > frequent(2), > > veryFrequent(3) > > I see another occurence in another table. So a good > candidate for a TC > > But I also wonder what "frequent" and "veryFrequent" means? > > To me they seem very very vague terms, no? > > I believe this comes from CR-LDP and does not apply > for RSVP-TE (you would use unspecified). See the reference > of CR-LDP Specification, Section 4.3 for more details. I > would actually prefer to ditch this and the other CR-LDP > tables to make things simpler... > Either ditch it, or add some of the above explanation to the DESCRIPTION clause. And if we keep multiple occurences, as I said, those are primary candidates for a TC > >- mplsTunnelResourceWeight OBJECT-TYPE > > SYNTAX Unsigned32(0..255) > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "The relative weight for using excess bandwidth above > > its committed rate. The value of 0 means that > > weight is not applicable for the CR-LSP." > > I see this multiple times. Good candidate for a TC > > I only see it twice. Can we skip this? > You can... but that is what TCs are for, namely descrinbing once what is used in multiple (more than 1) places. Since it occures only twice and in same MIB module, I can live with it, if you find it too much trouble and if no-one else cares. > >- mplsTunnelARHopAddrType and related objects > > I assume this will be replaced by new TCs as discussed in atlanta > >- mplsTunnelCHopAddrType and related objects > > I assume this will be replaced by new TCs as discussed in atlanta > >- I would suggest to just do counter 64 instead of both 64 and 32 > > for objects like > > mplsTunnelPerfPackets Counter32, > > mplsTunnelPerfHCPackets Counter64, > > mplsTunnelPerfBytes Counter32, > > mplsTunnelPerfHCBytes Counter64 > > In general we also speak about octets instead of bytes, but I can > > live with bytes. > >- I wonder if mplsTunnelCRLDPResFlags would not be better represented > > with a BITS construct instead of an INTEGER enumeration > > We have been over this several times. The representation is > based on what is found in the CR-LDP protocol. The WG preferred > to leave the value this way, so I would prefer to leave it (unless > we can ditch all of the CR-LDP related stuff). > That is a WG question > >- MODULE COMPLIANCE > > Maybe a Full and a ReadOnly compliance? > > Will add. > > > See also my comment to other mpls MIB modules. It links to the > > SYNTAX and WRITE-SYNTAX of some of the objects as well, > specifically > > the RowStatus objects > >- Pls see also my note in other MIB Module comments about the > > 'other' for StirageType objetcs. It seems really weird to have > > that in the compliance. > >- It is not good to give a group of objects a name that indicates > > optionality. A gorup is just a group. If it is optional or > > manadatory, that should become clear in the MODULE COMPLIANCE > > statement, but not in the name (and/or description > clause) of the group > > Okay. > > > Some future MODULE COMPLIANCE may want to make that group > mandatory. > > An OBJECT GROUP is a "logical grouping" of objects. The > requirement > > for mandatory of conditional or optional implementation is to be > > specified in the MODULE-COMPLIANCE. > >- I do not understand why there is both mplsTunnelIsIntfcGroup and a > > mplsTunnelIsNotIntfcGroup? > > Because some objects make sense only for when the > tunnel entry is implemented as an ifIndex. > It seems I am not clear. This is what you have in your MIB module: mplsTunnelIsIntfcGroup OBJECT-GROUP OBJECTS { mplsTunnelIsIf } STATUS current DESCRIPTION "Objects needed to implement tunnels that are interfaces." ::= { mplsTeGroups 5 } mplsTunnelIsNotIntfcGroup OBJECT-GROUP OBJECTS { mplsTunnelIsIf } STATUS current DESCRIPTION "Objects needed to implement tunnels that are not interfaces." ::= { mplsTeGroups 6 } They are EXACTLY the same set of (one single) object. That to me means there is only ONE group and not TWO. You then go on in the MODULE-COMPLIANCE to state (in a DESCRITION clause) that in some cases the value is true or false. You can write that in the single DESCRIPTION clause in the MODULE-COMPLIANCE anyway, So again, it completely escapes me why you think you need two groups with the same content. > >One seems sufficient to me. > > This is moot if we just remove the IsIf object from the > tunnelEntry. > That is true too, but I'd like you to read the above and try to understand why I think my viepoint makes sense and what is unb the rev 9 of the document does not. > > And why not spell out Intfc as Interface? > > Brevity? *) We actually wanted to be consistent with > the rest of the MIB, which I think uses "if". > Well, then be consistent, Either that or spell it out, But... this is a real NIT and I won't loose sleep over it. Bert > --Tom > > > >Thanks, > >Bert > > From owner-mpls@UU.NET Fri Dec 13 09:16:42 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 JAA23941 for ; Fri, 13 Dec 2002 09:16:41 -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 QQntbl09261 for ; Fri, 13 Dec 2002 14:19:32 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 QQntbl02791; Fri, 13 Dec 2002 14:15:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQntbl01417 for mpls-outgoing; Fri, 13 Dec 2002 14:15: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 QQntbl01412 for ; Fri, 13 Dec 2002 14:15:18 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 QQntbk23218 for ; Fri, 13 Dec 2002 14:13: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 QQntbk01004 for ; Fri, 13 Dec 2002 14:13:12 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 QQntbk00949 for ; Fri, 13 Dec 2002 14:13:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBDEDauH008088 for ; Fri, 13 Dec 2002 09:13:37 -0500 (EST) 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 JAA14472 for ; Fri, 13 Dec 2002 09:13:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBDED5g00683 for mpls@uu.net; Fri, 13 Dec 2002 09:13:05 -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 QQntbk00974 for ; Fri, 13 Dec 2002 14:12: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 QQntbk22670 for ; Fri, 13 Dec 2002 14:11:19 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 QQnszw20258 for ; Fri, 13 Dec 2002 04:14:18 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 QQnszw20245 for ; Fri, 13 Dec 2002 04:14:17 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 XAA50433; Thu, 12 Dec 2002 23:14:02 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212130414.XAA50433@workhorse.fictitious.org> To: Shahram Davari cc: mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Thu, 12 Dec 2002 11:15:06 PST." <4B6D09F3B826D411A67300D0B706EFDEB03B8C@nt-exch-yow.pmc-sierra.bc.ca> Date: Thu, 12 Dec 2002 23:14:02 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4B6D09F3B826D411A67300D0B706EFDEB03B8C@nt-exch-yow.pmc-sierra.bc.ca >, Shahram Davari writes: > Hi, > > Would the authors comment on how the MPLS-ping applies when > Fast Reroute scheme exists? In other words how is the backup path > and/or detour paths tested from the ingress? > > Thanks, > -Shahram In ping mode you should not know that the backup is in use. Perhaps an error return in traceroute mode would be helpful or an indication that the next hop is part of a detour. Keep in mind that once the detour is put into use it is usually a matter of seconds before a new primary is created with its own set of detours, none of which are in use. Curtis From owner-mpls@UU.NET Fri Dec 13 09:22:03 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 JAA24112 for ; Fri, 13 Dec 2002 09:22:02 -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 QQntbl16026 for ; Fri, 13 Dec 2002 14:24: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 QQntbl12309; Fri, 13 Dec 2002 14:22:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQntbl02333 for mpls-outgoing; Fri, 13 Dec 2002 14:22:02 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 QQntbl02279 for ; Fri, 13 Dec 2002 14:21:55 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 QQntbl29198 for ; Fri, 13 Dec 2002 14:21: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 QQntbl12074 for ; Fri, 13 Dec 2002 14:21:14 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 QQntbl12058 for ; Fri, 13 Dec 2002 14:21:14 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBDELhA6009307 for ; Fri, 13 Dec 2002 09:21:44 -0500 (EST) 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 JAA14994 for ; Fri, 13 Dec 2002 09:21:12 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBDELC101618 for mpls@uu.net; Fri, 13 Dec 2002 09:21:12 -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 QQntbl01861 for ; Fri, 13 Dec 2002 14:19:54 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 QQntbl28928 for ; Fri, 13 Dec 2002 14:17: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 QQntbl00760 for ; Fri, 13 Dec 2002 14:17:00 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 QQntbl00751 for ; Fri, 13 Dec 2002 14:16:59 GMT Received: (qmail 29489 invoked by uid 104); 13 Dec 2002 14:16:58 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 (uvscan: v4.1.40/v4237. Clear:. Processed in 0.444967 secs); 13 Dec 2002 14:16:58 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 13 Dec 2002 14:16: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 gBDEGvQ17525; Fri, 13 Dec 2002 06:16:57 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Fri, 13 Dec 2002 06:16:57 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B90@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'curtis@fictitious.org'" Cc: mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Fri, 13 Dec 2002 06:16:55 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Curtis, I was more thinking in terms of how to make sure the backup/detour paths are working fine, while the traffic is still on the working path. Yours, -Shahram > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: Thursday, December 12, 2002 11:14 PM > To: Shahram Davari > Cc: mpls@UU.NET > Subject: Re: Last call on LSP Ping > > > > In message > <4B6D09F3B826D411A67300D0B706EFDEB03B8C@nt-exch-yow.pmc-sierra.bc.ca > >, Shahram Davari writes: > > Hi, > > > > Would the authors comment on how the MPLS-ping applies when > > Fast Reroute scheme exists? In other words how is the backup path > > and/or detour paths tested from the ingress? > > > > Thanks, > > -Shahram > > > In ping mode you should not know that the backup is in use. > > Perhaps an error return in traceroute mode would be helpful or an > indication that the next hop is part of a detour. > > Keep in mind that once the detour is put into use it is usually a > matter of seconds before a new primary is created with its own set of > detours, none of which are in use. > > Curtis > From owner-mpls@UU.NET Fri Dec 13 09:54:35 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 JAA24727 for ; Fri, 13 Dec 2002 09:54:35 -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 QQntbn12952 for ; Fri, 13 Dec 2002 14:57: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 QQntbn09545; Fri, 13 Dec 2002 14:55:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQntbn06168 for mpls-outgoing; Fri, 13 Dec 2002 14:55:03 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 QQntbn06163 for ; Fri, 13 Dec 2002 14:55:01 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 QQntbn02406 for ; Fri, 13 Dec 2002 14:54:10 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 QQntbn06721 for ; Fri, 13 Dec 2002 14:54:09 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 QQntbn06715 for ; Fri, 13 Dec 2002 14:54:09 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBDEsccD014171 for ; Fri, 13 Dec 2002 09:54:39 -0500 (EST) 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 JAA17074 for ; Fri, 13 Dec 2002 09:54:07 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBDEs7G07713 for mpls@uu.net; Fri, 13 Dec 2002 09:54:07 -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 QQntbn05998 for ; Fri, 13 Dec 2002 14:52:51 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 QQntbn11660 for ; Fri, 13 Dec 2002 14:52:30 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 QQntbn05876 for ; Fri, 13 Dec 2002 14:52:29 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 QQntbn05870 for ; Fri, 13 Dec 2002 14:52:29 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 gBDEqe2O013901; Fri, 13 Dec 2002 09:52:41 -0500 (EST) Received: from tnadeau-w2k.cisco.com (rtp-vpn1-838.cisco.com [10.82.227.70]) by bucket.cisco.com (Mirapoint) with ESMTP id ACG62026; Fri, 13 Dec 2002 09:52:08 -0500 (EST) Message-Id: <5.2.0.9.2.20021213094319.094389b0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 13 Dec 2002 09:52:04 -0500 To: Shahram Davari From: "Thomas D. Nadeau" Subject: RE: Last call on LSP Ping Cc: "'curtis@fictitious.org'" , mpls@UU.NET In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03B90@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 It does seem plausible that RSVP-TE could signal backup tunnels that could black hole traffic on the data plane once switched on. It is possible to do this at least in the facility- based FRR mode, since a TE tunnel is signaled a priori (perhaps many of them), so one could go and test each to verify their health to make sure that they are really protecting once turned on. --Tom >I was more thinking in terms of how to make sure the backup/detour >paths are working fine, while the traffic is still on the working path. > > >Yours, >-Shahram > > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > Sent: Thursday, December 12, 2002 11:14 PM > > To: Shahram Davari > > Cc: mpls@UU.NET > > Subject: Re: Last call on LSP Ping > > > > > > > > In message > > <4B6D09F3B826D411A67300D0B706EFDEB03B8C@nt-exch-yow.pmc-sierra.bc.ca > > >, Shahram Davari writes: > > > Hi, > > > > > > Would the authors comment on how the MPLS-ping applies when > > > Fast Reroute scheme exists? In other words how is the backup path > > > and/or detour paths tested from the ingress? > > > > > > Thanks, > > > -Shahram > > > > > > In ping mode you should not know that the backup is in use. > > > > Perhaps an error return in traceroute mode would be helpful or an > > indication that the next hop is part of a detour. > > > > Keep in mind that once the detour is put into use it is usually a > > matter of seconds before a new primary is created with its own set of > > detours, none of which are in use. > > > > Curtis > > "The difficult, we do immediately. The impossible takes a little longer." -- Air Force Motto From owner-mpls@UU.NET Fri Dec 13 10:25: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 KAA25569 for ; Fri, 13 Dec 2002 10:25:19 -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 QQntbp04227 for ; Fri, 13 Dec 2002 15:28: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 QQntbp26383; Fri, 13 Dec 2002 15:23:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQntbp27583 for mpls-outgoing; Fri, 13 Dec 2002 15:22:44 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 QQntbp27576 for ; Fri, 13 Dec 2002 15:22:39 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 QQntbp03840 for ; Fri, 13 Dec 2002 15:22:09 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 QQntbp25722 for ; Fri, 13 Dec 2002 15:22:08 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 QQntbp25706 for ; Fri, 13 Dec 2002 15:22:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBDFMbrS018621 for ; Fri, 13 Dec 2002 10:22:37 -0500 (EST) 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 KAA19429 for ; Fri, 13 Dec 2002 10:22:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBDFM6G11379 for mpls@uu.net; Fri, 13 Dec 2002 10:22:06 -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 QQntbp27429 for ; Fri, 13 Dec 2002 15:20:54 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 QQntbp23108 for ; Fri, 13 Dec 2002 15:18: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 QQntbp23383 for ; Fri, 13 Dec 2002 15:18:41 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 QQntbp23375 for ; Fri, 13 Dec 2002 15:18: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 gBDFJ8Ft018071; Fri, 13 Dec 2002 10:19:09 -0500 (EST) Received: from tnadeau-w2k.cisco.com (rtp-vpn1-838.cisco.com [10.82.227.70]) by bucket.cisco.com (Mirapoint) with ESMTP id ACG62656; Fri, 13 Dec 2002 10:18:35 -0500 (EST) Message-Id: <5.2.0.9.2.20021213095501.0945bc40@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 13 Dec 2002 10:18:31 -0500 To: "Wijnen, Bert (Bert)" From: "Thomas D. Nadeau" Subject: RE: review of draft-ietf-mpls-te-mib-09.txt Cc: "Mpls (E-mail)" In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550488@nl0006exch001u.nl.luc ent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 02:49 PM 12/13/2002 +0100, Wijnen, Bert (Bert) wrote: >Inline > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: maandag 9 december 2002 17:33 > > To: Wijnen, Bert (Bert) > > Cc: Mpls (E-mail) > > Subject: Re: review of draft-ietf-mpls-te-mib-09.txt > > > > >Seems that a lot of earlier comments I had made to the authors > > >half a year or so ago, have not been addressed. Oh well. > > >Here we go (mix of nits, and more serious things) > > > > > >- missing IPR section > > >- Security considerations probably needs more work > > > Security ADs want you to explain what the vulnerabilities/risks > > > are and what to do against them. > > > Also for read only objects, pls list each (group of) object(s) > > > and explain what sensitivity attributes they have > > >- RowStatus and STorageType objects need better text as per my comments > > > to the other MIB modules. > > > > Well, it is not from lack of trying. In many cases, > > I would ask that you make suggestions as to what > > exact text you would like to see. In particular, things like > > the examples and security sections have been updated > > to what we thought addressed your comments. For this > > and the other MIBs you have returned comments on > > you have stated that they are not up to snuff. Please > > instead of going back and forth 50 times on this via > > email, please just propose some text as you have > > done in other DESCRIPTION clause fixes, which will > > greatly speed things along. > > >OK, so here we go. I thought I had passed this on before. >First, I'd like to see an answer to the following piece of text >that is in every StorageType TC. What does this mean? > " If this variable > is set to readOnly(5), and the corresponding entry > is removed, then the agent must remove this row > shortly thereafter [RFC2579]." >What does that mean? >What is the "corresponding entry"? That is this row, is it not? > >Anyway, let us look at how the STorageType TC is defined (RFC2579): > > StorageType ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "Describes the memory realization of a conceptual row. A > row which is volatile(2) is lost upon reboot. A row which > is either nonVolatile(3), permanent(4) or readOnly(5), is > backed up by stable storage. A row which is permanent(4) > can be changed but not deleted. A row which is readOnly(5) > cannot be changed nor deleted. > > If the value of an object with this syntax is either > permanent(4) or readOnly(5), it cannot be written. > Conversely, if the value is either other(1), volatile(2) or > nonVolatile(3), it cannot be modified to be permanent(4) or > readOnly(5). (All illegal modifications result in a > 'wrongValue' error.) > > Every usage of this textual convention is required to > specify the columnar objects which a permanent(4) row must > at a minimum allow to be writable." > SYNTAX INTEGER { > other(1), -- eh? > volatile(2), -- e.g., in RAM > nonVolatile(3), -- e.g., in NVRAM > permanent(4), -- e.g., partially in ROM > readOnly(5) -- e.g., completely in ROM > } > >It says that a row which is either nonVolatile(3), permanent(4) >or readOnly(5), is backed up by stable storage. >That means that after a reboot (or restart of SNMP agent) such a row >should re-appear. If for other reasons such a row needs to go away >(for example since the LSP is removed via some LDP protocol mechanism), >then the row of course can and should be removed. > >If the row is readOnly, the SNMP SET command cannot change or delete >the row. So not SET command for that row succeeds. > >To me it means that there is no need to say anything about readOnly >storageType in your descrition clauses, or there must be something >special that I do not understand. I would agree. >Now, if the row is permanent, then you cannot delete it (via SNMP SET). >But the row can be changed. That is if such is wanted/needed. Since >some people may interpret "permanent" as "cannot be changed", the >last para tells you that a DESCRIPTION clause (for an object with syntax >of StoraggeType) MUST (is required to) specify which columns must be >writable for such a permanent row. >If you do not "require" any write access, then a simple DESCRIPTION >clause for all your StorageType objects could be: > > DESCRIPTION > "The storage type for this conceptual row. Conceptual rows > having the value 'permanent' need not allow write-access to any > columnar objects in the row." I think that since we do have a read-write conformance mode for tunnelEntries, that we need to include some text on when the row is writable. >RFC2574 has example of STorageType where some (special) columns DO >need to be writable, even for permanent rows. I will look at that reference. >Hope this helps. > >For the RowStatus, Good examples are again in for example rfc3289 > DESCRIPTION > "The status of this conceptual row. All writable objects in this > row may be modified at any time." >But then I see that in many cases you do NOT allow changes while the >row is active, so then it could be something aka: > > DESCRIPTION > "The status of this conceptual row. None of the writable objects > in this row may be modified when this row is 'active'." > >Or if some can and some otehrs cannot, then for example something like > DESCRIPTION > "The status of this conceptual row. Writable objects a and b > in this row may be modified at any time, but other wrietable > objects in this row may not be modified when this row is 'active'." > >Now, be carefull, because when objects are not allowed to be modified when >the row is 'active', and when you specify (in MODULE COMPLIANCE) that >one only has to support createAndGo for the WRITE-SYNTAX, then people >cannot (in such an implementation) set the row to notInService, and >so that then means that changes to the row can only be made by >deleting (destroy) and recreating the rows. > >Does this help? Yes. I think that any object in the row may be modified (if the implementation supports it) only once the row is taken out of service. This may require TE parameters to be re-signaled priori to the tunnelEntry returning to the operational state; however. Is something that describes that reasonable? > > >- References need to be split in normative and informative > > > > I thought Arun did this. Which ones do you think > > are not? > > >Comon Tom, this is easy to find, and I did mention it for each doc. >But here is the summary, these docs do not have them split: > > draft-ietf-mpls-tc-mib-05.txt > draft-ietf-mpls-ftn-mib-05.txt > draft-ietf-mpls-lsr-mib-09.txt > draft-ietf-mpls-te-mib-09.txt > >these are OK w.r.t. reference split > > draft-ietf-mpls-ldp-mib-09.txt > draft-ietf-mpls-mgmt-overview-02.txt > draft-ietf-mpls-bundle-mib-04.txt >Although the SNMP references are not split properly, see my other >emails about how to split those. Okay. One more round on the references I guess. > > >- mplsXxxxNext, see my comments in my review of other mpls > > MIB modules > > > > Will use the description in the FTN MIB. > > >Well, note that >- I had pointed out some conflicts in the description clauses in > those objects and TCs in that MIB >- I had suggested to use a common approach (similar as in diffserv > MIB module (rfc3289). So that means taking the TCs out > into the mpls TC MIB and using the same TC in all objects of > that type. Yes. >Hope I was clear on that. If not, let me know and I can propose >exact text and TCs to be specified and used. In general, I would appreciate it if you would propose wherever you can. I think that way we can get to satisfying your comments more quickly. > > >- last bullet sect 4 talks about (non-)persistent tunnels. > > > as does the DESCRIPTION clause of mplsTunnelGroup... > > > but I don't get a good picture of what makes a persistent > > > or a non-persistent tunnel and what the MIB offers for that. > > >- section 9, the example > > > includes mplsTunnelOwner... but it claims that those things > > > are to be part of a SET request. But... in the MIB module I see > > > the mplsTunnelOwner is read-only, so it cannot be part > > > of a SET > > > > Right. Need to clarify. The owner is gleaned from > > who creates the entry, as is described in the TC. > > >Well.. try to be very clear. When you say that you are listing objects >as they would be passed in a SET request, then it seems incorrect >to specify any read-only objects. Okay. >Also... you have the index (indices) included too. I udnerstand you >want to do that... maybe you want to mark them with an asterisk or such >and then explain they are index/indices and so that they are not >separate varBinds in the SET PDU but that they make up the >index part of each object in the varBinds in the SET PDU. >Or some such. Isn't it implied that the indexes are required as part of the SET PDU when doing createAndGo style row creation? I think it is pretty common knowledge that by not sending down the indexes (and other required objects as stated in DESCRIPTION) that the creation will fail. I didn't realize that we needed to be specific on this (which seems redundant). > > >- section 9 example > > > inlcudes mplsTunnelResourcePointer and syas that it should > > > be SET to mplsTunnelResourceIndex.5 > > > I think that should be mplsResourceMaxRate.5 because that > > > is the first accessible columnar object in a row that table > > > > Yes. > > > > >- section 10, > > > first sentence > > > s/to one of its objetcs/to the first accesible object in a row/ > > > last sentence > > > s/to the first column/to the first accessible column/ > > >- I wonder if mplsTunnelConfigured would be better named > > > mplsTunnelsConfigured and mplsTunnelActive better be named > > > mplsTunnelsActive > > >- I ownder if mplsTunnelNotiMaxRate would be better named > > > mplsTunnelNotiInterval > > > May want to add a UNITS clause to this object anyway > > > and why is it not named mplsTunnerNotificationInterval? > > > > Looks like a typo. > > > > >- mplsTunnelIndexNext > > > well, same comment as to all the mplsXxxNext objects in the > > > other MIB modules. > > > But this one has even another strange thing, namely it is > > > a Interger32 (as opposed to a Unsigned32) and it has a pretty > > > limited range and for all I can tell for no good reason. > > > In fact I see no reason for a upper limit. > > > > It is supposed to match the indexing of the tunnel table. > > > > >- mplsTunnelEntry > > > Why is there a reference to RFC1700 ??? That RFC has been > > > obsoleted anyway... > > >- Can someone explain to me why you use the complex indexing > > > scheme for the mplsTunnelTable, namely: > > > INDEX { > > > mplsTunnelIndexIndex, > > > mplsTunnelInstance, > > > mplsTunnelIngressLSRId, > > > mplsTunnelEgressLSRId > > > } > > > > > > - first, I do not understand why it the 1st one is named > > > mplsTunnelIndexIndex instead of just mplsTunnelIndex > > > > Compiler complained because the type is MplsTunnelIndex. > > > > > - 2nd, mplsTunnelIndexIndex claims to "uniquely" identify a row > > > so then no more index objects seem needed > > > - but mplsTunnelInstance seems to also "uniquely" identify a row?? > > > - and then there are yet more index objects. > > > - mplsTunnelIngresLSRId, description talks about "this value". > > > but the index object does not really have a value. It is part > > > of the OID that identifies instances in the table. > > > Why do I not understand this indexing scheme? > > > > We went over this during the MIB meeting. This is basically > > just the RSVP-TE indexing required. > > > > > I think it would be good to include in the DESCRIPTION clause of > > > either the mplsTunnleEntry or of the indices a very good > > explanation > > > as to how the indexing works here. > > > > Yes. We agreed to improve the description as an action > > from the MIB meeting. > > >OK, looking forward to that, hopefully I then understand. >Is it just me who does not understand? I doubt it in fact. No, the indexes have fairly thin descriptions right now and can be improved. > > >- I have trouble with the use of DisplaySTring (as mentioned > > half a year > > > ago). These days we want people to use UTF8 based strings > > if the strings > > > are intended for human use. So either SnmpAdminString or > > some other > > > UTF8-based string. Several TCs have been defined to > > replace DisplayString > > > > Yes, will use SnmpAdminString. > > > > >- I wonder why the mplsTunnelName is ever to be equal to ifName. > > > The link between an entry in the mplsTunnelTable and the > > ifTable is > > > made by the mplsIfTunnelIndex which is the better way > > indeed to make > > > the link. > > > > The idea is that in cases where the tunnel is an ifEntry too, > > this makes sense so they are associated. > > > >And so when people do SET on ifName or on mplsTunnelName, then >the agent needs to make sure they stay in sync? >What if in one SET request (I will admit it is kind of stupid) one >send a SET for ifName of "abcd" and a SET for mplsTunnelName of "efgh" >I see all sorts of potential problems with this. >And is it the MIB who wants to presrcibe this? >I know thay ifName was meant for operators to use. So you are forcing >them to use same name for mplsTunnel, why can they not use > > ifName : Interface1 for MPLS > mplsTunnelName : mpls Tunnel to Linschoten (this is where I live ;-)) > >Oh well... I won't loose sleep over it.... I just wonder about >the complexities it may cause (for in mu view no good reason) I think it is common practice in the implementations I know of to keep these the same. The reason being that the ifType is for an mplsTunnel, so the entities are really one in the same (just the tunnel entry extends the ifIndex a bit). I think that it is a reasonable requirement that the agent SHOULD keep these values consistent. If it cannot, then let it be, but I think we should indicate that the best practice is to do so. > > >- It seems to me that mplsIfTunnelDescription could have a DEFVAL > > > of the empty (zero lenght) string > > >- It seems to me that mplsTunnelIsIf and mplsTunnelIfIndex > > are overlapping. > > > A value of zero in the mplsTunnelIfIndex means that this > > tunnel does > > > not correspond to an interface. A nonzero value means that it does > > > correspond to an interface. So why is mplsTunnelIsIf > > needed? So that > > > people can have conflicting stuff that needs to be > > chacked and all that? > > > > The idea is that you can quickly determine the type of > > tunnel. I suppose that we could eliminate this object and just > > state that if ifIndex = 0 that it is NOT an ifIndex. > > >Having 2 objects to represnt kind of the same thing always >adds complexity in terms of "what to do when they conflict" >or "how to make sure they stay in sync". >Is it just me who sees these type of concerns? I obviously agree that redundant objects should be removed. However, after working on this document for 3 years it is hard to see things like this sometimes. *) In any event, I think this was a comment made during the MIB review meeting, and I believe we agreed to remove the object. > > >- mplsTunnelSessionAttributes > > > you may want to check the formatting in the DESCRIPTION clause > > >- mplsTunnelOwner is a read-only object and yet the > > description clause > > > talks about that it cannot be modified when RowStatus is active. > > > That seems redundant text. A read-only object can NEVER be changed > > > > Again, this should be the same as that in the TC that we > > discussed (the agent sets this value). > > >Right... but pls remove the piece of text that says that it cannot >be changed when row is active, because that piece if nonsense and >confusing. Gotcha. > > >- I see mplsTunnelHopTableIndex to be read-create while > > > mplsTunnelARHopTableIndex and mplsTunnelCHopTableIndex > > are read-only > > > Is that not strange? > > > > Nope. The actual route hop table is what is spit out > > by the CSPF computation; not operator programmable. > > >Got you. Maybe say something about how it gets filled in, >and then people (like myself) might not need to wonder as much >Not everyone is an MPLS expert on all these things (think about >the (generic) apps developers we talked about in Atlanta. They >want to quickly understand it too. Okay, I will try to improve. > > >- I do not understand mplsTunnelPrimaryInstance, but that is > > probably linked > > > to me not understanding the indexing scheme. > > >- mplsTunnelPathChanges > > > s/paths has changed/path has changed/ or > > > s/path has changed/paths have changed/ ?? > > >- mplsTunnelTotalUptime > > > so is this an aggregate value of multiple entries in this table? > > > > This is the up time of all LSP instances of the tunnel. > > >That is not a clear answer to my question >My interpreation of your answer is that the answer is: YES Is this more clear: This is the uptime of all instances of the tunnel since its creation? Perhaps an example might help. If the tunnel head creates an LSP at time T and it runs until T+n. At time T+n+2 a new LSP is signaled and lasts until T+n+5. This object would then be counted as (T+n) + ((T+n+5) - (T+n+2)). > > > and if so of how many? Is that of all entries with the same > > > mplsTunnelIndexIndex, or what? > > > > Yes, the same group of tunnel instances (the same primary > > tunnel index). > > >First of all, it would be good to make that very clear in the >DESCRIPTION clauses. One can kind of conclude that, but it is >a very strange thing to see in a MIB table, so make it clear >that it is intentional. > >But it seems BAD to me. Why? During the meeting we had concluded that this was not a bad idea -- that it was pretty nice in fact. The only suggestion that came out of the meeting was that we make the indexing style/interpretation mandatory so that there was no confusion about grouping of tunnel heads with their instances. > > > And then... if there are 4 entries aggregated, do all 4 entries then > > > have the same value? > > > And what is the upTime of each entry? > > > > mplsTunnelPrimaryTimeUp shows the time of the primary > > instance that this tunnel > > > > mplsTunnelTotalUpTime is the aggregate time of all > > instances of this tunnel (head). > > > > mplsTunnelInstanceUpTime is the time this instance has > > been up. > > >So you are again not answering my first question: do all 4 >entries have the same value? And if so that looks BAD to me. >But maybe it is just me. Any other opinions? They have the same value on the tunnelEntry with instance = 0 (i.e.: the tunnel head). On other instances of the tunnel, primaryTimeUp/TotalUpTime might be set to that of the head entry (if possible). TunnelInstanceUpTime will be different if more than one LSP has been used for the tunnel head. If no instances exist, only the head does, and so those variables will only exist on the head entry. > > > I am confused here as to what the purpose of this object > > is and how > > > it is computed. Under what circumstances would it "not be > > available"? > > > > It might not be available if no instances exist for > > the tunnel. I suppose it might be simpler to just remove this > > text, but the thinking was that we specified an initial value > > for when no tunnel instances (other than 0) existed. > > >Or add the explanation as to when the condition can occur. >In general, whenever a independent (that is someone who was >not involved in the devlopment of the protocol and/or the MIB) >reviewer has a question in the form of "how does that work?" or >"Do I understand this and that (in)correctly?", then that often >indicates that it is a good idea to add explanatory text in >some of the DESCRIPTION clauses. So that not every new reader >needs to go to the mailing lists to ask the same questions Agreed. On the other hand, it is also a requirement in my mind that independents as you call them, read the protocol specifications to understand what they are going to manage using the MIBs. I agree with you in this case, but in general, I think that people using the MIBs should be up to speed with how the protocol works so that when the MIB refers to a term like "tunnel head" that the MIB not need to define its meaning. The MIB should not be a tutorial on how the protocol works that it is managing. --Tom > > >- mplsTunnelHopListIndexNext > > > well, same comment as to all the mplsXxxNext objects in the > > > other MIB modules. > > > But this one has even another strange thing, namely it is > > > a Interger32 (as opposed to a Unsigned32) and it has a pretty > > > limited range and for all I can tell for no good reason. > > > In fact I see no reason for a upper limit. > > >- mplsTunnelHopTable. > > > again I do not (from the DESCRIPTION clauses) understand > > the indexing > > > scheme. It seems to have two "seconday" indices. Should > > that be a secondary > > > and a tertiary? Must be me, since I am not an mpls expert ;-) > > >- I assume that the mplsTunnelHopAddrType and related > > objects get replaced > > > with a common new TC as discussed at the MPLS MIB meeting > > in Atlanta > > > > Yes. > > > > >- mplsTunnelHopType > > > this sort of ENUMERATION seems to occur a few times, so > > that it seems to > > > me that you want to create a TC for it. > > > > Okay. > > > > >- mplsTunnelHopPathOptionName should be UTF8 based and not > > DisplayString > > > > SnmpAdminString okay? > > >Yep. > > > >- mplsTunnelResourceIndexNext > > > well, same comment as to all the mplsXxxNext objects in the > > > other MIB modules. > > > But this one has even another strange thing, namely it is > > > a Interger32 (as opposed to a Unsigned32) and it has a pretty > > > limited range and for all I can tell for no good reason. > > > In fact I see no reason for a upper limit. > > >- mplsTunnelResourceMaxRate and mplsTunnelResourceMeanRate > > > could use a UNITS clause > > > And... you say it is bits per second, while the > > MplsBitRate TC claims > > > that it is Kbps... oh well > > >- mplsTunnelResourceMaxRate and mplsTunnelResourceMeanRate > > > I don't think I udnerstand what the OID copying is all about and > > > how an agent determines what to do? Or is it the > > management station > > > who does this? > > > > The text you are referring to is: > > > > This object is copied to an instance of > > mplsTrafficParamMaxRate in mplsTrafficParamTable > > the OID of which is copied into the corresponding > > mplsInSegmentTrafficParamPtr. > > > > this refers to the fact the values should be copied down > > to those see in the LSR MIB's resource table. This is now > > moot, as we are removing the LSR MIB's table. I will > > remove the aforementioned text. In fact, this text appears > > all over the place in the resource table, so I will fix. > > >OK, thanks > > > >- mplsTunnelResourceFrequency OBJECT-TYPE > > > SYNTAX INTEGER { > > > unspecified(1), > > > frequent(2), > > > veryFrequent(3) > > > I see another occurence in another table. So a good > > candidate for a TC > > > But I also wonder what "frequent" and "veryFrequent" means? > > > To me they seem very very vague terms, no? > > > > I believe this comes from CR-LDP and does not apply > > for RSVP-TE (you would use unspecified). See the reference > > of CR-LDP Specification, Section 4.3 for more details. I > > would actually prefer to ditch this and the other CR-LDP > > tables to make things simpler... > > >Either ditch it, or add some of the above explanation to the >DESCRIPTION clause. And if we keep multiple occurences, as I >said, those are primary candidates for a TC > > > >- mplsTunnelResourceWeight OBJECT-TYPE > > > SYNTAX Unsigned32(0..255) > > > MAX-ACCESS read-create > > > STATUS current > > > DESCRIPTION > > > "The relative weight for using excess bandwidth above > > > its committed rate. The value of 0 means that > > > weight is not applicable for the CR-LSP." > > > I see this multiple times. Good candidate for a TC > > > > I only see it twice. Can we skip this? > > >You can... but that is what TCs are for, namely descrinbing once >what is used in multiple (more than 1) places. > >Since it occures only twice and in same MIB module, I can >live with it, if you find it too much trouble and if no-one else >cares. > > > >- mplsTunnelARHopAddrType and related objects > > > I assume this will be replaced by new TCs as discussed in atlanta > > >- mplsTunnelCHopAddrType and related objects > > > I assume this will be replaced by new TCs as discussed in atlanta > > >- I would suggest to just do counter 64 instead of both 64 and 32 > > > for objects like > > > mplsTunnelPerfPackets Counter32, > > > mplsTunnelPerfHCPackets Counter64, > > > mplsTunnelPerfBytes Counter32, > > > mplsTunnelPerfHCBytes Counter64 > > > In general we also speak about octets instead of bytes, but I can > > > live with bytes. > > >- I wonder if mplsTunnelCRLDPResFlags would not be better represented > > > with a BITS construct instead of an INTEGER enumeration > > > > We have been over this several times. The representation is > > based on what is found in the CR-LDP protocol. The WG preferred > > to leave the value this way, so I would prefer to leave it (unless > > we can ditch all of the CR-LDP related stuff). > > >That is a WG question > > > >- MODULE COMPLIANCE > > > Maybe a Full and a ReadOnly compliance? > > > > Will add. > > > > > See also my comment to other mpls MIB modules. It links to the > > > SYNTAX and WRITE-SYNTAX of some of the objects as well, > > specifically > > > the RowStatus objects > > >- Pls see also my note in other MIB Module comments about the > > > 'other' for StirageType objetcs. It seems really weird to have > > > that in the compliance. > > >- It is not good to give a group of objects a name that indicates > > > optionality. A gorup is just a group. If it is optional or > > > manadatory, that should become clear in the MODULE COMPLIANCE > > > statement, but not in the name (and/or description > > clause) of the group > > > > Okay. > > > > > Some future MODULE COMPLIANCE may want to make that group > > mandatory. > > > An OBJECT GROUP is a "logical grouping" of objects. The > > requirement > > > for mandatory of conditional or optional implementation is to be > > > specified in the MODULE-COMPLIANCE. > > >- I do not understand why there is both mplsTunnelIsIntfcGroup and a > > > mplsTunnelIsNotIntfcGroup? > > > > Because some objects make sense only for when the > > tunnel entry is implemented as an ifIndex. > > >It seems I am not clear. This is what you have in your MIB module: > > mplsTunnelIsIntfcGroup OBJECT-GROUP > OBJECTS { mplsTunnelIsIf } > STATUS current > DESCRIPTION > "Objects needed to implement tunnels that are > interfaces." > ::= { mplsTeGroups 5 } > > mplsTunnelIsNotIntfcGroup OBJECT-GROUP > OBJECTS { mplsTunnelIsIf } > STATUS current > DESCRIPTION > "Objects needed to implement tunnels that are not > interfaces." > ::= { mplsTeGroups 6 } > >They are EXACTLY the same set of (one single) object. >That to me means there is only ONE group and not TWO. >You then go on in the MODULE-COMPLIANCE to state (in a DESCRITION >clause) that in some cases the value is true or false. >You can write that in the single DESCRIPTION clause in the >MODULE-COMPLIANCE anyway, > >So again, it completely escapes me why you think you need >two groups with the same content. > > > >One seems sufficient to me. > > > > This is moot if we just remove the IsIf object from the > > tunnelEntry. > > >That is true too, but I'd like you to read the above >and try to understand why I think my viepoint makes sense and >what is unb the rev 9 of the document does not. > > > > And why not spell out Intfc as Interface? > > > > Brevity? *) We actually wanted to be consistent with > > the rest of the MIB, which I think uses "if". > > >Well, then be consistent, Either that or spell it out, >But... this is a real NIT and I won't loose sleep over it. > >Bert > > --Tom > > > > > > >Thanks, > > >Bert > > > > "The difficult, we do immediately. The impossible takes a little longer." -- Air Force Motto From owner-mpls@UU.NET Fri Dec 13 10:46:04 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 KAA26407 for ; Fri, 13 Dec 2002 10:46:03 -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 QQntbr20607 for ; Fri, 13 Dec 2002 15:48:52 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 QQntbr16670; Fri, 13 Dec 2002 15:46:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQntbr29584 for mpls-outgoing; Fri, 13 Dec 2002 15:46: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 QQntbr29579 for ; Fri, 13 Dec 2002 15:46: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 QQntbr15466 for ; Fri, 13 Dec 2002 15:45: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 QQntbr15472 for ; Fri, 13 Dec 2002 15:45: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 QQntbr15463 for ; Fri, 13 Dec 2002 15:45:06 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBDFja5u022061 for ; Fri, 13 Dec 2002 10:45:36 -0500 (EST) 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 KAA21424 for ; Fri, 13 Dec 2002 10:45:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBDFj5314876 for mpls@uu.net; Fri, 13 Dec 2002 10:45:05 -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 QQntbq29121 for ; Fri, 13 Dec 2002 15:43: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 QQntbq07652 for ; Fri, 13 Dec 2002 15:43: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 QQntbq14328 for ; Fri, 13 Dec 2002 15:43:38 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 QQntbq14319 for ; Fri, 13 Dec 2002 15:43:38 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 gBDFhuCO021760; Fri, 13 Dec 2002 10:43:56 -0500 (EST) Received: from tnadeau-w2k.cisco.com (rtp-vpn1-838.cisco.com [10.82.227.70]) by bucket.cisco.com (Mirapoint) with ESMTP id ACG63218; Fri, 13 Dec 2002 10:43:23 -0500 (EST) Message-Id: <5.2.0.9.2.20021213102437.094102a8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 13 Dec 2002 10:43:17 -0500 To: brunner@ccrle.nec.de From: "Thomas D. Nadeau" Subject: Re: LSR-MIB XC table indexing Cc: Adrian Farrel , "Mpls (E-mail)" In-Reply-To: <8621977.1039781915@[192.168.102.207]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk : >At the MIB review meeting in Atlanta, we discussed the issue of indexing >the XCTable. Is there a resolution now how this should work? The solution agreed to is as follows using the MPLS LSR-MIB's mplsInSegmentTable: (ifIndex, labelCategory, OctetString(24 bytes)) labelCategory { mpls, gmplsSonet, gmplsTDM } To use the pair, you first check the type which tells you what type of label to expect. If the labelCategory is set to mpls, then the mplsInSegmentTopLabel object is queried for the 20 bit MPLS label. If the labelCategory is something else, you need to query the gmplsInSegmentLabelTable (GMPLS LSR MIB), which looks like: gmplsInSegmentLabelTable INDEX ( labelPrimaryIndex (OctetString (24 bytes)), labelPartIndex (Unsigned32)) This table has one object that is an OctetString that contains the actual label value (or the piece of the label if it spans more than one Octet String). The first index gets you to the group of octet strings used to represent the long label, and the second gets you to the specific "chunk" of the label. I propose that we let the "chunk" index of 0 specify that only 1 "chunk" exists, so that the NMS need not look further for the label's value. The agreement was to replace any instance where an MPLS label appeared in any of the MIBs to include the (type, octet string) pair and to have the gmpls label table extensions used to extend places where it was necessary to represent those labels in GMPLS. >Additionally, I tried to explain the problem again to some people here, >but was not able anymore to recall what the problem really was. The problem was many fold: 1) Use of (ifIndex, label (32 bits)) is not sufficient to index GMPLS labels which are (in theory) unlimited in length. 2) Overloading the label to say that if the top bits were set to indicate that the label was really a GMPLS label table index was unacceptable. 3) Use of the 32 bit label value to index (easily at least) all of the many applications of MPLS on a box that supported all current applications did not work. >They ask me why we need mplsXCInSegmentIfIndex, mplsXCInSegmentLabel as >index instead of mplsInSegmentIndex. The explanation might be added to the >description as well. I think that the explanation of what the fields are and how they are used belongs in the MIB, but the details of why we chose what we did over say any other approach belongs in meeting minutes. --Tom >Marcus > >-------------------------------------- >Marcus Brunner >Network Laboratories >NEC Europe Ltd. > >E-Mail: brunner@ccrle.nec.de >WWW: http://www.ccrle.nec.de/ >Phone: +49 (0) 6221 905 11 29 >personal home page: http://www.brubers.org/marcus > "The difficult, we do immediately. The impossible takes a little longer." -- Air Force Motto From owner-mpls@UU.NET Fri Dec 13 11:26: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 LAA27326 for ; Fri, 13 Dec 2002 11:26: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 QQntbt01714 for ; Fri, 13 Dec 2002 16:29:13 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 QQntbt26342; Fri, 13 Dec 2002 16:25:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQntbt21469 for mpls-outgoing; Fri, 13 Dec 2002 16:25: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 QQntbt21430 for ; Fri, 13 Dec 2002 16:24:57 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 QQntbt04393 for ; Fri, 13 Dec 2002 16:24:13 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 QQntbt25249 for ; Fri, 13 Dec 2002 16:24:13 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 QQntbt25170 for ; Fri, 13 Dec 2002 16:24:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBDGObro028890 for ; Fri, 13 Dec 2002 11:24:37 -0500 (EST) 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 LAA24849 for ; Fri, 13 Dec 2002 11:24:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBDGO5j17996 for mpls@uu.net; Fri, 13 Dec 2002 11:24: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 QQntbt21283 for ; Fri, 13 Dec 2002 16:22:20 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 QQntbt24908 for ; Fri, 13 Dec 2002 16:21:11 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 QQntbt14966 for ; Fri, 13 Dec 2002 16:21:10 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 QQntbt14959 for ; Fri, 13 Dec 2002 16:21:10 GMT Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBDGIbnl027926; Fri, 13 Dec 2002 17:18:37 +0100 (MET) Received: from JVASSEUR-W2K.cisco.com (sjc-vpn2-388.cisco.com [10.21.113.132]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA16936; Fri, 13 Dec 2002 17:19:53 +0100 (MET) Message-Id: <4.3.2.7.2.20021212173514.03e31e98@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 13 Dec 2002 11:19:36 -0500 To: Dimitri.Papadimitriou@alcatel.be From: Jean Philippe Vasseur Subject: Re: Multi-Area TE Protocol Extensions Cc: Cheng-Yin.Lee@alcatel.com, sachin laddha , mpls@UU.NET, ccamp@ops.ietf.org In-Reply-To: <3DF90CCC.835A3C88@alcatel.be> References: <4.3.2.7.2.20021210090846.06284110@paris.cisco.com> <4.3.2.7.2.20021210123021.0382fe10@paris.cisco.com> <3DF643DF.4F8AC12C@alcatel.be> <4.3.2.7.2.20021211114607.0513d0a0@paris.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi Dimitri, At 23:25 12/12/2002 +0100, Dimitri.Papadimitriou@alcatel.be wrote: >your impression is too affirmative wrt to my next reply >(i've never said that the xro mechanisms are restricted >to ma-te or that this i-d should be entirely dedicated >to it) also the intention of opening a charter item >implies imho structuring the content of proposals that >are on the table and that may further come in, this in >order to achieve common mechanisms in the scope of the >ccamp wg - in whatever i-d btw as long as it reproduces >the consensus of the wg (taking a look back at gmpls >signalling for instance you will see that it is the >concatenation of many individual submissions coming >from various horizons) > >as said before, we have currently two methods We probably have more ... we can also add some methods consisting on leaking part of the topology info into the areas, .... But I do agree with you that once the CCAMP charter explicitly includes the multi-area TE item, we will need to find a consensus and work on a single document. >on the >table 1) constraint passing and 2) path queries, the >first beneficiate from the fact it is the logical >evolution from loose routing (the next step) the other >uses signalling for querying a server, as such there >is one fundamental question underlying the latter: >moving features from distributed entities to the >centralized ones for path computation purposes solves >an intermediate problem (when a unique server is >available) that comes back when several centralized >systems have to interoperate I guess you are referring to the problem of multiple central systems sharing the path computation requests that indeed need to be in sync. That of course seriously increases the level of complexity but I do not think this is required. In the case of multi-area TE, a determined ABR (statically configured or dynamically discovered) can the THE PCS serving the requests for the LSRs residing within a specific area. In case of failure, a backup PCS can be used. >but also one fundamental >protocol aspect (which is due to the methods currently >proposed) using a signalling protocol like rsvp to >explicitly query a server is clearly questionable (*) Well, I would be more than happy to discuss this aspect of course, but not from a philosophical point of view ... We have various options there: (1) try to extend an existing protocol like RSVP. Note that http://www.ietf.org/internet-drafts/draft-vasseur-mpls-computation-rsvp-03.txt requires to specify only one new message type and a single additional object (REQUEST-ID object). All the other objects are completely optional. All the LSRs have already an RSVP stack and this allows to reuse all the RSVP objects defined so far to pass the constraints to the PCS. So the idea is: - to slightly extend an existing protocol (with one new message type, one new object required) without impacting its scalability, - re use all the existing objects, - not require any additional protocol running on the LSRs (2) re invent a new protocol from scratch ... I personally vote for the pragmatic approach (1), let see other inputs on the list. I won't go in the philosophical aspects ... Note that IGPs/RSVP have not been designed to carry Optical/SDH/SONET/... infos either and I think one could mention many other examples like this and as a matter of fact they perfectly make the job. I personally think that if an exiting protocol can be slightly extended (without impacting its scalability, ... ) and can solve an actual problem, this option is preferable than trying to reinvent a new protocol from scratch. Again I'll be more than happy to get more feed-backs on the list. >- i think this should be clarified in the kompella i-d What would you exactly want us to clarify in the i-d ? > >since this is independent from the fact that the server >is collocated on an abr or along the lsp path - back >to previous method using constraint passing i would >say constraint-passing keeps the current philosophy >of rsvp-te since based on the implicit assumption >that each hop (in particular abr in ma-te context) are >capable to respond to the incoming request; is the >latter optimal, no of course; but i would say that at >the end the "simplest solution to this complex problem >will remain", well i think that rfc 3439 phrases this >principle much better than i do; > >(*) understand this as a general remark people have >the tendency to overload/over-generalize the features >supported by a protocol and its applicability scope I am also hopping we will move forward on this discussion with the input of Service Providers on which method(s) for inter-area TE better address their needs. Thanks. Cheers, JP. >thanks, >- dimitri. > >Jean Philippe Vasseur wrote: > > > > Hi, > > > > At 10:43 11/12/2002 -0500, Cheng-Yin Lee wrote: > > >Dimitri, JP, > > >While I think an applicability section/statement is fine, I'm not sure > > >if a mechanism > > >to compute inter-area TE path belong in this ID. > > > > This was exactly my impression. > > > > JP. > > > > >We did include applications in the first discussion of this ID and in the > > >slides > > >http://www.ietf.org/proceedings/02mar/slides/ccamp-6/index.html and in > > >addressing > > >Kireeti's suggestion to include a discussion on the impact of message > > >size, we provided > > >an inter-area example for illustration purposes. However, there have also > > >been > > >suggestions in the past to not discuss applications specifically in the > > >draft itself. > > >I am fine with either way. > > > > > >thanks > > >cheng-yin > > > > > >Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > > jp, > > > > > > > > > this ID does not propose a mechanism to compute inter-area TE path > > > > > > > > well i would say that either none of them does it, or all of > > > > them, more accurately route exclusions are applicable to any > > > > mpls network where full computation of the ero is not performed > > > > before the LSP is signaled, implying thus a "scope" for computed > > > > path thus among other applicable to multiple areas - nevertheless > > > > i agree that a next version of this i-d should probably include > > > > an applicability section covering this in a bit more details (see > > > > also section 4.1 for an example - > > > > > > > > this said and as for any other input or i-d provided on constraint- > > > > passing (as well as path query, btw) lot of work is still needed to > > > > achieve a decent first step in this effort; > > > > > > > > thanks, > > > > - dimitri. > > > > > > > > Jean Philippe Vasseur wrote: > > > > > > > > > > Hi Dimitri, > > > > > > > > > > cc'ing CCAMP - see in line, > > > > > > > > > > At 17:45 10/12/2002 +0100, Dimitri.Papadimitriou@alcatel.be wrote: > > > > > >jp, > > > > > > > > > > > >in fact the below list should simply be as follows for > > > > > >signalling-based methods: 1) constraint-passing 2) loose > > > > > >routing and 3) path query; > > > > > > > > > > > >and the for constraint-passing we have a several i-d's > > > > > >such as, > > > > > > > > > > > >http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclu > de-r > > > oute-01.txt > > > > > > > > > > > > > > > > this ID does not propose a mechanism to compute inter-area TE path > > > > > > > > > > >constraint passing may also be extended using the crank- > > > > > >back as listed below; the usage scenarios of these methods > > > > > >are described in the following: > > > > > > > > > > > >http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea > -te- > > > 03.txt > > > > > > > > > > > >now probably it is worth spending some time in considering > > > > > >input coming from the tewg wrt to this effort, most of the > > > > > >input that you see listed above has been produced over the > > > > > >past year (and more) i can't imagine stepping in the protocol > > > > > >details without a clear consensus on what do we want to cover > > > > > >within the ccamp wg & w/o taking into account the tewg rec's > > > > > >(probably better to discuss this on the ccamp mailing list) > > > > > > > > > > Fully agree with you. Hopefully multi-area TE should be soon part > of the > > > > > CCAMP charter. > > > > > > > > > > JP. > > > > > > > > > > >thanks, > > > > > >- dimitri. > > > > > > > > > > > >Jean Philippe Vasseur wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > At 13:53 10/12/2002 +0530, sachin laddha wrote: > > > > > > > >Hi, > > > > > > > >'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as > > > > > > > >"Initial requirements are given here for protocol support of the > > > > > > multi-area > > > > > > > >TE methods, which include needs to support > > > > > > > > > > > > > > > >* path-computation-server (PCS) functionality > [kompella, lee, > > > > > > vasseur, > > > > > > > >te-qos-routing], > > > > > > > >* query functionality [query, vasseur], > > > > > > > >* crankback functionality [crankback], > > > > > > > > > > > > > > > >and, optionally, > > > > > > > > > > > > > > > >* TE feedback functionality [feedback], and > > > > > > > >* summary-LSA functionality [summary_lsa]." > > > > > > > >. > > > > > > > >I want to know whether cisco/juniper routers (standard ones) > > > supports > > > > > > all of > > > > > > > >the above extension. > > > > > > > >or if not,how many.......or Whether router is supposed to > > > support how many > > > > > > > >... > > > > > > > > > > > > > > I do not think any vendor supports all the method mentioned > > > above, but just > > > > > > > a subset. If you are running a network, your feed-backs on your > > > preferred > > > > > > > method is very welcome. > > > > > > > > > > > > > > JP. > > > > > > > > > > > > > > >Regards, > > > > > > > >---Sachin > > > > > > > > > > > >-- > > > > > >Papadimitriou Dimitri > > > > > >E-mail : dimitri.papadimitriou@alcatel.be > > > > > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > > > > >E-mail : dpapadimitriou@psg.com > > > > > >Public : http://psg.com/~dpapadimitriou/ > > > > > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > > > > >Phone : Work: +32 3 2408491 - Home: +32 2 3434361 > > > > > > > > -- > > > > Papadimitriou Dimitri > > > > E-mail : dimitri.papadimitriou@alcatel.be > > > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > > > E-mail : dpapadimitriou@psg.com > > > > Public : http://psg.com/~dpapadimitriou/ > > > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > > > Phone : Work: +32 3 2408491 - Home: +32 2 3434361 > >-- >Papadimitriou Dimitri >E-mail : dimitri.papadimitriou@alcatel.be >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html >E-mail : dpapadimitriou@psg.com >Public : http://psg.com/~dpapadimitriou/ >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium >Phone : Work: +32 3 2408491 - Home: +32 2 3434361 From owner-mpls@UU.NET Fri Dec 13 13:58: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 NAA01833 for ; Fri, 13 Dec 2002 13:58:46 -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 QQntce17924 for ; Fri, 13 Dec 2002 19:01:24 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 QQntcd12893; Fri, 13 Dec 2002 18:58:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQntcd12851 for mpls-outgoing; Fri, 13 Dec 2002 18:58:28 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 QQntcd12839 for ; Fri, 13 Dec 2002 18:58:21 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 QQntcd27548 for ; Fri, 13 Dec 2002 18:58: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 QQntcd12488 for ; Fri, 13 Dec 2002 18:58:07 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 QQntcd12484 for ; Fri, 13 Dec 2002 18:58:06 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBDIwak1022122 for ; Fri, 13 Dec 2002 13:58:37 -0500 (EST) 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 NAA07311 for ; Fri, 13 Dec 2002 13:58:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBDIw5P28633 for mpls@uu.net; Fri, 13 Dec 2002 13:58:05 -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 QQntcd12785 for ; Fri, 13 Dec 2002 18:57:09 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 QQntcd00331 for ; Fri, 13 Dec 2002 18:56: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 QQntcd11097 for ; Fri, 13 Dec 2002 18:56:22 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 QQntcd11091 for ; Fri, 13 Dec 2002 18:56:21 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 NAA52023; Fri, 13 Dec 2002 13:56:12 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212131856.NAA52023@workhorse.fictitious.org> To: Shahram Davari cc: "'curtis@fictitious.org'" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Fri, 13 Dec 2002 06:16:55 PST." <4B6D09F3B826D411A67300D0B706EFDEB03B90@nt-exch-yow.pmc-sierra.bc.ca> Date: Fri, 13 Dec 2002 13:56:11 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4B6D09F3B826D411A67300D0B706EFDEB03B90@nt-exch-yow.pmc-sierra.bc.ca >, Shahram Davari writes: > Curtis, > > I was more thinking in terms of how to make sure the backup/detour > paths are working fine, while the traffic is still on the working path. > > Yours, > -Shahram Currently you'd have to do that from each PLR. We don't provide a means to tell the ingress of the existance of a detour (except the local-protect-available bit in the signaling itself which one major implementation wasn't using last I checked). We also don't provide a means to tell a specific PLR to exercise its detour and report back. Let's wait and hear from Kireeti or other authors whether they think anything should be added or whether the intent is to require testing initiated at each PLR. There is no way to run a (non-intrusive) test that would determine whether the traffic would be correctly diverted on failure. That is not a limitation of the protocol. There is no way to test it other than induce a failure. Curtis > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > Sent: Thursday, December 12, 2002 11:14 PM > > To: Shahram Davari > > Cc: mpls@UU.NET > > Subject: Re: Last call on LSP Ping > > > > > > > > In message > > <4B6D09F3B826D411A67300D0B706EFDEB03B8C@nt-exch-yow.pmc-sierra.bc.ca > > >, Shahram Davari writes: > > > Hi, > > > > > > Would the authors comment on how the MPLS-ping applies when > > > Fast Reroute scheme exists? In other words how is the backup path > > > and/or detour paths tested from the ingress? > > > > > > Thanks, > > > -Shahram > > > > > > In ping mode you should not know that the backup is in use. > > > > Perhaps an error return in traceroute mode would be helpful or an > > indication that the next hop is part of a detour. > > > > Keep in mind that once the detour is put into use it is usually a > > matter of seconds before a new primary is created with its own set of > > detours, none of which are in use. > > > > Curtis > > > From owner-mpls@UU.NET Fri Dec 13 14:21: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 OAA02668 for ; Fri, 13 Dec 2002 14:21:52 -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 QQntcf02243 for ; Fri, 13 Dec 2002 19:24: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 QQntcf00463; Fri, 13 Dec 2002 19:23:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQntcf03737 for mpls-outgoing; Fri, 13 Dec 2002 19:23: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 QQntcf03726 for ; Fri, 13 Dec 2002 19:23:29 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 QQntcf21747 for ; Fri, 13 Dec 2002 19:23: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 QQntcf09736 for ; Fri, 13 Dec 2002 19:23:21 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 QQntcf09726 for ; Fri, 13 Dec 2002 19:23:20 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 gBDJNKS31540; Fri, 13 Dec 2002 11:23:20 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id gBDJNKv30420; Fri, 13 Dec 2002 11:23:20 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Fri, 13 Dec 2002 11:23:20 -0800 (PST) From: Kireeti Kompella To: Curtis Villamizar cc: Shahram Davari , Subject: Re: Last call on LSP Ping In-Reply-To: <200212131856.NAA52023@workhorse.fictitious.org> Message-ID: <20021213111527.V30401-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Curtis, Shahram: On Fri, 13 Dec 2002, Curtis Villamizar wrote: > > I was more thinking in terms of how to make sure the backup/detour > > paths are working fine, while the traffic is still on the working path. > > > Currently you'd have to do that from each PLR. Agreed. One question is, do the PLRs do this autonomously, or should this be triggered by LSP pings for the protected LSPs (to be more accurate, LSP traceroutes)? For now, I'm happy to go with the former. > We also don't provide a > means to tell a specific PLR to exercise its detour and report back. Having the PLR exercise (i.e., send pings along) its detours is up to the implementation. Right now, there is no LSP ping mechanism for reporting back. Should there be? (If so, I would rather leave it to a follow-up doc.) > Let's wait and hear from Kireeti or other authors whether they think > anything should be added or whether the intent is to require testing > initiated at each PLR. You've heard from me (insofar as you can hear email) :-) Kireeti. From owner-mpls@UU.NET Fri Dec 13 14:27: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 OAA02836 for ; Fri, 13 Dec 2002 14:27: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 QQntcg16549 for ; Fri, 13 Dec 2002 19:30:16 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 QQntcf14141; Fri, 13 Dec 2002 19:29:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQntcf04206 for mpls-outgoing; Fri, 13 Dec 2002 19:28: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 QQntcf04200 for ; Fri, 13 Dec 2002 19:28:37 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 QQntcf08356 for ; Fri, 13 Dec 2002 19:28:28 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 QQntcf10077 for ; Fri, 13 Dec 2002 19:28:27 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 QQntcf10073 for ; Fri, 13 Dec 2002 19:28:27 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 gBDJSQS32083; Fri, 13 Dec 2002 11:28:26 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id gBDJSQa30450; Fri, 13 Dec 2002 11:28:26 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Fri, 13 Dec 2002 11:28:26 -0800 (PST) From: Kireeti Kompella To: "Thomas D. Nadeau" cc: Subject: RE: Last call on LSP Ping In-Reply-To: <5.2.0.9.2.20021213094319.094389b0@bucket.cisco.com> Message-ID: <20021213112401.Y30424-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Tom, On Fri, 13 Dec 2002, Thomas D. Nadeau wrote: > > It does seem plausible that RSVP-TE could signal > backup tunnels that could black hole traffic on the data plane > once switched on. It is possible to do this at least in the facility- > based FRR mode, since a TE tunnel is signaled a priori (perhaps many > of them), so one could go and test each to verify their health > to make sure that they are really protecting once turned on. (I appear to have an email *stack*, LIFO) As Curtis mentioned, the PLR can initiate such tests. Furthermore, the head end can test presignaled backup LSPs (alternate tunnel instances). All of these are left to the implementation to provide; perhaps after some experience, we will find that some enhancements to LSP ping to make this work better. Kireeti. From owner-mpls@UU.NET Fri Dec 13 14:28: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 OAA02912 for ; Fri, 13 Dec 2002 14:28:37 -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 QQntcg09378 for ; Fri, 13 Dec 2002 19:31:27 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 QQntcf27884; Fri, 13 Dec 2002 19:25:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQntcf03795 for mpls-outgoing; Fri, 13 Dec 2002 19:25: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 QQntcf03774 for ; Fri, 13 Dec 2002 19:25: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 QQntcf24232 for ; Fri, 13 Dec 2002 19:24: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 QQntcf10103 for ; Fri, 13 Dec 2002 19:24:07 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 QQntcf10094 for ; Fri, 13 Dec 2002 19:24:06 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBDJOawd026063 for ; Fri, 13 Dec 2002 14:24:37 -0500 (EST) 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 OAA09769 for ; Fri, 13 Dec 2002 14:24:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBDJO5N02572 for mpls@uu.net; Fri, 13 Dec 2002 14:24: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 QQntcf03698 for ; Fri, 13 Dec 2002 19:23:00 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 QQntcf16752 for ; Fri, 13 Dec 2002 19:22: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 QQntcf09126 for ; Fri, 13 Dec 2002 19:22:31 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 QQntcf09117 for ; Fri, 13 Dec 2002 19:22:30 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBDJMpM0025752; Fri, 13 Dec 2002 14:22:51 -0500 (EST) 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 OAA09576; Fri, 13 Dec 2002 14:22:20 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA18873; Fri, 13 Dec 2002 14:22:19 -0500 (EST) Message-Id: <200212131922.OAA18873@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: curtis@fictitious.org cc: Shahram Davari , mpls@UU.NET, swallow@cisco.com Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Fri, 13 Dec 2002 13:56:11 EST." <200212131856.NAA52023@workhorse.fictitious.org> Date: Fri, 13 Dec 2002 14:22:19 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > Currently you'd have to do that from each PLR. We don't provide a > means to tell the ingress of the existance of a detour (except the > local-protect-available bit in the signaling itself which one major > implementation wasn't using last I checked). We also don't provide a > means to tell a specific PLR to exercise its detour and report back. > > Let's wait and hear from Kireeti or other authors whether they think > anything should be added or whether the intent is to require testing > initiated at each PLR. The PLR is responsible for the bypass. It knows what sender-template it used, so it can form the proper FEC for the ping. It can send a lsp-ping with the proper label stack. So it is the natural place to do this. If it fails, it should a) report to network management b) reset the backup in place bit c) look for another way of establishing a backup d) if successful on c) set the backup in place bit. You may want to put a hold-down on b) to avoid reporting to the head-end on a transient situation. I don't see what advantage you would gain by moving all this to the head-end. I do see a lot of complications... ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Fri Dec 13 14:31:10 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 OAA03073 for ; Fri, 13 Dec 2002 14:31:10 -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 QQntcg15011 for ; Fri, 13 Dec 2002 19:34:01 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 QQntcg09292; Fri, 13 Dec 2002 19:31:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQntcg04439 for mpls-outgoing; Fri, 13 Dec 2002 19:30: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 QQntcg04426 for ; Fri, 13 Dec 2002 19:30:46 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 QQntcg12697 for ; Fri, 13 Dec 2002 19:30:40 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 QQntcg07649 for ; Fri, 13 Dec 2002 19:30:38 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 QQntcg07618 for ; Fri, 13 Dec 2002 19:30:38 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Dec 2002 14:30:34 -0500 Message-ID: <1117F7D44159934FB116E36F4ABF221B0267EDA8@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'George Swallow'" , curtis@fictitious.org Cc: Shahram Davari , mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Fri, 13 Dec 2002 14:30: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 And so, naturally, you could make this same argument for how an ECMP splitter would test out all of the equal cost paths... Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Friday, December 13, 2002 2:22 PM > To: curtis@fictitious.org > Cc: Shahram Davari; mpls@UU.NET; swallow@cisco.com > Subject: Re: Last call on LSP Ping > > > Currently you'd have to do that from each PLR. We don't provide a > > means to tell the ingress of the existance of a detour (except the > > local-protect-available bit in the signaling itself which one major > > implementation wasn't using last I checked). We also don't provide a > > means to tell a specific PLR to exercise its detour and report back. > > > > Let's wait and hear from Kireeti or other authors whether they think > > anything should be added or whether the intent is to require testing > > initiated at each PLR. > > The PLR is responsible for the bypass. It knows what sender-template > it used, so it can form the proper FEC for the ping. It can send a > lsp-ping with the proper label stack. So it is the natural place to > do this. If it fails, it should > > a) report to network management > b) reset the backup in place bit > c) look for another way of establishing a backup > d) if successful on c) set the backup in place bit. > > You may want to put a hold-down on b) to avoid reporting to the > head-end on a transient situation. > > I don't see what advantage you would gain by moving all this to the > head-end. I do see a lot of complications... > > ...George > > > ================================================================== > George Swallow Cisco Systems (978) 497-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 From owner-mpls@UU.NET Fri Dec 13 14:41: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 OAA03368 for ; Fri, 13 Dec 2002 14:41:27 -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 QQntcg24527 for ; Fri, 13 Dec 2002 19:44: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 QQntcg20570; Fri, 13 Dec 2002 19:42:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQntcg05587 for mpls-outgoing; Fri, 13 Dec 2002 19:41: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 QQntcg05561 for ; Fri, 13 Dec 2002 19:41:25 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 QQntcg15364 for ; Fri, 13 Dec 2002 19:41: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 QQntcg26507 for ; Fri, 13 Dec 2002 19:41:06 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 QQntcg26496 for ; Fri, 13 Dec 2002 19:41:06 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBDJfaMp028533 for ; Fri, 13 Dec 2002 14:41:36 -0500 (EST) 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 OAA11262 for ; Fri, 13 Dec 2002 14:41:04 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBDJf4106492 for mpls@uu.net; Fri, 13 Dec 2002 14:41:04 -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 QQntcg05238 for ; Fri, 13 Dec 2002 19:39:17 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 QQntcg04586 for ; Fri, 13 Dec 2002 19:39: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 QQntcg24979 for ; Fri, 13 Dec 2002 19:39:04 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 QQntcg24973 for ; Fri, 13 Dec 2002 19:39:03 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 OAA52376; Fri, 13 Dec 2002 14:38:49 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212131938.OAA52376@workhorse.fictitious.org> To: George Swallow cc: curtis@fictitious.org, Shahram Davari , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Fri, 13 Dec 2002 14:22:19 EST." <200212131922.OAA18873@bifocal.cisco.com> Date: Fri, 13 Dec 2002 14:38:48 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <200212131922.OAA18873@bifocal.cisco.com>, George Swallow writes: > > Currently you'd have to do that from each PLR. We don't provide a > > means to tell the ingress of the existance of a detour (except the > > local-protect-available bit in the signaling itself which one major > > implementation wasn't using last I checked). We also don't provide a > > means to tell a specific PLR to exercise its detour and report back. > > > > Let's wait and hear from Kireeti or other authors whether they think > > anything should be added or whether the intent is to require testing > > initiated at each PLR. > > The PLR is responsible for the bypass. It knows what sender-template > it used, so it can form the proper FEC for the ping. It can send a > lsp-ping with the proper label stack. So it is the natural place to > do this. If it fails, it should > > a) report to network management > b) reset the backup in place bit > c) look for another way of establishing a backup > d) if successful on c) set the backup in place bit. > > You may want to put a hold-down on b) to avoid reporting to the > head-end on a transient situation. > > I don't see what advantage you would gain by moving all this to the > head-end. I do see a lot of complications... > > ...George I agree. That is why I suggested we should ask the authors first before suggesting more protocol gorp. Curtis From owner-mpls@UU.NET Fri Dec 13 14:48:45 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 OAA03532 for ; Fri, 13 Dec 2002 14:48:45 -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 QQntch05547 for ; Fri, 13 Dec 2002 19:51: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 QQntch01316; Fri, 13 Dec 2002 19:49:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQntch06635 for mpls-outgoing; Fri, 13 Dec 2002 19:48: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 QQntch06593 for ; Fri, 13 Dec 2002 19:48: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 QQntch04589 for ; Fri, 13 Dec 2002 19:47: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 QQntch02552 for ; Fri, 13 Dec 2002 19:47:21 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 QQntch02542 for ; Fri, 13 Dec 2002 19:47:20 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBDJloiC029522 for ; Fri, 13 Dec 2002 14:47:50 -0500 (EST) 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 OAA11819 for ; Fri, 13 Dec 2002 14:47:19 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBDJlJS07348 for mpls@uu.net; Fri, 13 Dec 2002 14:47:19 -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 QQntcg05641 for ; Fri, 13 Dec 2002 19:42:39 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 QQntcg17070 for ; Fri, 13 Dec 2002 19:41: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 QQntcg29400 for ; Fri, 13 Dec 2002 19:41:46 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 QQntcg29365 for ; Fri, 13 Dec 2002 19:41:45 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 OAA52395; Fri, 13 Dec 2002 14:41:34 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212131941.OAA52395@workhorse.fictitious.org> To: Kireeti Kompella cc: Curtis Villamizar , Shahram Davari , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Fri, 13 Dec 2002 11:23:20 PST." <20021213111527.V30401-100000@kummer.juniper.net> Date: Fri, 13 Dec 2002 14:41:34 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <20021213111527.V30401-100000@kummer.juniper.net>, Kireeti Kompella writes: > Hi Curtis, Shahram: > > On Fri, 13 Dec 2002, Curtis Villamizar wrote: > > > > I was more thinking in terms of how to make sure the backup/detour > > > paths are working fine, while the traffic is still on the working path. > > > > > > Currently you'd have to do that from each PLR. > > Agreed. One question is, do the PLRs do this autonomously, or should > this be triggered by LSP pings for the protected LSPs (to be more > accurate, LSP traceroutes)? For now, I'm happy to go with the former. > > > We also don't provide a > > means to tell a specific PLR to exercise its detour and report back. > > Having the PLR exercise (i.e., send pings along) its detours is up > to the implementation. Right now, there is no LSP ping mechanism for > reporting back. Should there be? (If so, I would rather leave it to > a follow-up doc.) > > > Let's wait and hear from Kireeti or other authors whether they think > > anything should be added or whether the intent is to require testing > > initiated at each PLR. > > You've heard from me (insofar as you can hear email) :-) > > Kireeti. I like the extension doc idea. If there is a perceived need (from those who deployed it) after MPLS-ping is deployed, an extention can be added. Curtis From owner-mpls@UU.NET Fri Dec 13 14:48: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 OAA03546 for ; Fri, 13 Dec 2002 14:48:47 -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 QQntch13006 for ; Fri, 13 Dec 2002 19:51:38 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 QQntch06172; Fri, 13 Dec 2002 19:48:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQntch06516 for mpls-outgoing; Fri, 13 Dec 2002 19:47:53 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 QQntch06477 for ; Fri, 13 Dec 2002 19:47:43 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 QQntch02628 for ; Fri, 13 Dec 2002 19:46:56 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 QQntch01921 for ; Fri, 13 Dec 2002 19:46:56 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 QQntch01880 for ; Fri, 13 Dec 2002 19:46:55 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 gBDJksS34008; Fri, 13 Dec 2002 11:46:54 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id gBDJksx30577; Fri, 13 Dec 2002 11:46:54 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Fri, 13 Dec 2002 11:46:54 -0800 (PST) From: Kireeti Kompella To: "Gray, Eric" cc: Subject: RE: Last call on LSP Ping In-Reply-To: <1117F7D44159934FB116E36F4ABF221B0267EDA8@celox-ma1-ems1.celoxnetworks.com> Message-ID: <20021213114302.P30556-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Eric, On Fri, 13 Dec 2002, Gray, Eric wrote: > And so, naturally, you could make this same argument for > how an ECMP splitter would test out all of the equal cost > paths... There is a difference between ECMP and detours, which I am sure you appreciate, but for the good of all, I'll articulate: packets can in principle take all ECMP paths; however, packets cannot (SHOULD NOT) take a detour without a failure occurring. Kireeti. From owner-mpls@UU.NET Fri Dec 13 14:56: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 OAA03737 for ; Fri, 13 Dec 2002 14:56:30 -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 QQntch19407 for ; Fri, 13 Dec 2002 19: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 QQntch14437; Fri, 13 Dec 2002 19:56:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQntch07601 for mpls-outgoing; Fri, 13 Dec 2002 19:56: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 QQntch07306 for ; Fri, 13 Dec 2002 19:55:59 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 QQntch12414 for ; Fri, 13 Dec 2002 19:54: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 QQntch11580 for ; Fri, 13 Dec 2002 19:54:08 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 QQntch11575 for ; Fri, 13 Dec 2002 19:54:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBDJsc0h000618 for ; Fri, 13 Dec 2002 14:54:38 -0500 (EST) 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 OAA12505 for ; Fri, 13 Dec 2002 14:54:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBDJs6g10873 for mpls@uu.net; Fri, 13 Dec 2002 14:54:06 -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 QQntch06803 for ; Fri, 13 Dec 2002 19:51:14 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 QQntch14524 for ; Fri, 13 Dec 2002 19:50:55 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 QQntch06075 for ; Fri, 13 Dec 2002 19:50:55 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 QQntch06061 for ; Fri, 13 Dec 2002 19:50:54 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 gBDJpNiV029995; Fri, 13 Dec 2002 14:51:24 -0500 (EST) Received: from tnadeau-w2k.cisco.com (rtp-vpn1-838.cisco.com [10.82.227.70]) by bucket.cisco.com (Mirapoint) with ESMTP id ACG68983; Fri, 13 Dec 2002 14:50:51 -0500 (EST) Message-Id: <5.2.0.9.2.20021213144925.09723e40@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 13 Dec 2002 14:50:48 -0500 To: Kireeti Kompella From: "Thomas D. Nadeau" Subject: Re: Last call on LSP Ping Cc: In-Reply-To: <20021213111527.V30401-100000@kummer.juniper.net> References: <200212131856.NAA52023@workhorse.fictitious.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 11:23 AM 12/13/2002 -0800, Kireeti Kompella wrote: >Hi Curtis, Shahram: > >On Fri, 13 Dec 2002, Curtis Villamizar wrote: > > > > I was more thinking in terms of how to make sure the backup/detour > > > paths are working fine, while the traffic is still on the working path. > > > > > > Currently you'd have to do that from each PLR. > >Agreed. One question is, do the PLRs do this autonomously, or should >this be triggered by LSP pings for the protected LSPs (to be more >accurate, LSP traceroutes)? For now, I'm happy to go with the former. It is probably best to let them do this whether or not the LSR is programmed to do so. > > We also don't provide a > > means to tell a specific PLR to exercise its detour and report back. > >Having the PLR exercise (i.e., send pings along) its detours is up >to the implementation. Right now, there is no LSP ping mechanism for >reporting back. Should there be? (If so, I would rather leave it to >a follow-up doc.) I think this belongs in another document specific to FRR. --Tom > > Let's wait and hear from Kireeti or other authors whether they think > > anything should be added or whether the intent is to require testing > > initiated at each PLR. > >You've heard from me (insofar as you can hear email) :-) > >Kireeti. "The difficult, we do immediately. The impossible takes a little longer." -- Air Force Motto From owner-mpls@UU.NET Fri Dec 13 14:59: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 OAA03827 for ; Fri, 13 Dec 2002 14:59:18 -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 QQntci21345 for ; Fri, 13 Dec 2002 20:02: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 QQntci18545; Fri, 13 Dec 2002 20:00:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQntci10313 for mpls-outgoing; Fri, 13 Dec 2002 20:00: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 QQntci08815 for ; Fri, 13 Dec 2002 20:00:06 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 QQntch10361 for ; Fri, 13 Dec 2002 19:59:51 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 QQntch20369 for ; Fri, 13 Dec 2002 19:59:50 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 QQntch20039 for ; Fri, 13 Dec 2002 19:59:39 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 gBDJxaS35240; Fri, 13 Dec 2002 11:59:36 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id gBDJxaI30705; Fri, 13 Dec 2002 11:59:36 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Fri, 13 Dec 2002 11:59:36 -0800 (PST) From: Kireeti Kompella To: Shahram Davari cc: Subject: RE: Last call on LSP Ping In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03B98@nt-exch-yow.pmc-sierra.bc.ca> Message-ID: <20021213115759.A30654-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Shahram, On Fri, 13 Dec 2002, Shahram Davari wrote: > Are you saying that now all LSRs (even the intermediate ones) > need to be able to generate and process MPLS-ping and keep > MPLS-ping states? To be more precise, PLRs. Do you have an alternative suggestion? Note that PLRs testing detours can do so at a more leisurely pace. Kireeti. From owner-mpls@UU.NET Fri Dec 13 15:00: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 PAA03893 for ; Fri, 13 Dec 2002 15:00:19 -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 QQntci05399 for ; Fri, 13 Dec 2002 20:03: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 QQntch17913; Fri, 13 Dec 2002 19:53:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQntch07112 for mpls-outgoing; Fri, 13 Dec 2002 19:53: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 QQntch07085 for ; Fri, 13 Dec 2002 19:53:25 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 QQntch10477 for ; Fri, 13 Dec 2002 19:53: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 QQntch10694 for ; Fri, 13 Dec 2002 19:53:23 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 QQntch10688 for ; Fri, 13 Dec 2002 19:53:22 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBDJrqxB000414 for ; Fri, 13 Dec 2002 14:53:52 -0500 (EST) 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 OAA12406 for ; Fri, 13 Dec 2002 14:53:21 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBDJrL410500 for mpls@uu.net; Fri, 13 Dec 2002 14:53:21 -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 QQntch06591 for ; Fri, 13 Dec 2002 19:48: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 QQntch05096 for ; Fri, 13 Dec 2002 19:47: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 QQntch02633 for ; Fri, 13 Dec 2002 19:47:31 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 QQntch02625 for ; Fri, 13 Dec 2002 19:47:30 GMT Received: (qmail 585 invoked by uid 104); 13 Dec 2002 19:47:29 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 (uvscan: v4.1.40/v4237. Clear:. Processed in 5.176759 secs); 13 Dec 2002 19:47:29 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 13 Dec 2002 19:47:13 -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 gBDJlDQ07051; Fri, 13 Dec 2002 11:47:13 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Fri, 13 Dec 2002 11:47:13 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B98@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'George Swallow'" , curtis@fictitious.org Cc: mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Fri, 13 Dec 2002 11:47:12 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Are you saying that now all LSRs (even the intermediate ones) need to be able to generate and process MPLS-ping and keep MPLS-ping states? -Shahram > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Friday, December 13, 2002 2:22 PM > To: curtis@fictitious.org > Cc: Shahram Davari; mpls@UU.NET; swallow@cisco.com > Subject: Re: Last call on LSP Ping > > > > Currently you'd have to do that from each PLR. We don't provide a > > means to tell the ingress of the existance of a detour (except the > > local-protect-available bit in the signaling itself which one major > > implementation wasn't using last I checked). We also don't > provide a > > means to tell a specific PLR to exercise its detour and report back. > > > > Let's wait and hear from Kireeti or other authors whether they think > > anything should be added or whether the intent is to require testing > > initiated at each PLR. > > The PLR is responsible for the bypass. It knows what sender-template > it used, so it can form the proper FEC for the ping. It can send a > lsp-ping with the proper label stack. So it is the natural place to > do this. If it fails, it should > > a) report to network management > b) reset the backup in place bit > c) look for another way of establishing a backup > d) if successful on c) set the backup in place bit. > > You may want to put a hold-down on b) to avoid reporting to the > head-end on a transient situation. > > I don't see what advantage you would gain by moving all this to the > head-end. I do see a lot of complications... > > ...George > > > ================================================================== > George Swallow Cisco Systems (978) 497-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > From owner-mpls@UU.NET Fri Dec 13 15:01: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 PAA03951 for ; Fri, 13 Dec 2002 15:01:48 -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 QQntci29851 for ; Fri, 13 Dec 2002 20: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 QQntci20714; Fri, 13 Dec 2002 20:00:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQntch07854 for mpls-outgoing; Fri, 13 Dec 2002 19:59: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 QQntch07734 for ; Fri, 13 Dec 2002 19:58:46 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 QQntch03204 for ; Fri, 13 Dec 2002 19:57: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 QQntch15367 for ; Fri, 13 Dec 2002 19:57:15 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 QQntch15328 for ; Fri, 13 Dec 2002 19:57:12 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBDJvg15000990 for ; Fri, 13 Dec 2002 14:57:42 -0500 (EST) 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 OAA12742 for ; Fri, 13 Dec 2002 14:57:10 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBDJvA312625 for mpls@uu.net; Fri, 13 Dec 2002 14:57:10 -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 QQntch07229 for ; Fri, 13 Dec 2002 19:54: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 QQntch24640 for ; Fri, 13 Dec 2002 19:54: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 QQntch18813 for ; Fri, 13 Dec 2002 19:54:25 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 QQntch18510 for ; Fri, 13 Dec 2002 19:54:17 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 OAA52572; Fri, 13 Dec 2002 14:53:49 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212131953.OAA52572@workhorse.fictitious.org> To: "Gray, Eric" cc: "'George Swallow'" , curtis@fictitious.org, Shahram Davari , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Fri, 13 Dec 2002 14:30:30 EST." <1117F7D44159934FB116E36F4ABF221B0267EDA8@celox-ma1-ems1.celoxnetworks.com> Date: Fri, 13 Dec 2002 14:53:49 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <1117F7D44159934FB116E36F4ABF221B0267EDA8@celox-ma1-ems1.celoxnetwor ks.com>, "Gray, Eric" writes: > And so, naturally, you could make this same argument for > how an ECMP splitter would test out all of the equal cost > paths... The ECMP split affects the primary path. The traffic for a branch has to be injected upstream of the branch or you are not adequately testing it. There is no way to send traffic from upstream of a detour to exercise a detour that is not in use. Curtis > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > > -----Original Message----- > > From: George Swallow [mailto:swallow@cisco.com] > > Sent: Friday, December 13, 2002 2:22 PM > > To: curtis@fictitious.org > > Cc: Shahram Davari; mpls@UU.NET; swallow@cisco.com > > Subject: Re: Last call on LSP Ping > > > > > Currently you'd have to do that from each PLR. We don't provide a > > > means to tell the ingress of the existance of a detour (except the > > > local-protect-available bit in the signaling itself which one major > > > implementation wasn't using last I checked). We also don't provide a > > > means to tell a specific PLR to exercise its detour and report back. > > > > > > Let's wait and hear from Kireeti or other authors whether they think > > > anything should be added or whether the intent is to require testing > > > initiated at each PLR. > > > > The PLR is responsible for the bypass. It knows what sender-template > > it used, so it can form the proper FEC for the ping. It can send a > > lsp-ping with the proper label stack. So it is the natural place to > > do this. If it fails, it should > > > > a) report to network management > > b) reset the backup in place bit > > c) look for another way of establishing a backup > > d) if successful on c) set the backup in place bit. > > > > You may want to put a hold-down on b) to avoid reporting to the > > head-end on a transient situation. > > > > I don't see what advantage you would gain by moving all this to the > > head-end. I do see a lot of complications... > > > > ...George > > > > > > ================================================================== > > George Swallow Cisco Systems (978) 497-8143 > > 250 Apollo Drive > > Chelmsford, Ma 01824 > From owner-mpls@UU.NET Fri Dec 13 15:06: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 PAA04017 for ; Fri, 13 Dec 2002 15:06:31 -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 QQntci18314 for ; Fri, 13 Dec 2002 20:09: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 QQntci05791; Fri, 13 Dec 2002 20:03:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQntci18279 for mpls-outgoing; Fri, 13 Dec 2002 20:02:02 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 QQntci13632 for ; Fri, 13 Dec 2002 20:01: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 QQntci13885 for ; Fri, 13 Dec 2002 20:00:55 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 QQntci01179 for ; Fri, 13 Dec 2002 20:00:52 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 QQntci00983 for ; Fri, 13 Dec 2002 20:00:46 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Dec 2002 15:00:45 -0500 Message-ID: <1117F7D44159934FB116E36F4ABF221B0267EDAA@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'curtis@fictitious.org'" , "Gray, Eric" Cc: "'George Swallow'" , Shahram Davari , mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Fri, 13 Dec 2002 15:00:43 -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, You're applying the argument in the reverse of the way I intended. :-) In the same way that it is possible to argue that a PLR knows where a back up path goes, so does an ECMP splitter. On a slightly different but related topic, note that - for the trace-route capability - the Downstream Mapping object makes it quite straight forward for the ECMP splitter to indicate to the head-end that there are multiple labels and next-hops it might use for a specific FEC. Too bad, is it not, that this is not as true for the Ping capability. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: Friday, December 13, 2002 2:54 PM > To: Gray, Eric > Cc: 'George Swallow'; curtis@fictitious.org; Shahram Davari; mpls@UU.NET > Subject: Re: Last call on LSP Ping > > > In message <1117F7D44159934FB116E36F4ABF221B0267EDA8@celox-ma1- > ems1.celoxnetwor > ks.com>, "Gray, Eric" writes: > > And so, naturally, you could make this same argument for > > how an ECMP splitter would test out all of the equal cost > > paths... > > > The ECMP split affects the primary path. The traffic for a branch has > to be injected upstream of the branch or you are not adequately > testing it. There is no way to send traffic from upstream of a detour > to exercise a detour that is not in use. > > Curtis > > > > Eric W. Gray > > Systems Architect > > Celox Networks, Inc. > > egray@celoxnetworks.com > > 508 305 7214 > > > > > > > -----Original Message----- > > > From: George Swallow [mailto:swallow@cisco.com] > > > Sent: Friday, December 13, 2002 2:22 PM > > > To: curtis@fictitious.org > > > Cc: Shahram Davari; mpls@UU.NET; swallow@cisco.com > > > Subject: Re: Last call on LSP Ping > > > > > > > Currently you'd have to do that from each PLR. We don't provide a > > > > means to tell the ingress of the existance of a detour (except the > > > > local-protect-available bit in the signaling itself which one major > > > > implementation wasn't using last I checked). We also don't provide > a > > > > means to tell a specific PLR to exercise its detour and report back. > > > > > > > > Let's wait and hear from Kireeti or other authors whether they think > > > > anything should be added or whether the intent is to require testing > > > > initiated at each PLR. > > > > > > The PLR is responsible for the bypass. It knows what sender-template > > > it used, so it can form the proper FEC for the ping. It can send a > > > lsp-ping with the proper label stack. So it is the natural place to > > > do this. If it fails, it should > > > > > > a) report to network management > > > b) reset the backup in place bit > > > c) look for another way of establishing a backup > > > d) if successful on c) set the backup in place bit. > > > > > > You may want to put a hold-down on b) to avoid reporting to the > > > head-end on a transient situation. > > > > > > I don't see what advantage you would gain by moving all this to the > > > head-end. I do see a lot of complications... > > > > > > ...George > > > > > > > > > ================================================================== > > > George Swallow Cisco Systems (978) 497-8143 > > > 250 Apollo Drive > > > Chelmsford, Ma 01824 > > From owner-mpls@UU.NET Fri Dec 13 15:18: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 PAA04298 for ; Fri, 13 Dec 2002 15:18:03 -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 QQntcj22373 for ; Fri, 13 Dec 2002 20:20: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 QQntcj14249; Fri, 13 Dec 2002 20:16:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQntcj28481 for mpls-outgoing; Fri, 13 Dec 2002 20:16: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 QQntcj28364 for ; Fri, 13 Dec 2002 20:15: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 QQntcj27457 for ; Fri, 13 Dec 2002 20:15: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 QQntcj05941 for ; Fri, 13 Dec 2002 20:15:05 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 QQntcj05930 for ; Fri, 13 Dec 2002 20:15:05 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBDKFZiD003874 for ; Fri, 13 Dec 2002 15:15:36 -0500 (EST) 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 PAA14399 for ; Fri, 13 Dec 2002 15:15:04 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBDKF4O21821 for mpls@uu.net; Fri, 13 Dec 2002 15:15:04 -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 QQntci28035 for ; Fri, 13 Dec 2002 20:13:22 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 QQntci21456 for ; Fri, 13 Dec 2002 20:13:09 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 QQntci04427 for ; Fri, 13 Dec 2002 20:13:09 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 QQntci04423 for ; Fri, 13 Dec 2002 20:13:08 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBDKDUQn003609; Fri, 13 Dec 2002 15:13:31 -0500 (EST) 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 PAA14211; Fri, 13 Dec 2002 15:12:59 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id PAA19838; Fri, 13 Dec 2002 15:12:59 -0500 (EST) Message-Id: <200212132012.PAA19838@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Shahram Davari cc: "'George Swallow'" , curtis@fictitious.org, mpls@UU.NET, swallow@cisco.com Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Fri, 13 Dec 2002 11:47:12 PST." <4B6D09F3B826D411A67300D0B706EFDEB03B98@nt-exch-yow.pmc-sierra.bc.ca> Date: Fri, 13 Dec 2002 15:12:59 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > Are you saying that now all LSRs (even the intermediate ones) > need to be able to generate and process MPLS-ping and keep > MPLS-ping states? With regard to TE tunnels, just the ones that are supporting tunnels. Though I will give all of my LSRs the ability to generate and process MPLS-pings. ...george ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Fri Dec 13 15:18:22 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 PAA04316 for ; Fri, 13 Dec 2002 15:18:21 -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 QQntcj05751 for ; Fri, 13 Dec 2002 20:21: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 QQntcj27295; Fri, 13 Dec 2002 20:16:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQntcj28599 for mpls-outgoing; Fri, 13 Dec 2002 20:16:42 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 QQntcj28586 for ; Fri, 13 Dec 2002 20:16: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 QQntci16293 for ; Fri, 13 Dec 2002 20:14:14 GMT Received: from mail.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc239.alcatel.be [195.207.101.239]) id QQntci00093 for ; Fri, 13 Dec 2002 20:04:41 GMT Received: from bemail05.net.alcatel.be (localhost [127.0.0.1]) by mail.alcatel.be (8.10.1/8.11.4) with ESMTP id gBDK4GU22015; Fri, 13 Dec 2002 21:04:16 +0100 (MET) Received: from alcatel.be ([138.203.67.230]) by bemail05.net.alcatel.be (Lotus Domino Release 5.0.9a) with ESMTP id 2002121321041406:4599 ; Fri, 13 Dec 2002 21:04:14 +0100 Message-ID: <3DFA3CFD.B26A5031@alcatel.be> Date: Fri, 13 Dec 2002 21:03:09 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: Optical Network Architecture (NTA - Antwerpen) X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jean Philippe Vasseur Cc: Cheng-Yin.Lee@alcatel.com, sachin laddha , mpls@UU.NET, ccamp@ops.ietf.org Subject: Re: Multi-Area TE Protocol Extensions References: <4.3.2.7.2.20021210090846.06284110@paris.cisco.com> <4.3.2.7.2.20021210123021.0382fe10@paris.cisco.com> <3DF643DF.4F8AC12C@alcatel.be> <4.3.2.7.2.20021211114607.0513d0a0@paris.cisco.com> <4.3.2.7.2.20021212173514.03e31e98@paris.cisco.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.9a |January 7, 2002) at 12/13/2002 21:04:14, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.9a |January 7, 2002) at 12/13/2002 21:04:16, Serialize complete at 12/13/2002 21:04:16 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit hi jean-philippe, see in-line... Jean Philippe Vasseur wrote: > > Hi Dimitri, > > At 23:25 12/12/2002 +0100, Dimitri.Papadimitriou@alcatel.be wrote: > >your impression is too affirmative wrt to my next reply > >(i've never said that the xro mechanisms are restricted > >to ma-te or that this i-d should be entirely dedicated > >to it) also the intention of opening a charter item > >implies imho structuring the content of proposals that > >are on the table and that may further come in, this in > >order to achieve common mechanisms in the scope of the > >ccamp wg - in whatever i-d btw as long as it reproduces > >the consensus of the wg (taking a look back at gmpls > >signalling for instance you will see that it is the > >concatenation of many individual submissions coming > >from various horizons) > > > >as said before, we have currently two methods > > We probably have more ... we can also add some methods consisting on > leaking part of the topology info into the areas, .... i referred here to the "signalling" based methods (i should have said before, sorry) hence, i think we should scope the discussion to these two here for the time being > But I do agree with you that once the CCAMP charter explicitly includes the > multi-area TE item, we will need to find a consensus and work on a single > document. me too > >on the > >table 1) constraint passing and 2) path queries, the > >first beneficiate from the fact it is the logical > >evolution from loose routing (the next step) the other > >uses signalling for querying a server, as such there > >is one fundamental question underlying the latter: > >moving features from distributed entities to the > >centralized ones for path computation purposes solves > >an intermediate problem (when a unique server is > >available) that comes back when several centralized > >systems have to interoperate > > I guess you are referring to the problem of multiple central systems > sharing the path computation requests that indeed need to be in sync. That > of course seriously increases the level of complexity but I do not think > this is required. In the case of multi-area TE, a determined ABR > (statically configured or dynamically discovered) can the THE PCS serving > the requests for the LSRs residing within a specific area. In case of > failure, a backup PCS can be used. it is not "required" but your last sentence clearly indicates it will become rapidly a "recommendation" this clearly puts limits to the current applicability of this method - see also here below - and i think it would be wise to start thinking about scoping this approach (in case). > >but also one fundamental > >protocol aspect (which is due to the methods currently > >proposed) using a signalling protocol like rsvp to > >explicitly query a server is clearly questionable (*) > > Well, I would be more than happy to discuss this aspect of course, but not > from a philosophical point of view ... when i say questionable, i don't want to enter into the arcane of protocol philosophy but the protocol consistence & evolution - imho i think this is part of our common responsibility as ietf'ers - this said take this as a technical discussion, please (no bad intentions here) > We have various options there: > (1) try to extend an existing protocol like RSVP. Note that > http://www.ietf.org/internet-drafts/draft-vasseur-mpls-computation-rsvp-03.txt > requires to specify only one new message type and a single additional > object (REQUEST-ID object). All the other objects are completely optional. > All the LSRs have already an RSVP stack and this allows to reuse all the > RSVP objects defined so far to pass the constraints to the PCS. So the idea is: > - to slightly extend an existing protocol (with one new message > type, one new object required) without impacting its scalability, this i-d describes in details the new messages, objects and their usage but i don't see any detail about how RSVP works in this case ? would you please go first by yourself into the details of what's the use of the mandatory objects in that context and their semantic wrt respect to their current use ? this would help me really to understand the rationales behind this method - the issue is as follows there is no clear explanations on why rsvp re-use is a key in enabling a path query between a client and a server, except from the fact it is already used but for resource reservation - you've said "without impacting its scalability", first you should clarify from which viewpoint since due to the above point it is probably a method that complexifies when the #pcs > 1 thus i would only consider that #pcs = 1 (in a first approach) now, if you refer to the installed and running distributed rsvp-te software on the routers and other switches from the client side it seems the case since you have to maintain a session (but do i have to call it a session in this context ?) with one pcs and even if you have several sessions (?) you would at most double or triple their number so it is clearly limited, the problem is in the other way around, where you have a factor n (at least), n being the number of nodes; if each of these nodes maintains m flows (with m>>1) well the question becomes that the dimensioning of the number of lsp's is dependent of the capabilities of the pcs (thus in addition, it seems you have introduced a new issue in network dimensioning) imho scalability with respect to the pcs (in particular wrt to rsvp usage) imho would deserve more words in this i-d in particular when running on the same device than the one(s) along the lsp. > - re use all the existing objects, this re-use is clearly what i refer to here, i clearly understand the use of the new objects but what about the , etc. what do they represent in this context ? you will see that this discussion is exactly the one that we would have in defining a new application, but where i see another point here one start to use rsvp as p2p tunnel to transport the info for such kind of applications > - not require any additional protocol running on the LSRs > (2) re invent a new protocol from scratch ... > I personally vote for the pragmatic approach (1), let see other inputs on > the list. well you have really point out the two alternatives sitting at the both end of the solution spectrum > I won't go in the philosophical aspects ... Note that IGPs/RSVP have not > been designed to carry Optical/SDH/SONET/... well let me point out here they don't carry sdh, they extend the set of bandwidth request encoding (as such no change in the orientation of resource reservation of this protocol) > infos either and I think one > could mention many other examples like this and as a matter of fact they > perfectly make the job. I personally think that if an exiting protocol can > be slightly extended (without impacting its scalability, ... ) and can > solve an actual problem, this option is preferable than trying to reinvent > a new protocol from scratch. using your words: 1) constraint-passing would be then much more pragmatic (since you don't have to implement one new message, only new objects) and this without impacting existing approaches 2) if one has to implement a new message with new semantic (outside of the scope of resource reservation even in a generic sense) then we can legitimatelly "ask" the question why not a dedicated protocol for it running over udp; and this is probably the way to go for this method use all the object encoding, errors and s.o. without being obliged to maintain backward semantic with rsvp itself this is what the ccamp wg did with lmp and i don't think this is unfeasible in this case, however i would say that this would solve only the easy part of the problem (the issue of what happens in case of multiple pcs that runs in parallel is still for me an open issue) > Again I'll be more than happy to get more feed-backs on the list. > > >- i think this should be clarified in the kompella i-d > > What would you exactly want us to clarify in the i-d ? the following paragraph says: " Once the path computation server computes the path, if the server is not along the path, the server is no longer responsible for maintaining the feasibility of the path (for one thing, the server may not even know whether the LSR established the path in the first place)." the "if the server is not along the path" is not a condition, this applies independently of the condition the lsp is along the path, this should be clarified otherwise the above paragraph requires that you have to maintain the state of the computed path and the actual lsp on abr's for instance! but this is this may be what you intend to propose ? but in this case i don't see this clearly this i-d (is my understanding right here ?) > >since this is independent from the fact that the server > >is collocated on an abr or along the lsp path - back > >to previous method using constraint passing i would > >say constraint-passing keeps the current philosophy > >of rsvp-te since based on the implicit assumption > >that each hop (in particular abr in ma-te context) are > >capable to respond to the incoming request; is the > >latter optimal, no of course; but i would say that at > >the end the "simplest solution to this complex problem > >will remain", well i think that rfc 3439 phrases this > >principle much better than i do; > > > >(*) understand this as a general remark people have > >the tendency to overload/over-generalize the features > >supported by a protocol and its applicability scope > > I am also hopping we will move forward on this discussion with the input of > Service Providers on which method(s) for inter-area TE better address their > needs. of course, the whole ietf community is kindly invited to provide comments and input ! thanks, - dimitri. > Thanks. > > Cheers, > > JP. > > >thanks, > >- dimitri. > > > >Jean Philippe Vasseur wrote: > > > > > > Hi, > > > > > > At 10:43 11/12/2002 -0500, Cheng-Yin Lee wrote: > > > >Dimitri, JP, > > > >While I think an applicability section/statement is fine, I'm not sure > > > >if a mechanism > > > >to compute inter-area TE path belong in this ID. > > > > > > This was exactly my impression. > > > > > > JP. > > > > > > >We did include applications in the first discussion of this ID and in the > > > >slides > > > >http://www.ietf.org/proceedings/02mar/slides/ccamp-6/index.html and in > > > >addressing > > > >Kireeti's suggestion to include a discussion on the impact of message > > > >size, we provided > > > >an inter-area example for illustration purposes. However, there have also > > > >been > > > >suggestions in the past to not discuss applications specifically in the > > > >draft itself. > > > >I am fine with either way. > > > > > > > >thanks > > > >cheng-yin > > > > > > > >Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > > > > jp, > > > > > > > > > > > this ID does not propose a mechanism to compute inter-area TE path > > > > > > > > > > well i would say that either none of them does it, or all of > > > > > them, more accurately route exclusions are applicable to any > > > > > mpls network where full computation of the ero is not performed > > > > > before the LSP is signaled, implying thus a "scope" for computed > > > > > path thus among other applicable to multiple areas - nevertheless > > > > > i agree that a next version of this i-d should probably include > > > > > an applicability section covering this in a bit more details (see > > > > > also section 4.1 for an example - > > > > > > > > > > this said and as for any other input or i-d provided on constraint- > > > > > passing (as well as path query, btw) lot of work is still needed to > > > > > achieve a decent first step in this effort; > > > > > > > > > > thanks, > > > > > - dimitri. > > > > > > > > > > Jean Philippe Vasseur wrote: > > > > > > > > > > > > Hi Dimitri, > > > > > > > > > > > > cc'ing CCAMP - see in line, > > > > > > > > > > > > At 17:45 10/12/2002 +0100, Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > >jp, > > > > > > > > > > > > > >in fact the below list should simply be as follows for > > > > > > >signalling-based methods: 1) constraint-passing 2) loose > > > > > > >routing and 3) path query; > > > > > > > > > > > > > >and the for constraint-passing we have a several i-d's > > > > > > >such as, > > > > > > > > > > > > > >http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclu > > de-r > > > > oute-01.txt > > > > > > > > > > > > > > > > > > > this ID does not propose a mechanism to compute inter-area TE path > > > > > > > > > > > > >constraint passing may also be extended using the crank- > > > > > > >back as listed below; the usage scenarios of these methods > > > > > > >are described in the following: > > > > > > > > > > > > > >http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea > > -te- > > > > 03.txt > > > > > > > > > > > > > >now probably it is worth spending some time in considering > > > > > > >input coming from the tewg wrt to this effort, most of the > > > > > > >input that you see listed above has been produced over the > > > > > > >past year (and more) i can't imagine stepping in the protocol > > > > > > >details without a clear consensus on what do we want to cover > > > > > > >within the ccamp wg & w/o taking into account the tewg rec's > > > > > > >(probably better to discuss this on the ccamp mailing list) > > > > > > > > > > > > Fully agree with you. Hopefully multi-area TE should be soon part > > of the > > > > > > CCAMP charter. > > > > > > > > > > > > JP. > > > > > > > > > > > > >thanks, > > > > > > >- dimitri. > > > > > > > > > > > > > >Jean Philippe Vasseur wrote: > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > At 13:53 10/12/2002 +0530, sachin laddha wrote: > > > > > > > > >Hi, > > > > > > > > >'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as > > > > > > > > >"Initial requirements are given here for protocol support of the > > > > > > > multi-area > > > > > > > > >TE methods, which include needs to support > > > > > > > > > > > > > > > > > >* path-computation-server (PCS) functionality > > [kompella, lee, > > > > > > > vasseur, > > > > > > > > >te-qos-routing], > > > > > > > > >* query functionality [query, vasseur], > > > > > > > > >* crankback functionality [crankback], > > > > > > > > > > > > > > > > > >and, optionally, > > > > > > > > > > > > > > > > > >* TE feedback functionality [feedback], and > > > > > > > > >* summary-LSA functionality [summary_lsa]." > > > > > > > > >. > > > > > > > > >I want to know whether cisco/juniper routers (standard ones) > > > > supports > > > > > > > all of > > > > > > > > >the above extension. > > > > > > > > >or if not,how many.......or Whether router is supposed to > > > > support how many > > > > > > > > >... > > > > > > > > > > > > > > > > I do not think any vendor supports all the method mentioned > > > > above, but just > > > > > > > > a subset. If you are running a network, your feed-backs on your > > > > preferred > > > > > > > > method is very welcome. > > > > > > > > > > > > > > > > JP. > > > > > > > > > > > > > > > > >Regards, > > > > > > > > >---Sachin > > > > > > > > > > > > > >-- > > > > > > >Papadimitriou Dimitri > > > > > > >E-mail : dimitri.papadimitriou@alcatel.be > > > > > > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > > > > > >E-mail : dpapadimitriou@psg.com > > > > > > >Public : http://psg.com/~dpapadimitriou/ > > > > > > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > > > > > >Phone : Work: +32 3 2408491 - Home: +32 2 3434361 > > > > > > > > > > -- > > > > > Papadimitriou Dimitri > > > > > E-mail : dimitri.papadimitriou@alcatel.be > > > > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > > > > E-mail : dpapadimitriou@psg.com > > > > > Public : http://psg.com/~dpapadimitriou/ > > > > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > > > > Phone : Work: +32 3 2408491 - Home: +32 2 3434361 > > > >-- > >Papadimitriou Dimitri > >E-mail : dimitri.papadimitriou@alcatel.be > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > >E-mail : dpapadimitriou@psg.com > >Public : http://psg.com/~dpapadimitriou/ > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > >Phone : Work: +32 3 2408491 - Home: +32 2 3434361 -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : Work: +32 3 2408491 - Home: +32 2 3434361 From owner-mpls@UU.NET Fri Dec 13 15:24: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 PAA04416 for ; Fri, 13 Dec 2002 15:24:22 -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 QQntcj20616 for ; Fri, 13 Dec 2002 20:27: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 QQntcj16118; Fri, 13 Dec 2002 20:24:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQntcj29452 for mpls-outgoing; Fri, 13 Dec 2002 20:24:30 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 QQntcj29426 for ; Fri, 13 Dec 2002 20:24:18 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 QQntcj08780 for ; Fri, 13 Dec 2002 20: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 QQntcj14439 for ; Fri, 13 Dec 2002 20:23:18 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 QQntcj14431 for ; Fri, 13 Dec 2002 20:23:17 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBDKNlp4005101 for ; Fri, 13 Dec 2002 15:23:48 -0500 (EST) 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 PAA15103 for ; Fri, 13 Dec 2002 15:23:16 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBDKNGD23812 for mpls@uu.net; Fri, 13 Dec 2002 15:23:16 -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 QQntcj29131 for ; Fri, 13 Dec 2002 20:21: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 QQntcj02996 for ; Fri, 13 Dec 2002 20:20: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 QQntcj11679 for ; Fri, 13 Dec 2002 20:20:54 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 QQntcj11667 for ; Fri, 13 Dec 2002 20:20:53 GMT Received: (qmail 5571 invoked by uid 104); 13 Dec 2002 20:20:53 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 (uvscan: v4.1.40/v4237. Clear:. Processed in 0.43809 secs); 13 Dec 2002 20:20:53 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 13 Dec 2002 20:20:52 -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 gBDKKqQ28535; Fri, 13 Dec 2002 12:20:52 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Fri, 13 Dec 2002 12:20:51 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B99@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Kireeti Kompella'" Cc: mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Fri, 13 Dec 2002 12:20:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Kireeti, Since the PLRs are in charge of deciding when to use the backup/detour, it seem that there is no other choice, but to generate MPLS-pings at PLRs (as you said it). Yours, -Shahram > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Friday, December 13, 2002 3:00 PM > To: Shahram Davari > Cc: mpls@UU.NET > Subject: RE: Last call on LSP Ping > > > Hi Shahram, > > On Fri, 13 Dec 2002, Shahram Davari wrote: > > > Are you saying that now all LSRs (even the intermediate ones) > > need to be able to generate and process MPLS-ping and keep > > MPLS-ping states? > > To be more precise, PLRs. > > Do you have an alternative suggestion? > > Note that PLRs testing detours can do so at a more leisurely pace. > > Kireeti. > From owner-mpls@UU.NET Fri Dec 13 16:01: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 QAA05173 for ; Fri, 13 Dec 2002 16:01:51 -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 QQntcm27521 for ; Fri, 13 Dec 2002 21:04:43 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 QQntcm20667; Fri, 13 Dec 2002 21:01:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQntcm06029 for mpls-outgoing; Fri, 13 Dec 2002 21:00:45 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 QQntcm06000 for ; Fri, 13 Dec 2002 21:00:42 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 QQntcl28333 for ; Fri, 13 Dec 2002 20:59: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 QQntcl17321 for ; Fri, 13 Dec 2002 20:59:42 GMT Received: from kanmx1.ca.alcatel.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: m115-138.on.tac.net [209.202.115.138] (may be forged)) id QQntcl17314 for ; Fri, 13 Dec 2002 20:59:41 GMT Received: (qmail 6838 invoked from network); 13 Dec 2002 21:05:49 -0000 Received: (ofmipd 138.120.118.71); 13 Dec 2002 21:05:27 -0000 Received: from alcatel.com ([138.120.62.58]) by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA4C4D; Fri, 13 Dec 2002 15:59:40 -0500 Date: 13 Dec 2002 15:59:28 -0500 Message-ID: <3DFA4A2F.9B3A1341@alcatel.com> From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com To: "Kireeti Kompella" Cc: mpls@UU.NET X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Last call on LSP Ping References: <200212111817.NAA44983@workhorse.fictitious.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Kireeti et al, It looks like separating the issues may be useful, for e.g. something along the line: For "ping" mode: 1) send a labeled test pkt on a p2p LSP 2) send a labeled test pkt on a p2p LSP, with PHP (no label after PHP) 3) send a labeled test pkt on a mp2p LSP (with and without ECMP) 4) send a labeled test pkt on a mp2p LSP, with PHP (with and without ECMP) 5) FRR case, etc... Similarly for "traceroute" mode. This may not be the best/correct/complete way to separate the issues, if so pls suggest other ways. But I think separating the issues may help in progressing the draft in the WG. One may find that it may not be necessary to use 127/8, or that the problem could be partitioned. Just a thought ... thanks, cheng-yin Curtis Villamizar wrote: > In message <20021211023339.K19625-100000@kummer.juniper.net>, Kireeti Kompella > writes: > > Hi Curtis, > > > > On Fri, 6 Dec 2002, Curtis Villamizar wrote: > > > > > Maybe one of the authors can join (do they really want to?) > > > > Not really :-) > > Smart move. > > > > whether they would see fit to add a sentence or deem it too obvious. > > > > Saying what? "Setting the destination IP address to something from 127/8 > > causes some to break out in a rash, but is perfectly valid"? > > I'll take that as closer to a "no its too obvious". My first choice > as well. > > If there remains insistence on the list that we justify the choice of > 127/8, the criteria would be: > > An ideal destination address would be deliverable to the local LSR > when TTL expires, regardless of where in the topology that router > was. This first requirement is so that an address on the next > MPLS-ping capable downstream LSR need not be known to get a > response. An ideal destination address would be deliverable within > an MPLS LSP but otherwise unrouteable even in networks using the > IANA designated private address space [RFC1700]. This second > requirement insures that the MPLS-ping packet is not forwarded by > IP and does not travel further than the LSR where TTL expires, or > the egress LSR. > > The address space 127/8 is explicitly chosen by IANA to be used > only to reach the local loopback device on a host or router > [RFC1812]. This address space is never routeable. For these > reasons, destination addresses are chosen from the address range > 127/8. Multipath capabilities on some routers, are based on a hash > or other algorithm applied to IP source and IP destination > addresses [RFC2991]. In order to exercise multipath, addresses > from a range of addresses must be used. > > An MPLS-ping capable LSR as an LSP egress must be able to deliver > packets exiting the LSP with an address anywhere in the range 127/8 > and a UDP payload with destination port 3503 to a local loopback > device. An MPLS-ping capable LSR as an LSP midpoint must be able > to deliver packets for which TTL expires which have an IP payload > and a destination address anywhere in the range 127/8 and a UDP > payload with destination port 3503 to a local loopback device. > > Maybe I should have suggested text in the first place. > > Now we have two questions... First do you agree with the text. > Second is do we need it. > > > Kireeti. > > Curtis From owner-mpls@UU.NET Fri Dec 13 16:06: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 QAA05304 for ; Fri, 13 Dec 2002 16:06:53 -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 QQntcm07020 for ; Fri, 13 Dec 2002 21:09: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 QQntcm01503; Fri, 13 Dec 2002 21:07:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQntcm21150 for mpls-outgoing; Fri, 13 Dec 2002 21:06: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 QQntcm21131 for ; Fri, 13 Dec 2002 21:06:28 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 QQntcm04286 for ; Fri, 13 Dec 2002 21:06: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 QQntcm00528 for ; Fri, 13 Dec 2002 21:06:18 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 QQntcm00519 for ; Fri, 13 Dec 2002 21:06:17 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Dec 2002 16:06:17 -0500 Message-ID: <1117F7D44159934FB116E36F4ABF221B0267EDAD@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'George Swallow'" Cc: mpls@UU.NET, Kireeti Kompella , "'Ping Pan'" , "'Dave Cooper'" , "'Sanjay Wadhwa'" , "'Ron Bonica'" Subject: RE: Last call on LSP Ping Date: Fri, 13 Dec 2002 16:06:09 -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 George, Here are my last call comments on the LSP Ping draft (nits intermixed with technical comments): 1) In general, there are several minor indications that the draft may not have been quite ready for last call. The draft includes many partially described features and at least one incomplete section. Some features seem not quite fully baked, even if they are fairly adequately described. TLV definitions are not described in a way that is conducive to compatibility with future versions, and there are other such indications as are reflected in comments below. However, once the issues are addressed, this specification will be very useful piece of work. 2) The "Return Subcode" field in the format "picture" (page 5) should be "Reserved" instead; no values are defined for it and it is supposed to be set to zero. The text on page 6 describing this field should also be changed to reflect the field name change. Other text should be changed to omit references to this field. The current field name presupposes a use for this field not yet (and therefore, possibly, never to be) defined. 3) At the end of the first paragraph on page 6, the parenthesized text should be changed to read "(this is currently only defined for control planes that uses RSVP-TE)." = === 4) For the Sender's handle, the text "There are no semantics associated with this handle," (page 6) should be changed to replace "associated with" with "defined for". The intention should be that the receiver is not allowed to infer meaning from the bits in this field, not that there is no meaning. With this change, the text "although the sender may find this for ..." could be removed. 5) The sentence at the top of page 7 should be changed to read - "TLVs (Type-Length-Value tuples) and sub-TLVs have the following format" (there is no separate description of sub-TLV formats). 6) The first paragraph in section 3.1 should be changed to read - ======================================================================= A Target FEC Stack is a list of sub-TLVs. The number of elements is determined as a result of the combination of TLV length, and sub-TLV length, fields. ======================================================================= 7) Immediately after the table in section 3.1 (page 7), the phrase "Other FEC Types will be defined as needed" is not reflected in IANA considerations section - which is currently empty (the draft should not have been sent for WG last call with this sections empty). 8) First paragraph in section 3.1.3 should read - "... [RSVP-TE], sections 4.6.1.1 and 4.6.2.1" - (corrected reference and moved close bracket). Similarly, the first paragraph in section 3.1.4 should read "... [RSVP-TE], sections 4.6.1.2 and 4.6.2.2". 9) In the formats specified in sections 3.1.3 and 3.1.4 (RSVP IPv4 and IPv6 Session TLVs, an entire word can be eliminated from the TLV by simply replacing the first "Must be zero" field with the LSP ID field in the last word (eliminating the last 32-bit word). 10) The document editor should use nroff blocking with format diagrams (example - format diagrams in 3.1.3, 3.1.8 and elsewhere). 11) Sub-TLV lengths are inconsistent with format diagrams in sections 3.1.5, 3.1.6, 3.1.7 and 3.1.8. If the authors intend that sub-TLVs should be contiguous, the "Must be zero" fields at the end of these diagrams should simply be omitted. If the authors intended these fields to indicate padding to nearest word boundary, then sub-TLV lengths should be "rounded up" to the nearest multiple of 4. Based on the definitions for LDP IPv4 and IPv6 Prefix sub-TLVs, it looks as if the intent was not to pad (there is no format diagram, nor a statement as to the alignment - therefore, the "Must be zero" fields would actually contain sub-TLV Type and Length information. Based on the supposition that the definition of TLV is meant to apply as well to sub-TLVs (see #4 above), valid length values for TLV value fields should be an even multiple of 4. 12) In section 3.2 the format diagram contains the fields Interface Address and Downstream Label which are not described in subsequent text. In addition, the description for Address Type is buried in a paragraph describing MTU. These fields need to be described briefly in bullets immediately following the diagram. If the descriptions would not make sense without the text that follows the diagram, then that text should precede the diagram. 13) The first sentence in the paragraph at the very bottom of page 11 should be changed to read "The notion of 'downstream router' is explained as follows:" (otherwise, it is not clear that authors are not leaving this as an exercise for the reader). This should be made clearer, because it is hard to be sure that the notion has been explained - i.e. - some return codes indicate that the receiver is (or is not) a "downstream router" (presumably from its own point of view) while the definition appears to be from the sender's point of view. 14) The delimited (===) text below is hard to understand. ======================================================================= ... Consider an LSR X. If a packet with outermost label L and TTL n>1 arrived at X on interface I, X must be able to compute which LSRs could receive the packet with TTL=n+1, and what label they would see. (It is outside the scope of this document to specify how this computation may be done.) The set of these LSRs are the downstream routers (and their corresponding labels) for X with respect to L. The case where X is the LSR originating the echo request is a special case. X needs to figure out what LSRs would receive a labelled packet with TTL=1 when X tries to send a packet to the FEC Stack that is being pinged. ========================================================================= What the first paragraph seems to say is that X determines the set of downstream LSRs as those to which it might forward an unexpired labeled packet for the FEC(s) in question. If that is what it is trying to say, it could be said in an easier to understand way. I do not understand in what way X - as the originator of the Ping - is a special case. Presumably it is the only LSR that would do this, therefore, it is "special" only in the sense that it is the only LSR to which this applies. 15) The use of the Pad TLV (defined in section 3.3) is not described in the text other than to state whether or not the Pad TLV is to be returned to the sender. Exactly how would the Pad TLV be used and why is it needed? 16) The Error code TLV should not be included in this specification if it is not going to be defined in this specification. Instead, the IANA considerations section should include requirements for management of the TLV type space associated with this specification. 17) In section 4.1, the point in randomly selecting an address from the address range 127/8 is inadequately specified in the draft and has not been resolved in mailing list discussions. The common belief at this point is that this is provided in order to provide some hope of being able to test multiple ECMP paths. The specification should either specifically address behavior required to support Ping and Trace-Route of ECMP equal cost paths, or it should not address it at all. Several suggestions have been made to date as to how the specification could handle ECMP paths; either one of them should be documented in this specification, or the specific wording should be changed to indicate that the destination address in the UDP packet should be chosen from the address range 127/8 using a mechanism not defined by this specification. 18) First sentence in section 4.3 should read "When the Reply Mode in an MPLS echo request is 2 or 3, an MPLS echo reply is constructed as a UDP packet." Alternatively, this should be a subsection, or the section heading should distinguish this from a control plane echo reply. The latter approach is probably better, since all of the paragraphs in this section apply only to the UDP reply case. I would suggest something like - "4.3 Sending an MPLS Echo Reply via UDP" 19) The second sentence, first paragraph of section 4.4 should be changed to read - ======================================================================= "... Thus, on receipt of an MPLS Echo Reply, X should parse the packet to assure that it is well-formed, then attempt to match up the Echo Reply with an Echo Request that it had previously sent, using (for example) the destination UDP port and the Sender's Handle." ======================================================================= The sender should be free to determine on its own what means it will use to match a request with a reply and can do so as long as the receiver has followed the rules. Several approaches may be used: for example, a sender may have only one outstanding echo request at a time or it may use the Sequence Number (and, possibly, Time Stamp Sent). 20) For the RSVP-TE extension, the Time Stamp Sent should be copied to the Time Stamp field in the LSP ECHO object - or there should be a field for both Send and Receive Time Stamps. Because of differences in local times likely (especially in microseconds) at two different devices in the network, the time sent is likely to be of more use than the time received. For example, the time sent may be used to determine which of several Pings sent is being responded to in the event that multiple Pings were sent with the same sequence number. Also, the Time Stamp sent can be used as a reliable way to detect changes in round-trip time for the Ping request/reply messages. 21) I do not see why [RSVP] and [RSVP-REFRESH] are listed as Normative references. In the [RSVP] case, it does not much matter because it is necessarily the case that this specification has a Normative references to [RSVP-TE] which it self has normative references to [RSVP] - though the explicit reference is redundant, especially given that this specification makes no apparent direct references to [RSVP]. However, there is no reason to include [RSVP-REFRESH] as a reference at all. 22) RFC 768 [UDP] should be listed as a Normative reference. 23) The last paragraph in section 8 (appropriately named Security Considerations) is wrong, in particular with respect to the Downstream Mapping TLV. The contents of this TLV are of a particularly useful nature to anyone wishing to deny access to the service being "Ping-ed" and should be secured against the possibility of un-trusted viewing. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Tuesday, December 03, 2002 5:52 PM > To: mpls@UU.NET > Subject: Last call on LSP Ping > > This message begins a workgroup last call on: > > Detecting MPLS Data Plane Liveness > > draft-ietf-mpls-lsp-ping-01.txt > > The last call ends on Dec 16, 2002 2400H GMT. > > George & Loa > > ====================================================================== > George Swallow Cisco Systems (978) 497-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > From owner-mpls@UU.NET Fri Dec 13 16:24:21 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 QAA05753 for ; Fri, 13 Dec 2002 16:24:21 -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 QQntcn28699 for ; Fri, 13 Dec 2002 21:27: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 QQntcn21536; Fri, 13 Dec 2002 21:23:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQntcn23537 for mpls-outgoing; Fri, 13 Dec 2002 21:23:05 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 QQntcn23485 for ; Fri, 13 Dec 2002 21:22: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 QQntcn26475 for ; Fri, 13 Dec 2002 21:22:23 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 QQntcn03560 for ; Fri, 13 Dec 2002 21:22:22 GMT Received: from kanmx1.ca.alcatel.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: m115-138.on.tac.net [209.202.115.138] (may be forged)) id QQntcn03548 for ; Fri, 13 Dec 2002 21:22:22 GMT Received: (qmail 15518 invoked from network); 13 Dec 2002 21:28:30 -0000 Received: (ofmipd 138.120.118.71); 13 Dec 2002 21:28:08 -0000 Received: from alcatel.com ([138.120.62.58]) by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA541E; Fri, 13 Dec 2002 16:22:20 -0500 Date: 13 Dec 2002 16:22:08 -0500 Message-ID: <3DFA4F80.E1D0E27A@alcatel.com> From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com To: Dimitri.Papadimitriou@alcatel.be, " Jean Philippe Vasseur" Cc: "sachin laddha" , mpls@UU.NET, ccamp@ops.ietf.org X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Multi-Area TE Protocol Extensions References: <4.3.2.7.2.20021210090846.06284110@paris.cisco.com> <4.3.2.7.2.20021210123021.0382fe10@paris.cisco.com> <3DF643DF.4F8AC12C@alcatel.be> <4.3.2.7.2.20021211114607.0513d0a0@paris.cisco.com> <4.3.2.7.2.20021212173514.03e31e98@paris.cisco.com> <3DFA3CFD.B26A5031@alcatel.be> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit JP, Dimitri, My understanding is that ITU-T SG15 architecture/requirements do allow both a "distributed" and "centralized" approach and that perhaps the PCS (btw, the Path Computation Entity is a functional element, not necessarily a device/server, hence Path Computation Entity/Component or something not denoting device may be more appropriate) approach may be more appropriate there. Both approaches may have its place in networks but perhaps SG15 may be a better place to advance the PCS/PCE approach? Just my 0.02 cents. regards cheng-yin Dimitri.Papadimitriou@alcatel.be wrote: > hi jean-philippe, > > see in-line... > > Jean Philippe Vasseur wrote: > > > > Hi Dimitri, > > > > At 23:25 12/12/2002 +0100, Dimitri.Papadimitriou@alcatel.be wrote: > > >your impression is too affirmative wrt to my next reply > > >(i've never said that the xro mechanisms are restricted > > >to ma-te or that this i-d should be entirely dedicated > > >to it) also the intention of opening a charter item > > >implies imho structuring the content of proposals that > > >are on the table and that may further come in, this in > > >order to achieve common mechanisms in the scope of the > > >ccamp wg - in whatever i-d btw as long as it reproduces > > >the consensus of the wg (taking a look back at gmpls > > >signalling for instance you will see that it is the > > >concatenation of many individual submissions coming > > >from various horizons) > > > > > >as said before, we have currently two methods > > > > We probably have more ... we can also add some methods consisting on > > leaking part of the topology info into the areas, .... > > i referred here to the "signalling" based methods (i should > have said before, sorry) hence, i think we should scope the > discussion to these two here for the time being > > > But I do agree with you that once the CCAMP charter explicitly includes the > > multi-area TE item, we will need to find a consensus and work on a single > > document. > > me too > > > >on the > > >table 1) constraint passing and 2) path queries, the > > >first beneficiate from the fact it is the logical > > >evolution from loose routing (the next step) the other > > >uses signalling for querying a server, as such there > > >is one fundamental question underlying the latter: > > >moving features from distributed entities to the > > >centralized ones for path computation purposes solves > > >an intermediate problem (when a unique server is > > >available) that comes back when several centralized > > >systems have to interoperate > > > > I guess you are referring to the problem of multiple central systems > > sharing the path computation requests that indeed need to be in sync. That > > of course seriously increases the level of complexity but I do not think > > this is required. In the case of multi-area TE, a determined ABR > > (statically configured or dynamically discovered) can the THE PCS serving > > the requests for the LSRs residing within a specific area. In case of > > failure, a backup PCS can be used. > > it is not "required" but your last sentence clearly > indicates it will become rapidly a "recommendation" > this clearly puts limits to the current applicability > of this method - see also here below - and i think it > would be wise to start thinking about scoping this > approach (in case). > > > >but also one fundamental > > >protocol aspect (which is due to the methods currently > > >proposed) using a signalling protocol like rsvp to > > >explicitly query a server is clearly questionable (*) > > > > Well, I would be more than happy to discuss this aspect of course, but not > > from a philosophical point of view ... > > when i say questionable, i don't want to enter into the > arcane of protocol philosophy but the protocol consistence > & evolution - imho i think this is part of our common > responsibility as ietf'ers - this said take this as a > technical discussion, please (no bad intentions here) > > > We have various options there: > > (1) try to extend an existing protocol like RSVP. Note that > > http://www.ietf.org/internet-drafts/draft-vasseur-mpls-computation-rsvp-03.txt > > requires to specify only one new message type and a single additional > > object (REQUEST-ID object). All the other objects are completely optional. > > All the LSRs have already an RSVP stack and this allows to reuse all the > > RSVP objects defined so far to pass the constraints to the PCS. So the idea is: > > - to slightly extend an existing protocol (with one new message > > type, one new object required) without impacting its scalability, > > this i-d describes in details the new messages, objects and > their usage but i don't see any detail about how RSVP works > in this case ? would you please go first by yourself into > the details of what's the use of the mandatory objects in > that context and their semantic wrt respect to their current > use ? this would help me really to understand the rationales > behind this method - the issue is as follows there is no > clear explanations on why rsvp re-use is a key in enabling > a path query between a client and a server, except from the > fact it is already used but for resource reservation - > > you've said "without impacting its scalability", first you > should clarify from which viewpoint since due to the above > point it is probably a method that complexifies when the > #pcs > 1 thus i would only consider that #pcs = 1 (in a > first approach) now, if you refer to the installed and > running distributed rsvp-te software on the routers and > other switches from the client side it seems the case since > you have to maintain a session (but do i have to call it a > session in this context ?) with one pcs and even if you have > several sessions (?) you would at most double or triple their > number so it is clearly limited, the problem is in the other > way around, where you have a factor n (at least), n being > the number of nodes; if each of these nodes maintains m flows > (with m>>1) well the question becomes that the dimensioning > of the number of lsp's is dependent of the capabilities of > the pcs (thus in addition, it seems you have introduced a > new issue in network dimensioning) imho scalability with > respect to the pcs (in particular wrt to rsvp usage) imho > would deserve more words in this i-d in particular when > running on the same device than the one(s) along the lsp. > > > - re use all the existing objects, > > this re-use is clearly what i refer to here, i clearly > understand the use of the new objects but what about the > , etc. what do they represent > in this context ? > > you will see that this discussion is exactly the one that > we would have in defining a new application, but where i > see another point here one start to use rsvp as p2p tunnel > to transport the info for such kind of applications > > > - not require any additional protocol running on the LSRs > > (2) re invent a new protocol from scratch ... > > I personally vote for the pragmatic approach (1), let see other inputs on > > the list. > > well you have really point out the two alternatives > sitting at the both end of the solution spectrum > > > I won't go in the philosophical aspects ... Note that IGPs/RSVP have not > > been designed to carry Optical/SDH/SONET/... > > well let me point out here they don't carry sdh, they > extend the set of bandwidth request encoding (as such > no change in the orientation of resource reservation > of this protocol) > > > infos either and I think one > > could mention many other examples like this and as a matter of fact they > > perfectly make the job. I personally think that if an exiting protocol can > > be slightly extended (without impacting its scalability, ... ) and can > > solve an actual problem, this option is preferable than trying to reinvent > > a new protocol from scratch. > > using your words: > > 1) constraint-passing would be then much more pragmatic > (since you don't have to implement one new message, only > new objects) and this without impacting existing approaches > > 2) if one has to implement a new message with new semantic > (outside of the scope of resource reservation even in a > generic sense) then we can legitimatelly "ask" the question > why not a dedicated protocol for it running over udp; > > and this is probably the way to go for this method use > all the object encoding, errors and s.o. without being > obliged to maintain backward semantic with rsvp itself > this is what the ccamp wg did with lmp and i don't think > this is unfeasible in this case, however i would say > that this would solve only the easy part of the problem > (the issue of what happens in case of multiple pcs that > runs in parallel is still for me an open issue) > > > Again I'll be more than happy to get more feed-backs on the list. > > > > >- i think this should be clarified in the kompella i-d > > > > What would you exactly want us to clarify in the i-d ? > > the following paragraph says: > " Once the path computation server computes the path, if the server is > not along the path, the server is no longer responsible for maintaining > the feasibility of the path (for one thing, the server may not even know > whether the LSR established the path in the first place)." > > the "if the server is not along the path" is not a > condition, this applies independently of the condition > the lsp is along the path, this should be clarified > otherwise the above paragraph requires that you have > to maintain the state of the computed path and the > actual lsp on abr's for instance! but this is this > may be what you intend to propose ? but in this case > i don't see this clearly this i-d (is my understanding > right here ?) > > > >since this is independent from the fact that the server > > >is collocated on an abr or along the lsp path - back > > >to previous method using constraint passing i would > > >say constraint-passing keeps the current philosophy > > >of rsvp-te since based on the implicit assumption > > >that each hop (in particular abr in ma-te context) are > > >capable to respond to the incoming request; is the > > >latter optimal, no of course; but i would say that at > > >the end the "simplest solution to this complex problem > > >will remain", well i think that rfc 3439 phrases this > > >principle much better than i do; > > > > > >(*) understand this as a general remark people have > > >the tendency to overload/over-generalize the features > > >supported by a protocol and its applicability scope > > > > I am also hopping we will move forward on this discussion with the input of > > Service Providers on which method(s) for inter-area TE better address their > > needs. > > of course, the whole ietf community is kindly invited > to provide comments and input ! > > thanks, > - dimitri. > > > Thanks. > > > > Cheers, > > > > JP. > > > > >thanks, > > >- dimitri. > > > > > >Jean Philippe Vasseur wrote: > > > > > > > > Hi, > > > > > > > > At 10:43 11/12/2002 -0500, Cheng-Yin Lee wrote: > > > > >Dimitri, JP, > > > > >While I think an applicability section/statement is fine, I'm not sure > > > > >if a mechanism > > > > >to compute inter-area TE path belong in this ID. > > > > > > > > This was exactly my impression. > > > > > > > > JP. > > > > > > > > >We did include applications in the first discussion of this ID and in the > > > > >slides > > > > >http://www.ietf.org/proceedings/02mar/slides/ccamp-6/index.html and in > > > > >addressing > > > > >Kireeti's suggestion to include a discussion on the impact of message > > > > >size, we provided > > > > >an inter-area example for illustration purposes. However, there have also > > > > >been > > > > >suggestions in the past to not discuss applications specifically in the > > > > >draft itself. > > > > >I am fine with either way. > > > > > > > > > >thanks > > > > >cheng-yin > > > > > > > > > >Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > > > > > > jp, > > > > > > > > > > > > > this ID does not propose a mechanism to compute inter-area TE path > > > > > > > > > > > > well i would say that either none of them does it, or all of > > > > > > them, more accurately route exclusions are applicable to any > > > > > > mpls network where full computation of the ero is not performed > > > > > > before the LSP is signaled, implying thus a "scope" for computed > > > > > > path thus among other applicable to multiple areas - nevertheless > > > > > > i agree that a next version of this i-d should probably include > > > > > > an applicability section covering this in a bit more details (see > > > > > > also section 4.1 for an example - > > > > > > > > > > > > this said and as for any other input or i-d provided on constraint- > > > > > > passing (as well as path query, btw) lot of work is still needed to > > > > > > achieve a decent first step in this effort; > > > > > > > > > > > > thanks, > > > > > > - dimitri. > > > > > > > > > > > > Jean Philippe Vasseur wrote: > > > > > > > > > > > > > > Hi Dimitri, > > > > > > > > > > > > > > cc'ing CCAMP - see in line, > > > > > > > > > > > > > > At 17:45 10/12/2002 +0100, Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > > >jp, > > > > > > > > > > > > > > > >in fact the below list should simply be as follows for > > > > > > > >signalling-based methods: 1) constraint-passing 2) loose > > > > > > > >routing and 3) path query; > > > > > > > > > > > > > > > >and the for constraint-passing we have a several i-d's > > > > > > > >such as, > > > > > > > > > > > > > > > >http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclu > > > de-r > > > > > oute-01.txt > > > > > > > > > > > > > > > > > > > > > > this ID does not propose a mechanism to compute inter-area TE path > > > > > > > > > > > > > > >constraint passing may also be extended using the crank- > > > > > > > >back as listed below; the usage scenarios of these methods > > > > > > > >are described in the following: > > > > > > > > > > > > > > > >http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea > > > -te- > > > > > 03.txt > > > > > > > > > > > > > > > >now probably it is worth spending some time in considering > > > > > > > >input coming from the tewg wrt to this effort, most of the > > > > > > > >input that you see listed above has been produced over the > > > > > > > >past year (and more) i can't imagine stepping in the protocol > > > > > > > >details without a clear consensus on what do we want to cover > > > > > > > >within the ccamp wg & w/o taking into account the tewg rec's > > > > > > > >(probably better to discuss this on the ccamp mailing list) > > > > > > > > > > > > > > Fully agree with you. Hopefully multi-area TE should be soon part > > > of the > > > > > > > CCAMP charter. > > > > > > > > > > > > > > JP. > > > > > > > > > > > > > > >thanks, > > > > > > > >- dimitri. > > > > > > > > > > > > > > > >Jean Philippe Vasseur wrote: > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > At 13:53 10/12/2002 +0530, sachin laddha wrote: > > > > > > > > > >Hi, > > > > > > > > > >'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as > > > > > > > > > >"Initial requirements are given here for protocol support of the > > > > > > > > multi-area > > > > > > > > > >TE methods, which include needs to support > > > > > > > > > > > > > > > > > > > >* path-computation-server (PCS) functionality > > > [kompella, lee, > > > > > > > > vasseur, > > > > > > > > > >te-qos-routing], > > > > > > > > > >* query functionality [query, vasseur], > > > > > > > > > >* crankback functionality [crankback], > > > > > > > > > > > > > > > > > > > >and, optionally, > > > > > > > > > > > > > > > > > > > >* TE feedback functionality [feedback], and > > > > > > > > > >* summary-LSA functionality [summary_lsa]." > > > > > > > > > >. > > > > > > > > > >I want to know whether cisco/juniper routers (standard ones) > > > > > supports > > > > > > > > all of > > > > > > > > > >the above extension. > > > > > > > > > >or if not,how many.......or Whether router is supposed to > > > > > support how many > > > > > > > > > >... > > > > > > > > > > > > > > > > > > I do not think any vendor supports all the method mentioned > > > > > above, but just > > > > > > > > > a subset. If you are running a network, your feed-backs on your > > > > > preferred > > > > > > > > > method is very welcome. > > > > > > > > > > > > > > > > > > JP. > > > > > > > > > > > > > > > > > > >Regards, > > > > > > > > > >---Sachin > > > > > > > > > > > > > > > >-- > > > > > > > >Papadimitriou Dimitri > > > > > > > >E-mail : dimitri.papadimitriou@alcatel.be > > > > > > > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > > > > > > >E-mail : dpapadimitriou@psg.com > > > > > > > >Public : http://psg.com/~dpapadimitriou/ > > > > > > > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > > > > > > >Phone : Work: +32 3 2408491 - Home: +32 2 3434361 > > > > > > > > > > > > -- > > > > > > Papadimitriou Dimitri > > > > > > E-mail : dimitri.papadimitriou@alcatel.be > > > > > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > > > > > E-mail : dpapadimitriou@psg.com > > > > > > Public : http://psg.com/~dpapadimitriou/ > > > > > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > > > > > Phone : Work: +32 3 2408491 - Home: +32 2 3434361 > > > > > >-- > > >Papadimitriou Dimitri > > >E-mail : dimitri.papadimitriou@alcatel.be > > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > >E-mail : dpapadimitriou@psg.com > > >Public : http://psg.com/~dpapadimitriou/ > > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > >Phone : Work: +32 3 2408491 - Home: +32 2 3434361 > > -- > Papadimitriou Dimitri > E-mail : dimitri.papadimitriou@alcatel.be > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > E-mail : dpapadimitriou@psg.com > Public : http://psg.com/~dpapadimitriou/ > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > Phone : Work: +32 3 2408491 - Home: +32 2 3434361 From owner-mpls@UU.NET Fri Dec 13 16:27: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 QAA05793 for ; Fri, 13 Dec 2002 16:27:07 -0500 (EST) 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 QQntcj06158; Fri, 13 Dec 2002 20:21:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQntcj28955 for mpls-outgoing; Fri, 13 Dec 2002 20:20:53 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 QQntcj28891 for ; Fri, 13 Dec 2002 20:20:35 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 QQntcj13692 for ; Fri, 13 Dec 2002 20:19: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 QQntcj19242 for ; Fri, 13 Dec 2002 20:19:04 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQntcj18794 for ; Fri, 13 Dec 2002 20:18:49 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Dec 2002 15:02:35 -0500 Message-ID: <1117F7D44159934FB116E36F4ABF221B0267EDAB@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'Shahram Davari'" , "'George Swallow'" , curtis@fictitious.org Cc: mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Fri, 13 Dec 2002 15:02:34 -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 Shahram, They would need to be able to process Ping requests in order to support the trace-route capability, anyway. It is not so bad a thing to add this to the list of new features required to support continuity checks for a PLR. 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: Friday, December 13, 2002 2:47 PM > To: 'George Swallow'; curtis@fictitious.org > Cc: mpls@UU.NET > Subject: RE: Last call on LSP Ping > > Are you saying that now all LSRs (even the intermediate ones) > need to be able to generate and process MPLS-ping and keep > MPLS-ping states? > > -Shahram > > > -----Original Message----- > > From: George Swallow [mailto:swallow@cisco.com] > > Sent: Friday, December 13, 2002 2:22 PM > > To: curtis@fictitious.org > > Cc: Shahram Davari; mpls@UU.NET; swallow@cisco.com > > Subject: Re: Last call on LSP Ping > > > > > > > Currently you'd have to do that from each PLR. We don't provide a > > > means to tell the ingress of the existance of a detour (except the > > > local-protect-available bit in the signaling itself which one major > > > implementation wasn't using last I checked). We also don't > > provide a > > > means to tell a specific PLR to exercise its detour and report back. > > > > > > Let's wait and hear from Kireeti or other authors whether they think > > > anything should be added or whether the intent is to require testing > > > initiated at each PLR. > > > > The PLR is responsible for the bypass. It knows what sender-template > > it used, so it can form the proper FEC for the ping. It can send a > > lsp-ping with the proper label stack. So it is the natural place to > > do this. If it fails, it should > > > > a) report to network management > > b) reset the backup in place bit > > c) look for another way of establishing a backup > > d) if successful on c) set the backup in place bit. > > > > You may want to put a hold-down on b) to avoid reporting to the > > head-end on a transient situation. > > > > I don't see what advantage you would gain by moving all this to the > > head-end. I do see a lot of complications... > > > > ...George > > > > > > ================================================================== > > George Swallow Cisco Systems (978) 497-8143 > > 250 Apollo Drive > > Chelmsford, Ma 01824 > > From owner-mpls@UU.NET Fri Dec 13 16:52:38 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 QAA06450 for ; Fri, 13 Dec 2002 16:52:38 -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 QQntcp03147 for ; Fri, 13 Dec 2002 21:55: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 QQntcp27467; Fri, 13 Dec 2002 21:52:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQntcp25460 for mpls-outgoing; Fri, 13 Dec 2002 21:52: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 QQntcp25447 for ; Fri, 13 Dec 2002 21:52:22 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 QQntcp27656 for ; Fri, 13 Dec 2002 21:52: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 QQntcp26137 for ; Fri, 13 Dec 2002 21:52:17 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 QQntcp26131 for ; Fri, 13 Dec 2002 21:52:17 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 gBDLqGS45698; Fri, 13 Dec 2002 13:52:16 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id gBDLqGu31244; Fri, 13 Dec 2002 13:52:16 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Fri, 13 Dec 2002 13:52:16 -0800 (PST) From: Kireeti Kompella To: "Gray, Eric" cc: Subject: RE: Last call on LSP Ping In-Reply-To: <1117F7D44159934FB116E36F4ABF221B0267EDAB@celox-ma1-ems1.celoxnetworks.com> Message-ID: <20021213134746.H31175-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk > 23) The last paragraph in section 8 ... ^^^ Thanks, Eric! All I need now is two counts: (a) the number of emails for this Last Call; (b) the number of individual comments/nits/fixes that were made. Loa, George, what are the current records for these? :-) Kireeti. From owner-mpls@UU.NET Fri Dec 13 17:08:21 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 RAA06947 for ; Fri, 13 Dec 2002 17:08:21 -0500 (EST) 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 QQntcg10522; Fri, 13 Dec 2002 19:31:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQntcg04626 for mpls-outgoing; Fri, 13 Dec 2002 19:31: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 QQntcg04605 for ; Fri, 13 Dec 2002 19:31: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 QQntcg14228 for ; Fri, 13 Dec 2002 19:30: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 QQntcg07759 for ; Fri, 13 Dec 2002 19:30:42 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 QQntcg07707 for ; Fri, 13 Dec 2002 19:30:40 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 gBDJUdS32383; Fri, 13 Dec 2002 11:30:39 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id gBDJUds30463; Fri, 13 Dec 2002 11:30:39 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Fri, 13 Dec 2002 11:30:39 -0800 (PST) From: Kireeti Kompella To: Curtis Villamizar cc: Subject: Re: Last call on LSP Ping In-Reply-To: <200212130414.XAA50433@workhorse.fictitious.org> Message-ID: <20021213112854.B30424-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Curtis, On Thu, 12 Dec 2002, Curtis Villamizar wrote: > In ping mode you should not know that the backup is in use. Faithfully following the data path :-) > Perhaps an error return in traceroute mode would be helpful or an > indication that the next hop is part of a detour. Agreed. Follow-up draft, if folks don't mind. Kireeti. From owner-mpls@UU.NET Fri Dec 13 19:36: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 TAA11400 for ; Fri, 13 Dec 2002 19:36:37 -0500 (EST) 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 QQntch25121; Fri, 13 Dec 2002 19:57:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQntch07638 for mpls-outgoing; Fri, 13 Dec 2002 19:56: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 QQntch07622 for ; Fri, 13 Dec 2002 19:56:48 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 QQntch01013 for ; Fri, 13 Dec 2002 19:55:56 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 QQntch13176 for ; Fri, 13 Dec 2002 19:55:55 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 QQntch13171 for ; Fri, 13 Dec 2002 19:55:55 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBDJuPOK000802 for ; Fri, 13 Dec 2002 14:56:25 -0500 (EST) 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 OAA12647 for ; Fri, 13 Dec 2002 14:55:53 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBDJtrr11889 for mpls@uu.net; Fri, 13 Dec 2002 14:55:53 -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 QQntch07126 for ; Fri, 13 Dec 2002 19:53:42 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 QQntch20636 for ; Fri, 13 Dec 2002 19:53: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 QQntch10545 for ; Fri, 13 Dec 2002 19:53:08 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 QQntch10527 for ; Fri, 13 Dec 2002 19:53:08 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 gBDJrbDf000370; Fri, 13 Dec 2002 14:53:37 -0500 (EST) Received: from tnadeau-w2k.cisco.com (rtp-vpn1-838.cisco.com [10.82.227.70]) by bucket.cisco.com (Mirapoint) with ESMTP id ACG69040; Fri, 13 Dec 2002 14:53:04 -0500 (EST) Message-Id: <5.2.0.9.2.20021213145110.09724b98@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 13 Dec 2002 14:52:58 -0500 To: Kireeti Kompella From: "Thomas D. Nadeau" Subject: RE: Last call on LSP Ping Cc: In-Reply-To: <20021213112401.Y30424-100000@kummer.juniper.net> References: <5.2.0.9.2.20021213094319.094389b0@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 11:28 AM 12/13/2002 -0800, Kireeti Kompella wrote: >Hi Tom, > >On Fri, 13 Dec 2002, Thomas D. Nadeau wrote: > > > > > It does seem plausible that RSVP-TE could signal > > backup tunnels that could black hole traffic on the data plane > > once switched on. It is possible to do this at least in the facility- > > based FRR mode, since a TE tunnel is signaled a priori (perhaps many > > of them), so one could go and test each to verify their health > > to make sure that they are really protecting once turned on. > >(I appear to have an email *stack*, LIFO) > >As Curtis mentioned, the PLR can initiate such tests. Yes, my thinking exactly. >Furthermore, >the head end can test presignaled backup LSPs (alternate tunnel >instances). Yes. I was thinking more of just letting the PLR test the detours as it constructs them. I can see how the head end can also trace the LSP instances, but I think it is more useful for the PLR to automatically do this if programmed, as it seems more scalable. > All of these are left to the implementation to provide; >perhaps after some experience, we will find that some enhancements to >LSP ping to make this work better. Agreed. --Tom "The difficult, we do immediately. The impossible takes a little longer." -- Air Force Motto From owner-mpls@UU.NET Fri Dec 13 20:28: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 UAA12462 for ; Fri, 13 Dec 2002 20:28:39 -0500 (EST) 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 QQntcy26820; Sat, 14 Dec 2002 00:02:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQntcy18753 for mpls-outgoing; Sat, 14 Dec 2002 00:02:26 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 QQntcy16844 for ; Sat, 14 Dec 2002 00:02:14 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 QQntcy18734 for ; Sat, 14 Dec 2002 00:02:07 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 QQntcy26437 for ; Sat, 14 Dec 2002 00:02:07 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 QQntcy26431 for ; Sat, 14 Dec 2002 00:02:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBE02bGh001940 for ; Fri, 13 Dec 2002 19:02:37 -0500 (EST) 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 TAA00875 for ; Fri, 13 Dec 2002 19:02:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBE025X15334 for mpls@uu.net; Fri, 13 Dec 2002 19:02:05 -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 QQntcy15530 for ; Sat, 14 Dec 2002 00:01:38 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 QQntcy26125 for ; Sat, 14 Dec 2002 00:01:15 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 QQntci23044 for ; Fri, 13 Dec 2002 20:01:09 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 PAA52612; Fri, 13 Dec 2002 15:00:57 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212132000.PAA52612@workhorse.fictitious.org> To: Kireeti Kompella cc: Curtis Villamizar , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Fri, 13 Dec 2002 11:30:39 PST." <20021213112854.B30424-100000@kummer.juniper.net> Date: Fri, 13 Dec 2002 15:00:57 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <20021213112854.B30424-100000@kummer.juniper.net>, Kireeti Kompella writes: > Hi Curtis, > > On Thu, 12 Dec 2002, Curtis Villamizar wrote: > > > In ping mode you should not know that the backup is in use. > > Faithfully following the data path :-) > > > Perhaps an error return in traceroute mode would be helpful or an > > indication that the next hop is part of a detour. > > Agreed. Follow-up draft, if folks don't mind. > > Kireeti. Kireeti, I think we're entirely in agreement. This extension, when completed would cover the few second interval when FRR was in use in the case where a link goes down and the NOC doesn't notice the 1001 alarms going off or the provider that doesn't poll SNMP, and doesn't notice all the LSPs rerouting, major traffic shifts, etc. First we'll see if those who deploy MPLS-ping find a need for it, then work on the extension. Curtis From owner-mpls@UU.NET Fri Dec 13 23:51: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 XAA16259 for ; Fri, 13 Dec 2002 23:51:57 -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 QQntdr07609 for ; Sat, 14 Dec 2002 04:54:53 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 QQntdr26105; Sat, 14 Dec 2002 04:48:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQntdr01528 for mpls-outgoing; Sat, 14 Dec 2002 04:47: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 QQntdr01513 for ; Sat, 14 Dec 2002 04:47:41 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 QQntdr08793 for ; Sat, 14 Dec 2002 04:47:17 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 QQntdr25388 for ; Sat, 14 Dec 2002 04:47:16 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 QQntdr25379 for ; Sat, 14 Dec 2002 04:47:16 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBE4lg36020215 for ; Fri, 13 Dec 2002 23:47:47 -0500 (EST) 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 XAA12002 for ; Fri, 13 Dec 2002 23:47:11 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBE4lBr02070 for mpls@uu.net; Fri, 13 Dec 2002 23:47:11 -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 QQntci26158 for ; Fri, 13 Dec 2002 20:05:44 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 QQntci20736 for ; Fri, 13 Dec 2002 20:04:15 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 QQntci25643 for ; Fri, 13 Dec 2002 20:04:12 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 QQntci25546 for ; Fri, 13 Dec 2002 20:04:10 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 gBDK4RoA002225; Fri, 13 Dec 2002 15:04:28 -0500 (EST) Received: from tnadeau-w2k.cisco.com (rtp-vpn1-838.cisco.com [10.82.227.70]) by bucket.cisco.com (Mirapoint) with ESMTP id ACG69287; Fri, 13 Dec 2002 15:03:55 -0500 (EST) Message-Id: <5.2.0.9.2.20021213145949.096fb838@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 13 Dec 2002 15:03:51 -0500 To: Shahram Davari From: "Thomas D. Nadeau" Subject: RE: Last call on LSP Ping Cc: mpls@UU.NET In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03B98@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 >Are you saying that now all LSRs (even the intermediate ones) >need to be able to generate and process MPLS-ping and keep >MPLS-ping states? I will let George speak for himself, but to me it seems clear that since the PLR is responsible for setting up the bypass that if it is also interested in testing the bypass path's liveliness, that it should be capable of generating and processing MPLS ping messages too. The only state being kept is by PLRs that wish to verify the liveliness of their backup paths. Those that do not wish to provide this sort of functionality need not keep any state or provide such functionality. --Tom >-Shahram > > > -----Original Message----- > > From: George Swallow [mailto:swallow@cisco.com] > > Sent: Friday, December 13, 2002 2:22 PM > > To: curtis@fictitious.org > > Cc: Shahram Davari; mpls@UU.NET; swallow@cisco.com > > Subject: Re: Last call on LSP Ping > > > > > > > Currently you'd have to do that from each PLR. We don't provide a > > > means to tell the ingress of the existance of a detour (except the > > > local-protect-available bit in the signaling itself which one major > > > implementation wasn't using last I checked). We also don't > > provide a > > > means to tell a specific PLR to exercise its detour and report back. > > > > > > Let's wait and hear from Kireeti or other authors whether they think > > > anything should be added or whether the intent is to require testing > > > initiated at each PLR. > > > > The PLR is responsible for the bypass. It knows what sender-template > > it used, so it can form the proper FEC for the ping. It can send a > > lsp-ping with the proper label stack. So it is the natural place to > > do this. If it fails, it should > > > > a) report to network management > > b) reset the backup in place bit > > c) look for another way of establishing a backup > > d) if successful on c) set the backup in place bit. > > > > You may want to put a hold-down on b) to avoid reporting to the > > head-end on a transient situation. > > > > I don't see what advantage you would gain by moving all this to the > > head-end. I do see a lot of complications... > > > > ...George > > > > > > ================================================================== > > George Swallow Cisco Systems (978) 497-8143 > > 250 Apollo Drive > > Chelmsford, Ma 01824 > > "The difficult, we do immediately. The impossible takes a little longer." -- Air Force Motto From owner-mpls@UU.NET Sun Dec 15 00:20:59 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 AAA18661 for ; Sun, 15 Dec 2002 00:20:59 -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 QQnthl17812 for ; Sun, 15 Dec 2002 05:23: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 QQnthl13471; Sun, 15 Dec 2002 05:21:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQnthl01382 for mpls-outgoing; Sun, 15 Dec 2002 05:20: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 QQnthl01377 for ; Sun, 15 Dec 2002 05:20:39 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 QQnthl11322 for ; Sun, 15 Dec 2002 05:20: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 QQnthl02814 for ; Sun, 15 Dec 2002 05:20:35 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f90.law14.hotmail.com [64.4.21.90]) id QQnthl02806 for ; Sun, 15 Dec 2002 05:20:34 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 14 Dec 2002 21:20:26 -0800 Received: from 64.168.21.249 by lw14fd.law14.hotmail.msn.com with HTTP; Sun, 15 Dec 2002 05:20:25 GMT X-Originating-IP: [64.168.21.249] From: "Hitesh Kulkarni" To: mpls@UU.NET Subject: need clarifications ER proc Date: Sat, 14 Dec 2002 21:20:25 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 15 Dec 2002 05:20:26.0304 (UTC) FILETIME=[ACEAAC00:01C2A3F9] Sender: owner-mpls@UU.NET Precedence: bulk All, I have few doubts on ER processing, would appreciate if anyone could clear them.. Thanks 1) When a path msg is rcvd by an LSR with ER should it first do the egress check ( on session dest ) and then take up ER object or do it the otherway.. 1.a If we do egress check first, and find that ER is not empty after er processing its an ERR.. Is there an error defined for this condition. 1.b If we do ER proc first and determine a nexthop, should we just fwd the path without doing the egress check ( This could happen with malformed ER-list)?? 2) I think i am missing something here.. Why is the strict/loose check not define for Abstract node border case? 3) Once the ER becomes empty after proc in a node that is not the egress, RFC says we MAY add new subobject.. What is the recommended bahavior. Should the path msg beyond that point go out with ER object or without ER object?? I appreciate ur help.. with regards, hkulk _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail From owner-mpls@UU.NET Sun Dec 15 08:05:09 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 IAA02979 for ; Sun, 15 Dec 2002 08:05:09 -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 QQntiq19753 for ; Sun, 15 Dec 2002 13:08:01 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 QQntiq17740; Sun, 15 Dec 2002 13:07:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQntiq00370 for mpls-outgoing; Sun, 15 Dec 2002 13:06: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 QQntiq00365 for ; Sun, 15 Dec 2002 13:06: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 QQntiq05952 for ; Sun, 15 Dec 2002 13:06:41 GMT From: neil.2.harrison@bt.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 QQntiq05350 for ; Sun, 15 Dec 2002 13:06:41 GMT Received: from cbibipnt05.hc.bt.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQntiq05342 for ; Sun, 15 Dec 2002 13:06:40 GMT Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Sun, 15 Dec 2002 13:06:51 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A35389014CFD15@i2km07-ukbr.domain1.systemhost.net> To: curtis@fictitious.org Cc: Shahram_Davari@pmc-sierra.com, dallan@nortelnetworks.com, swallow@cisco.com, mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Sun, 15 Dec 2002 13:06:36 -0000 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 Hi Curtis...please see below. regards, Neil Curtis Villamizar wrote 10 December 2002 15:52 > > NH=> Agreed, this was what I was driving at in my 2nd set > of questions that > > I posed 5 Dec, and specifically Q6 therein. I am still > waiting a response > > on all my postings.....to repeat that specific question: > > "6 In the same section......why is there an option to > reply by the RSVP > > control-plane? What scenario is this addressing that the > above (NH=> ie > > using IP only) doesn't? Further, some guidance on when to > select which > > option would be useful." > > I wouldn't mind getting rid of this. C&W (for example) has talked > about running a no-IP routing core with MPLS over it. I think this is > a very bad idea. It is speculative on my part but I think someone is > either directly driving this or it was added to head off any > objections that might arise. I thought you were one that insisted on > a means to decouple diagnostics from an IP control plane. Maybe I'm > mistaken. NH=> Yes, but this is an obvious and general requirement. Let me clarify again what the requirement is here: When traffic bearing data-plane layer networks (there are also control/management protocol bearing data-plane networks, often disjoint from the traffic's data-plane network) are specified/built correctly they should have self-contained fault handling functionality that is not dependent on: - what client layer network (or applications) they carry; - what sever layer network they are supported on (remember client layer link connections = server layer trails......please see G.805 if you don't understand this); - what signalling (or routing) protocols are used to instantiate the traffic bearing data-plane trails. This is obvious IMO (not just to me but to loads of people, though many of these don't even tune-in to this list), for without it you cannot have independent layer network evolution or control/management-plane (protocol) evolution. Further, without adherering to this principle one cannot use layer networks in a flexible manner (ie any client/server combinations....think PWE3 say in the case of MPLS, or even SDH, or even OTN). The need to decouple data-plane fault handling behaviour from specific client, server or control-plane cases is given in Y.1710 (which is based on agreed operator requirements). Some of these requirements are also given in draft-nadeau-ip-basedtool-requirements-00.txt, where requirement 'r' therein says: "r) Separation of Data and Control Plane OAM. The inherent separation of control and data planes in MPLS lends itself to being sometimes implemented independently within an MPLS LSR. For example, in a multi-slot LSR, one slot may run a control process responsible for running MPLS control protocols such as LDP and RSVP, and then programming line cards residing in other slots to forward traffic accordingly. In doing so, the switch separates out the data plane from the control plane in such as way that it is possible for the line card to be mis-programmed whilst the control card is unaware. This leads to a potential for the line card to black hole data plane traffic. This is one example of why it is important for LSRs to possess functions that allow an operator to detect data plane liveliness. Data Plane liveliness MUST use the exact same path as data." Now whilst the above does at least agree that the control-plane must not proxy for missing data-plane functionality (and its taken a while to even get this bit recognised as required), it still fudges the client/server data-plane layer network relationships. This is not a good idea for PWE3 applications say where the MPLS client can vary. Ideally one wants the *same* solution/behaviour for all client (or server) layer cases (and all control-plane cases...inc case of 'none', ie static trails). However, making an an appeal to an IP layer return route for LDP instantiated mp2p LSPs is not in the least surprising here to try and mitigate against the fault-handling complexity that mp2p constructs create. So breaking layering rules here seems unavoidable, and whilst I don't like it, it is perhaps the only way forward (I have suggested running Y.1711 CV on the p2p LSPs that must always exist above any mp2p LSP (needed to start to get rid of the merging) for initial proxied defect detection of lower layers, and then use trace-route as an ad hoc tool for the mp2p constructs, as a possible alternative approach. I know Dave Allan has recognised this as one solution (to mp2p) a long time ago, but I don't think anyone else is considering it). The RSVP return path case does not work as I tried to point out previously in the event of misdirected traffic, ie I think its reasonable to assume there is a probability close to 1 that there will be no valid RSVP return LSP from where any misdirected traffic will end up. Hence, why I said why not just use an IP return mode in all cases?.......but also wanted a clarification of why there is also a plain IP + 'router alert' IP option here (the latter of which I assume is to try and avoid picking up a server layer LSP return path?). > Implementation is greatly simplified by putting most of the fault > management smarts at the application layer. NH=> I would not put it like this. Basic fault handling behaviour (I am not talking about more complex ad hoc diagnostics tools here) should be an inherent design of the data-plane in a layer network. If it is not, one will not get the proper behaviour. Check out SDH and GMPLS....the general principles are the same (except one is not allowed mp2p constructs here, for obvious reasons). > > Lets just agree to disagree about what is a nifty hack. NH=> As one my (well known/respected) engineering colleagues who is responsible for defining our future network strategy here in BT remarked to me on seeing these words originally: "Yes, and "nifty hacks" are the bane of carrier class operations!! Tells us everything we need to know I think!" Not my words please note. From owner-mpls@UU.NET Sun Dec 15 08:09: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 IAA03005 for ; Sun, 15 Dec 2002 08:09:31 -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 QQntiq12808 for ; Sun, 15 Dec 2002 13:12:24 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 QQntiq06218; Sun, 15 Dec 2002 13:08:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQntiq00590 for mpls-outgoing; Sun, 15 Dec 2002 13:08:10 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 QQntiq00540 for ; Sun, 15 Dec 2002 13:08: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 QQntiq16628 for ; Sun, 15 Dec 2002 13:06:42 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 QQntiq05101 for ; Sun, 15 Dec 2002 13:06:42 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 QQntiq05095 for ; Sun, 15 Dec 2002 13:06:41 GMT Received: by cbibipnt08.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Sun, 15 Dec 2002 13:06:47 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A35389014CFD14@i2km07-ukbr.domain1.systemhost.net> To: curtis@fictitious.org Cc: dallan@nortelnetworks.com, mpls@UU.NET Subject: RE: draft-ietf-mpls-lsp-ping-01.txt - ECMP considerations Date: Sun, 15 Dec 2002 13:06:33 -0000 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 Hi Curtis, please see below. regards, Neil Curtis Villamizar wrote 12 December 2002 17:29 > > > DA=> I'm FAR from throwing my hands up in the air..... ;-) Just > > > trying to move > > > the mountain (and some thinking). > > > > > > If I did not make it clear, for figuring out what went wrong > > > once yoou know > > > somthing is wrong, > > NH=> This is an important point. The discussion would have > a far clearer > > basis for comment/analysis if we first identified/agreed > all the failure > > conditions we want to detect, and the consequent actions > that must be > > activated on such. Discussing nuances of ECMP and the > rights/wrongs of the > > LSP-Ping protocol without having this clear separation of > (i) detection and > > (ii) diagnostics as a bsis for discussion is not very helpful IMO. > > > > > OK. I think the following summarizes the intent. > > MPLS-ping is intended to detect forwarding faults NH=> These are not defined anywhere that I know of except in Y.1710/1711. > in an MPLS LSP > and isolate the fault to the LSR at which traffic stops flowing. NH=> Not all defects will lead to traffic stopping flowing, eg traffic being leaked out of an LSP due to unintended replication. > No attempt is made to determine that cause of the fault or diagnose > problems any further. NH=> I think LSP-Ping does actually try and give some indications of the nature of the defect, eg if the egress the pkt arrives at is a valid egress or not for a given FEC. However, no consequent actions are specified......like telling affected client layers. > Since MPLS-ping "echo request" packets are > injected no further upstream than the ingress LSR, faults at the > ingress related to classifying and directing packets and > encapsulating them for placement in the LSP are not detected. > Since the MPLS-ping "echo request" packets are extracted no further > downstream than the egress LSR, faults at the egress in > decapsulating and directing traffic further are not detected. > Persistent faults in transiting the LSP, regardless of their cause, > can be detected and isolated to one or two LSR. > > The document doesn't explicitly state what I have above but it only > talks about detection and isolation. For example: > > 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. > > If Kireeti adds this to the document we don't need to enumerate all > possible faults before getting started. I personally think it is > obvious enough that it doesn't need to be stated but it won't hurt to > add it. If this doesn't satisfy you, please explain in greater detail > what you would like to see discussed or in the document. NH=> I am not sure we can actually do much more than this in the case of mp2p (you can for p2p) due to the nature of the construct. However, some attempt should have been made to identify all the possible types of defect to at least understand if these can be detected (or the limitations) and what consequent actions should be taken (or the limitations). These are given in Y.1710 and simple solutions are given for the p2p case, and draft-nadeau-ip-basedtool-requirements-00.txt also starts to identify these too. Further, if detects are to be detected/handled consistently (between vendors/operators) then there should be deterministic behaviour of the detection devices used. This is a also a pre-cursor requirement for defining consistent SLAs (where these are required by operators/customers), as things like availability SLAs (though what this could posssibly mean in a mp2p construct beats me) and up-state QoS SLAs are dependent on having consistent defect detection/handling in the 1st place. I don't think any of this is simple (or even possible?) for mp2p constructs. From owner-mpls@UU.NET Sun Dec 15 22:55:45 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 WAA15700 for ; Sun, 15 Dec 2002 22:55:45 -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 QQntkx09940 for ; Mon, 16 Dec 2002 03:58: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 QQntkx08179; Mon, 16 Dec 2002 03:57:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQntkx27717 for mpls-outgoing; Mon, 16 Dec 2002 03:57: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 QQntkx27705 for ; Mon, 16 Dec 2002 03:57:17 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 QQntkx05908 for ; Mon, 16 Dec 2002 03:56: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 QQntkx07649 for ; Mon, 16 Dec 2002 03:56:55 GMT Received: from kanmx1.ca.alcatel.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: m115-138.on.tac.net [209.202.115.138] (may be forged)) id QQntkx07640 for ; Mon, 16 Dec 2002 03:56:55 GMT Received: (qmail 7909 invoked from network); 16 Dec 2002 04:02:57 -0000 Received: (ofmipd 138.120.118.71); 16 Dec 2002 04:02:35 -0000 Received: from alcatel.com ([138.120.250.28]) by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA3F8C; Sun, 15 Dec 2002 22:56:47 -0500 Date: 15 Dec 2002 22:44:16 -0500 Message-ID: <3DFD4C10.6D83A84C@alcatel.com> From: "Cheng-Yin Lee" To: neil.2.harrison@bt.com Cc: curtis@fictitious.org, Shahram_Davari@pmc-sierra.com, dallan@nortelnetworks.com, swallow@cisco.com, mpls@UU.NET X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Last call on LSP Ping References: <0536FC9B908BEC4597EE721BE6A35389014CFD15@i2km07-ukbr.domain1.systemhost.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Neil, > Now whilst the above does at least agree that the control-plane must not > proxy for missing data-plane functionality (and its taken a while to even > get this bit recognised as required), it still fudges the client/server > data-plane layer network relationships. This is not a good idea for PWE3 > applications say where the MPLS client can vary. Ideally one wants the > *same* solution/behaviour for all client (or server) layer cases (and all > control-plane cases...inc case of 'none', ie static trails). Is there a requirement to test the data plane liveliness from ideally the input interface of the ingress PE to the output interface of the egress PE for PWE3 applications? thanks cheng-yin neil.2.harrison@bt.com wrote: > > Hi Curtis...please see below. regards, Neil > > Curtis Villamizar wrote 10 December 2002 15:52 > > > > NH=> Agreed, this was what I was driving at in my 2nd set > > of questions that > > > I posed 5 Dec, and specifically Q6 therein. I am still > > waiting a response > > > on all my postings.....to repeat that specific question: > > > "6 In the same section......why is there an option to > > reply by the RSVP > > > control-plane? What scenario is this addressing that the > > above (NH=> ie > > > using IP only) doesn't? Further, some guidance on when to > > select which > > > option would be useful." > > > > I wouldn't mind getting rid of this. C&W (for example) has talked > > about running a no-IP routing core with MPLS over it. I think this is > > a very bad idea. It is speculative on my part but I think someone is > > either directly driving this or it was added to head off any > > objections that might arise. I thought you were one that insisted on > > a means to decouple diagnostics from an IP control plane. Maybe I'm > > mistaken. > NH=> Yes, but this is an obvious and general requirement. Let me clarify > again what the requirement is here: When traffic bearing data-plane layer > networks (there are also control/management protocol bearing data-plane > networks, often disjoint from the traffic's data-plane network) are > specified/built correctly they should have self-contained fault handling > functionality that is not dependent on: > - what client layer network (or applications) they carry; > - what sever layer network they are supported on (remember client > layer link connections = server layer trails......please see G.805 if you > don't understand this); > - what signalling (or routing) protocols are used to instantiate the > traffic bearing data-plane trails. > > This is obvious IMO (not just to me but to loads of people, though many of > these don't even tune-in to this list), for without it you cannot have > independent layer network evolution or control/management-plane (protocol) > evolution. Further, without adherering to this principle one cannot use > layer networks in a flexible manner (ie any client/server > combinations....think PWE3 say in the case of MPLS, or even SDH, or even > OTN). > > The need to decouple data-plane fault handling behaviour from specific > client, server or control-plane cases is given in Y.1710 (which is based on > agreed operator requirements). Some of these requirements are also given in > draft-nadeau-ip-basedtool-requirements-00.txt, where requirement 'r' therein > says: > "r) Separation of Data and Control Plane OAM. The inherent separation of > control and data planes in MPLS lends itself to being sometimes implemented > independently within an MPLS LSR. For example, in a multi-slot LSR, one > slot may run a control process responsible for running MPLS control > protocols such as LDP and RSVP, and then programming line cards residing in > other slots to forward traffic accordingly. In doing so, the switch > separates out the data plane from the control plane in such as way that it > is possible for the line card to be mis-programmed whilst the control card > is unaware. This leads to a potential for the line card to black hole data > plane traffic. This is one example of why it is important for LSRs to > possess functions that allow an operator to detect data plane liveliness. > Data Plane liveliness MUST use the exact same path as data." > > Now whilst the above does at least agree that the control-plane must not > proxy for missing data-plane functionality (and its taken a while to even > get this bit recognised as required), it still fudges the client/server > data-plane layer network relationships. This is not a good idea for PWE3 > applications say where the MPLS client can vary. Ideally one wants the > *same* solution/behaviour for all client (or server) layer cases (and all > control-plane cases...inc case of 'none', ie static trails). > > However, making an an appeal to an IP layer return route for LDP > instantiated mp2p LSPs is not in the least surprising here to try and > mitigate against the fault-handling complexity that mp2p constructs create. > So breaking layering rules here seems unavoidable, and whilst I don't like > it, it is perhaps the only way forward (I have suggested running Y.1711 CV > on the p2p LSPs that must always exist above any mp2p LSP (needed to start > to get rid of the merging) for initial proxied defect detection of lower > layers, and then use trace-route as an ad hoc tool for the mp2p constructs, > as a possible alternative approach. I know Dave Allan has recognised this > as one solution (to mp2p) a long time ago, but I don't think anyone else is > considering it). > > The RSVP return path case does not work as I tried to point out previously > in the event of misdirected traffic, ie I think its reasonable to assume > there is a probability close to 1 that there will be no valid RSVP return > LSP from where any misdirected traffic will end up. Hence, why I said why > not just use an IP return mode in all cases?.......but also wanted a > clarification of why there is also a plain IP + 'router alert' IP option > here (the latter of which I assume is to try and avoid picking up a server > layer LSP return path?). > > > > Implementation is greatly simplified by putting most of the fault > > management smarts at the application layer. > NH=> I would not put it like this. Basic fault handling behaviour (I am not > talking about more complex ad hoc diagnostics tools here) should be an > inherent design of the data-plane in a layer network. If it is not, one > will not get the proper behaviour. Check out SDH and GMPLS....the general > principles are the same (except one is not allowed mp2p constructs here, for > obvious reasons). > > > > Lets just agree to disagree about what is a nifty hack. > NH=> As one my (well known/respected) engineering colleagues who is > responsible for defining our future network strategy here in BT remarked to > me on seeing these words originally: > "Yes, and "nifty hacks" are the bane of carrier class operations!! Tells us > everything we need to know I think!" > Not my words please note. > From owner-mpls@UU.NET Mon Dec 16 03:49: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 DAA29137 for ; Mon, 16 Dec 2002 03:49:10 -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 QQntlr00124 for ; Mon, 16 Dec 2002 08:52: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 QQntlr28389; Mon, 16 Dec 2002 08:51:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQntlr21513 for mpls-outgoing; Mon, 16 Dec 2002 08:51:03 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 QQntlr21391 for ; Mon, 16 Dec 2002 08:50: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 QQntlr17301 for ; Mon, 16 Dec 2002 08:50:21 GMT From: neil.2.harrison@bt.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 QQntlr27855 for ; Mon, 16 Dec 2002 08:50:20 GMT Received: from cbibipnt05.hc.bt.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQntlr27846 for ; Mon, 16 Dec 2002 08:50:20 GMT Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Mon, 16 Dec 2002 08:50:34 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A35389014CFD18@i2km07-ukbr.domain1.systemhost.net> To: Cheng-Yin.Lee@alcatel.com Cc: curtis@fictitious.org, Shahram_Davari@pmc-sierra.com, dallan@nortelnetworks.com, swallow@cisco.com, mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Mon, 16 Dec 2002 08:50:13 -0000 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 Cheng-Yin....simple answer from me is 'I don't know'....others may be able to provide a more concrete answer. However, the question misses the point IMO. What we have here is a simple client/server relationship between 2 layer networks: - we have a PSN server layer technology, eg MPLS say; - we have some client layer network technology X. In architectural terms there is a client layer trail of X (between wherever its source/sink points are defined) and a server layer layer trail which is acting as a (ie one) link connection of the client layer trail between the PE devices. That is, the server layer trail has a trail termination source at one PE device, and a trail termination sink at tbe other PE device. Now, the specification and behaviour (of the traffic-bearing data-plane) of the server layer trail (all aspects, including OAM) should be independent of which client layer signal is being carried.....of course, this assumes that the server layer trail is actually capable of delivering the availability/QoS performance metrics/objectives that the client layer would expect (and this may not be possible for arbitrary client/server layer relationships, ie some make more sense than others). Further, it should also be independent of how the server layer trail was instantiated. These are the fundamental requirements for any client/server relationship....so this is not peculiar to PWE3, as it is a general architectural requirement. Putting this another way, what I am saying here is that the server layer should be able to 'look after itself' as a stand-alone entity. The same considerations apply to the client layer of course....noting that client/server relationships recurse, and can indeed be arbitrary (within the bounds of what are/are-not sensible client/server relationships). And this is why layer independence is such a fundamantal requirement. There is of course a need for communication *between* layer networks under failures, as this is vital to constrain alarms to their layer of orgin so that we don't have Ops people all all levels running around trying to work out what is happening. Note - in the general case there could be (i) many recursive client/server relationships here, and this communication has to reach the top level layer networks, (ii) the various layer networks may not be in the same operator's management domain, and (iii) the various client layer networks (and specifically their trail termination points) may be in geographically disperse locations, even different countries. The way this is normally catered for is that on server layer failure a FDI (Forward Defect Indication) is conveyed to the client layer network(s) that the affected server layer trail supported when it was working normally. Since defect detection/handling is a uni-directional function, FDI is required to be generated at the server layer trail sink termination point and (from G.805) adapted into the appropriate FDI of the affected client layer (trails). This is not something novel, it is a fundamental operator requirement, and it is how those layer networks that operators have had a large hand in defining are specified, eg PDH, SDH, OTN, ATM. Now if both the client layer and server layer are self-sufficient as I have described above then this directly answers your question, ie there is no need for anything else. The problems arise when layer networks aren't self-sufficient......be this from poor initial design, or the fact that are being used in a role that they were never designed for (ethernet is a good example of this latter point). And it is these cases that lead to architectural violations. Whether such violations are acceptable or not is for the potential user of them to decide. Some are clearly unacceptable....for example there was a requirement in a particular ATMoverMPLS ID a while back that said (paraphrased) "on near-end ATM network partition failure (ie CE->PE) inject Sonet/SDH AIS (=FDI) in the far-end ATM network partition (ie PE->CE)". I hope its obvious why this would be unacceptable behaviour for an operator (but please ask me to explain if not clear). In the case of mp2p MPLS LSPs, as I have pointed out previously these are bizarre architectural contructs. There is no concept of merging in cnls IP networks (this is clearly pkt multiplexing), nor does the concept of merging appear in the more usual p2p (or p2mp) co network topology constructs. In the case of mp2p LSPs therefore, one cannot appeal to 'normal' specifications....fault-management is obvious, but it also applies to performance specifications for availability and QoS metrics/objcetives (a moment's thought will illustrate its not obvious how one could define these). And it is for these mp2p constructs that LSP Ping is being defined as the fault management tool. In the case of p2p constructs, and specifically in the PWE3 case of XoverMPLS, then one can use the simple yet powerful techniques given in Y.1711. This is of particular significance/importance IMO for operators who may be considering MPLS as a convergence solution for all co pkt-sw technologies, eg FR/ATM/MPLS relationships. regards, Neil > -----Original Message----- > From: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com] > Sent: 16 December 2002 03:44 > To: Harrison,N,Neil,IKL2 R > Cc: curtis@fictitious.org; Shahram_Davari@pmc-sierra.com; > dallan@nortelnetworks.com; swallow@cisco.com; mpls@UU.NET > Subject: Re: Last call on LSP Ping > > > Neil, > > Now whilst the above does at least agree that the > control-plane must not > > proxy for missing data-plane functionality (and its taken a > while to even > > get this bit recognised as required), it still fudges the > client/server > > data-plane layer network relationships. This is not a good > idea for PWE3 > > applications say where the MPLS client can vary. Ideally > one wants the > > *same* solution/behaviour for all client (or server) layer > cases (and all > > control-plane cases...inc case of 'none', ie static trails). > Is there a requirement to test the data plane liveliness from ideally > the input > interface of the ingress PE to the output interface of the > egress PE for > PWE3 applications? > > thanks > cheng-yin > > neil.2.harrison@bt.com wrote: > > > > Hi Curtis...please see below. regards, Neil > > > > Curtis Villamizar wrote 10 December 2002 15:52 > > > > > > NH=> Agreed, this was what I was driving at in my 2nd set > > > of questions that > > > > I posed 5 Dec, and specifically Q6 therein. I am still > > > waiting a response > > > > on all my postings.....to repeat that specific question: > > > > "6 In the same section......why is there an option to > > > reply by the RSVP > > > > control-plane? What scenario is this addressing that the > > > above (NH=> ie > > > > using IP only) doesn't? Further, some guidance on when to > > > select which > > > > option would be useful." > > > > > > I wouldn't mind getting rid of this. C&W (for example) has talked > > > about running a no-IP routing core with MPLS over it. I > think this is > > > a very bad idea. It is speculative on my part but I > think someone is > > > either directly driving this or it was added to head off any > > > objections that might arise. I thought you were one that > insisted on > > > a means to decouple diagnostics from an IP control plane. > Maybe I'm > > > mistaken. > > NH=> Yes, but this is an obvious and general requirement. > Let me clarify > > again what the requirement is here: When traffic bearing > data-plane layer > > networks (there are also control/management protocol > bearing data-plane > > networks, often disjoint from the traffic's data-plane network) are > > specified/built correctly they should have self-contained > fault handling > > functionality that is not dependent on: > > - what client layer network (or applications) they carry; > > - what sever layer network they are supported on > (remember client > > layer link connections = server layer trails......please > see G.805 if you > > don't understand this); > > - what signalling (or routing) protocols are used to > instantiate the > > traffic bearing data-plane trails. > > > > This is obvious IMO (not just to me but to loads of people, > though many of > > these don't even tune-in to this list), for without it you > cannot have > > independent layer network evolution or > control/management-plane (protocol) > > evolution. Further, without adherering to this principle > one cannot use > > layer networks in a flexible manner (ie any client/server > > combinations....think PWE3 say in the case of MPLS, or even > SDH, or even > > OTN). > > > > The need to decouple data-plane fault handling behaviour > from specific > > client, server or control-plane cases is given in Y.1710 > (which is based on > > agreed operator requirements). Some of these requirements > are also given in > > draft-nadeau-ip-basedtool-requirements-00.txt, where > requirement 'r' therein > > says: > > "r) Separation of Data and Control Plane OAM. The inherent > separation of > > control and data planes in MPLS lends itself to being > sometimes implemented > > independently within an MPLS LSR. For example, in a > multi-slot LSR, one > > slot may run a control process responsible for running MPLS control > > protocols such as LDP and RSVP, and then programming line > cards residing in > > other slots to forward traffic accordingly. In doing so, the switch > > separates out the data plane from the control plane in such > as way that it > > is possible for the line card to be mis-programmed whilst > the control card > > is unaware. This leads to a potential for the line card to > black hole data > > plane traffic. This is one example of why it is important > for LSRs to > > possess functions that allow an operator to detect data > plane liveliness. > > Data Plane liveliness MUST use the exact same path as data." > > > > Now whilst the above does at least agree that the > control-plane must not > > proxy for missing data-plane functionality (and its taken a > while to even > > get this bit recognised as required), it still fudges the > client/server > > data-plane layer network relationships. This is not a good > idea for PWE3 > > applications say where the MPLS client can vary. Ideally > one wants the > > *same* solution/behaviour for all client (or server) layer > cases (and all > > control-plane cases...inc case of 'none', ie static trails). > > > > However, making an an appeal to an IP layer return route for LDP > > instantiated mp2p LSPs is not in the least surprising here > to try and > > mitigate against the fault-handling complexity that mp2p > constructs create. > > So breaking layering rules here seems unavoidable, and > whilst I don't like > > it, it is perhaps the only way forward (I have suggested > running Y.1711 CV > > on the p2p LSPs that must always exist above any mp2p LSP > (needed to start > > to get rid of the merging) for initial proxied defect > detection of lower > > layers, and then use trace-route as an ad hoc tool for the > mp2p constructs, > > as a possible alternative approach. I know Dave Allan has > recognised this > > as one solution (to mp2p) a long time ago, but I don't > think anyone else is > > considering it). > > > > The RSVP return path case does not work as I tried to point > out previously > > in the event of misdirected traffic, ie I think its > reasonable to assume > > there is a probability close to 1 that there will be no > valid RSVP return > > LSP from where any misdirected traffic will end up. Hence, > why I said why > > not just use an IP return mode in all cases?.......but also wanted a > > clarification of why there is also a plain IP + 'router > alert' IP option > > here (the latter of which I assume is to try and avoid > picking up a server > > layer LSP return path?). > > > > > > > Implementation is greatly simplified by putting most of the fault > > > management smarts at the application layer. > > NH=> I would not put it like this. Basic fault handling > behaviour (I am not > > talking about more complex ad hoc diagnostics tools here) > should be an > > inherent design of the data-plane in a layer network. If > it is not, one > > will not get the proper behaviour. Check out SDH and > GMPLS....the general > > principles are the same (except one is not allowed mp2p > constructs here, for > > obvious reasons). > > > > > > Lets just agree to disagree about what is a nifty hack. > > NH=> As one my (well known/respected) engineering colleagues who is > > responsible for defining our future network strategy here > in BT remarked to > > me on seeing these words originally: > > "Yes, and "nifty hacks" are the bane of carrier class > operations!! Tells us > > everything we need to know I think!" > > Not my words please note. > > > From owner-mpls@UU.NET Mon Dec 16 10:38: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 KAA08359 for ; Mon, 16 Dec 2002 10:38:58 -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 QQntms07086 for ; Mon, 16 Dec 2002 15:41:54 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 QQntms04949; Mon, 16 Dec 2002 15:40:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQntms01652 for mpls-outgoing; Mon, 16 Dec 2002 15:40: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 QQntms01640 for ; Mon, 16 Dec 2002 15:40:17 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 QQntms21771 for ; Mon, 16 Dec 2002 15:38:59 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 QQntms25184 for ; Mon, 16 Dec 2002 15:38:57 GMT Received: from zcars04e.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQntms19945 for ; Mon, 16 Dec 2002 15:37:14 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 gBGFahH13303 for ; Mon, 16 Dec 2002 10:36:43 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Dec 2002 10:36:44 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3405BF1927@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: mpls@UU.NET Subject: Text for Management Overview Document Date: Mon, 16 Dec 2002 10:36:41 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk hi In the MPLS MIB meeting in Atlanta, I promised to provide some text for the management overview document to help demystify the MIBs for general applications trying to discover and manage LSPs. There are still a few aspects I'm not 100% sure of, so I suspect some cleanup of the text will be required. --------- N. LSP Discovery and Management There are three different types of LSPs in MPLS - Traffic Engineering Tunnels, LDP and single hop service LSPs. Each of these will be discovered and managed somewhat differently. N.1. Traffic Engineering LSPs Traffic engineering LSPs are frequently explicitly routed and tend to be fairly persistent so can therefore be managed using techniques similar to that of connection oriented systems. These links can be discovered by reading in the interface table and matching against entries with an ifType of mplsTunnel(150). Under normal operation, ifConnectorPresent will always have a value of 'true'. As the operational status of these links is service affecting, ifLinkUpDownTrapEnable should be changed from its default value of 'false' to be 'true'. Additional information about this type of LSP can be found in the MPLS LSR MIB and the MPLS Traffic Engineering MIB. N.2. Label Distribution Protocol (LDP) LSPs LDP LSPs are implicitly routed LSPs and therefore most closely resembles traditional routing protocols, but, unlike protocols like BGP, the components of the LSP are found in the interfaces table. Both active and redundant links can be discovered by reading in the interface table and matching against entries with an ifType of mpls (166). A value of 'true' for ifConnectorPresent indicates that a link is active. Given the redundancy of links as well as the potential for non-service affecting changes in the operational status of component links, it does not really make sense to monitor these interfaces for linkDown notifications, so ifLinkUpDownTrapEnable has a default value of disabled for this type of interface. Additional information about this type of LSP can be found in the MPLS LSR MIB and the MPLS LDP MIB. N.3. Single Hop Service LSPs At the service level, there is a third type of LSPs in single hop service LSPs (e.g. 2547 BGP, or extended LDP discovery). It is not a peer layer to TE and LDP, but an overlay. This type of LSP shows up in the interface table as interfaces with ifType of mplsTunnel(150) layered over interfaces with ifType of mpls(166). The ifStack table will show the layering relationship between the LSPs. Additional information about this type of LSP can be found in the MPLS LSR MIB, the MPLS LDP MIB and the MPLS TE MIB. ----- Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada From owner-mpls@UU.NET Mon Dec 16 11:47:08 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 LAA10502 for ; Mon, 16 Dec 2002 11:47:08 -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 QQntmx17704 for ; Mon, 16 Dec 2002 16:49: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 QQntmx09544; Mon, 16 Dec 2002 16:45:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQntmw25176 for mpls-outgoing; Mon, 16 Dec 2002 16:44:57 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 QQntmw25171 for ; Mon, 16 Dec 2002 16:44:48 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 QQntmw07177 for ; Mon, 16 Dec 2002 16:42: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 QQntmw22905 for ; Mon, 16 Dec 2002 16:42:34 GMT Received: from mailg.telia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailg.telia.com [194.22.194.26]) id QQntmw22889 for ; Mon, 16 Dec 2002 16:42:33 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by mailg.telia.com (8.12.5/8.12.5) with ESMTP id gBGGgMeQ015147; Mon, 16 Dec 2002 17:42:26 +0100 (CET) X-Original-Recipient: mpls@UU.NET Received: from pi.se (h70n2fls31o888.telia.com [213.64.120.70]) by d1o888.telia.com (8.10.2/8.10.1) with ESMTP id gBGGgM229009; Mon, 16 Dec 2002 17:42:22 +0100 (CET) Message-ID: <3DFE024D.8090503@pi.se> Date: Mon, 16 Dec 2002 17:41:49 +0100 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: George Swallow , Scott Bradner Subject: draft-rosen-mpls-in-ip-or-gre-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 All, the draft draft-rosen-mpls-in-ip-or-gre-00.txt was presented in Atlanta, the reception was positive, and there has been no discussion after that on the mailing list. Based on prior response to the mailing list, the response at the Atlanta meeting and the lack of response after the meeting, it is the wg chairs intention to make this draft a wg document. Please comment before January 7th. Loa and George -- Loa Andersson Mobile +46 739 81 21 64 Email loa@pi.se From owner-mpls@UU.NET Mon Dec 16 11:50: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 LAA10603 for ; Mon, 16 Dec 2002 11:50:34 -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 QQntmx23877 for ; Mon, 16 Dec 2002 16:53: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 QQntmw06446; Mon, 16 Dec 2002 16:44:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQntmw25088 for mpls-outgoing; Mon, 16 Dec 2002 16:43: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 QQntmw25073 for ; Mon, 16 Dec 2002 16:43: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 QQntmw20081 for ; Mon, 16 Dec 2002 16:42: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 QQntmw05736 for ; Mon, 16 Dec 2002 16:42:59 GMT Received: from auemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail2.lucent.com [192.11.223.163]) id QQntmw05712 for ; Mon, 16 Dec 2002 16:42:58 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gBGGgug23898 for ; Mon, 16 Dec 2002 11:42:56 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Dec 2002 17:42:55 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550A0D@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Thomas D. Nadeau" Cc: "Mpls (E-mail)" Subject: RE: review of draft-ietf-mpls-te-mib-09.txt Date: Mon, 16 Dec 2002 17:42:54 +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 Inline > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: vrijdag 13 december 2002 16:19 > To: Wijnen, Bert (Bert) > Cc: Mpls (E-mail) > Subject: RE: review of draft-ietf-mpls-te-mib-09.txt > > > At 02:49 PM 12/13/2002 +0100, Wijnen, Bert (Bert) wrote: > >Inline > > > > > -----Original Message----- > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > Sent: maandag 9 december 2002 17:33 > > > To: Wijnen, Bert (Bert) > > > Cc: Mpls (E-mail) > > > Subject: Re: review of draft-ietf-mpls-te-mib-09.txt > > > > .. snip .. > >Hope this helps. > > > >For the RowStatus, Good examples are again in for example rfc3289 > > DESCRIPTION > > "The status of this conceptual row. All writable objects in this > > row may be modified at any time." > >But then I see that in many cases you do NOT allow changes while the > >row is active, so then it could be something aka: > > > > DESCRIPTION > > "The status of this conceptual row. None of the writable objects > > in this row may be modified when this row is 'active'." > > > >Or if some can and some otehrs cannot, then for example something like > > DESCRIPTION > > "The status of this conceptual row. Writable objects a and b > > in this row may be modified at any time, but other wrietable > > objects in this row may not be modified when this row is 'active'." > > > >Now, be carefull, because when objects are not allowed to be modified when > >the row is 'active', and when you specify (in MODULE COMPLIANCE) that > >one only has to support createAndGo for the WRITE-SYNTAX, then people > >cannot (in such an implementation) set the row to notInService, and > >so that then means that changes to the row can only be made by > >deleting (destroy) and recreating the rows. > > > >Does this help? > > Yes. I think that any object in the row may be modified > (if the implementation supports it) only once the row is taken out > of service. That sounds confusing to me, cause... is "ou of service" the same as putting a row into notInService? I believe in many cases you have made MODULE-COMPLIANCEs that do not require support for that. > This may require TE parameters to be re-signaled priori > to the tunnelEntry returning to the operational state; however. > Is something that describes that reasonable? > See above. Not sure I understand what you are saying here. > > >Hope I was clear on that. If not, let me know and I can propose > >exact text and TCs to be specified and used. > > In general, I would appreciate it if you would propose > wherever you can. I think that way we can get to satisfying your > comments more quickly. > But based on the example in RFC3289 you shoudl be able to come up with the text no? I believe the FTN MIB has it close to that already. > >Also... you have the index (indices) included too. I understand you > >want to do that... maybe you want to mark them with an asterisk or such > >and then explain they are index/indices and so that they are not > >separate varBinds in the SET PDU but that they make up the > >index part of each object in the varBinds in the SET PDU. > >Or some such. > > Isn't it implied that the indexes are required as part of > the SET PDU when doing createAndGo style row creation? > I think it is pretty common knowledge that by not sending > down the indexes (and other required objects as stated in > DESCRIPTION) that the creation will fail. I didn't > realize that we needed to be specific on this (which seems > redundant). > The INDEX objects are "not-accessible. So those objects do NOT get send. Lost of people have trouble with that. It is probably caused by the fact that in old SMIv1 they were accessible, and when someone has an old SMIv1 MIB that has been converted to SMIv2, then we allow INDEX objects to be still accessible. So... it is not easy for people to understand what you mean. Better be clear and explicit (or so I think). > > > >- I ownder if mplsTunnelNotiMaxRate would be better named > > > > mplsTunnelNotiInterval > > > > May want to add a UNITS clause to this object anyway > > > > and why is it not named mplsTunnerNotificationInterval? > > > > > > Looks like a typo. > > > Mmm.. a typo he? Oh well... whatever. > > > >- mplsTunnelIndexNext > > > > well, same comment as to all the mplsXxxNext objects in the > > > > other MIB modules. > > > > But this one has even another strange thing, namely it is > > > > a Interger32 (as opposed to a Unsigned32) and it has a pretty > > > > limited range and for all I can tell for no good reason. > > > > In fact I see no reason for a upper limit. > > > > > > It is supposed to match the indexing of the tunnel table. > > > I do not understand your answer. > > > >- mplsTunnelEntry > > > > Why is there a reference to RFC1700 ??? That RFC has been > > > > obsoleted anyway... > > > >- Can someone explain to me why you use the complex indexing > > > > scheme for the mplsTunnelTable, namely: > > > > INDEX { > > > > mplsTunnelIndexIndex, > > > > mplsTunnelInstance, > > > > mplsTunnelIngressLSRId, > > > > mplsTunnelEgressLSRId > > > > } > > > > > > > > - first, I do not understand why it the 1st one is named > > > > mplsTunnelIndexIndex instead of just mplsTunnelIndex > > > > > > Compiler complained because the type is MplsTunnelIndex. > > > It gave onlyh a warning I assume, this is to alert you to make sure you did things correct. > > > > - 2nd, mplsTunnelIndexIndex claims to "uniquely" identify a row > > > > so then no more index objects seem needed > > > > - but mplsTunnelInstance seems to also "uniquely" identify a row?? > > > > - and then there are yet more index objects. > > > > - mplsTunnelIngresLSRId, description talks about "this value". > > > > but the index object does not really have a value. It is part > > > > of the OID that identifies instances in the table. > > > > Why do I not understand this indexing scheme? > > > > > > We went over this during the MIB meeting. This is basically > > > just the RSVP-TE indexing required. > > > That is not a proper answer. I still do not understand, I believe Marcus was asking about it too. Pls repeat for me what we discussed/decided at the MIB meeting. ANd probably if that explains it, some oif that text should go into the document as MIB comments or in DESCRIPTION clauses. > > > > I think it would be good to include in the DESCRIPTION clause of > > > > either the mplsTunnleEntry or of the indices a very good explanation > > > > as to how the indexing works here. > > > > > > Yes. We agreed to improve the description as an action > > > from the MIB meeting. > > > OK, good. > >OK, looking forward to that, hopefully I then understand. > >Is it just me who does not understand? I doubt it in fact. > > No, the indexes have fairly thin descriptions right now > and can be improved. > Looking forward to that. > > > >- I have trouble with the use of DisplaySTring (as mentioned half a year > > > > ago). These days we want people to use UTF8 based strings if the strings > > > > are intended for human use. So either SnmpAdminString or some other > > > > UTF8-based string. Several TCs have been defined to > > > replace DisplayString > > > > > > Yes, will use SnmpAdminString. > > > Good > > > >- I wonder why the mplsTunnelName is ever to be equal to ifName. > > > > The link between an entry in the mplsTunnelTable and the ifTable is > > > > made by the mplsIfTunnelIndex which is the better way indeed to make > > > > the link. > > > > > > The idea is that in cases where the tunnel is an ifEntry too, > > > this makes sense so they are associated. > > > > > > >And so when people do SET on ifName or on mplsTunnelName, then > >the agent needs to make sure they stay in sync? > >What if in one SET request (I will admit it is kind of stupid) one > >send a SET for ifName of "abcd" and a SET for mplsTunnelName of "efgh" > >I see all sorts of potential problems with this. > >And is it the MIB who wants to presrcibe this? > >I know thay ifName was meant for operators to use. So you are forcing > >them to use same name for mplsTunnel, why can they not use > > > > ifName : Interface1 for MPLS > > mplsTunnelName : mpls Tunnel to Linschoten (this is where I live ;-)) > > > >Oh well... I won't loose sleep over it.... I just wonder about > >the complexities it may cause (for in mu view no good reason) > > I think it is common practice in the implementations > I know of > to keep these the same. The reason being that the ifType is > for an mplsTunnel, so the entities are really one in the same (just > the tunnel entry extends the ifIndex a bit). I think that it > is a reasonable > requirement that the agent SHOULD keep these values consistent. > If it cannot, then let it be, but I think we should indicate that the > best practice is to do so. > I will leave this to teh WG > > > >- It seems to me that mplsIfTunnelDescription could have a DEFVAL > > > > of the empty (zero lenght) string > > > >- It seems to me that mplsTunnelIsIf and mplsTunnelIfIndex are overlapping. > > > > A value of zero in the mplsTunnelIfIndex means that this tunnel does > > > > not correspond to an interface. A nonzero value means that it does > > > > correspond to an interface. So why is mplsTunnelIsIf needed? So that > > > > people can have conflicting stuff that needs to be chacked and all that? > > > > > > The idea is that you can quickly determine the type of > > > tunnel. I suppose that we could eliminate this object and just > > > state that if ifIndex = 0 that it is NOT an ifIndex. > > > > >Having 2 objects to represnt kind of the same thing always > >adds complexity in terms of "what to do when they conflict" > >or "how to make sure they stay in sync". > >Is it just me who sees these type of concerns? > > I obviously agree that redundant objects should be > removed. However, after working on this document for 3 years > it is hard to see things like this sometimes. *) In any > event, I think > this was a comment made during the MIB review meeting, and > I believe we agreed to remove the object. > Good > > > >- mplsTunnelSessionAttributes > > > > you may want to check the formatting in the DESCRIPTION clause > > > >- mplsTunnelOwner is a read-only object and yet the description clause > > > > talks about that it cannot be modified when RowStatus is active. > > > > That seems redundant text. A read-only object can NEVER be changed > > > > > > Again, this should be the same as that in the TC that we > > > discussed (the agent sets this value). > > > > >Right... but pls remove the piece of text that says that it cannot > >be changed when row is active, because that piece if nonsense and > >confusing. > > Gotcha. > Good > > > > >- I see mplsTunnelHopTableIndex to be read-create while > > > > mplsTunnelARHopTableIndex and mplsTunnelCHopTableIndex are read-only > > > > Is that not strange? > > > > > > Nope. The actual route hop table is what is spit out > > > by the CSPF computation; not operator programmable. > > > > >Got you. Maybe say something about how it gets filled in, > >and then people (like myself) might not need to wonder as much > >Not everyone is an MPLS expert on all these things (think about > >the (generic) apps developers we talked about in Atlanta. They > >want to quickly understand it too. > > Okay, I will try to improve. > Thanks > > > >- I do not understand mplsTunnelPrimaryInstance, but that is > > > > probably linked to me not understanding the indexing scheme. > > > >- mplsTunnelPathChanges > > > > s/paths has changed/path has changed/ or > > > > s/path has changed/paths have changed/ ?? > > > >- mplsTunnelTotalUptime > > > > so is this an aggregate value of multiple entries in this table? > > > > > > This is the up time of all LSP instances of the tunnel. > > > > >That is not a clear answer to my question > >My interpreation of your answer is that the answer is: YES > > Is this more clear: This is the uptime of all instances of > the tunnel since its creation? Perhaps an example might help. > If the tunnel head creates an LSP at time T and it runs until > T+n. At time T+n+2 a new LSP is signaled and lasts > until T+n+5. This object would then be counted > as (T+n) + ((T+n+5) - (T+n+2)). > That helps. And so my question is, would the same value occur in multiple entries. Again, I think the answer is YES, but you keep giving other answers. > > > > and if so of how many? Is that of all entries with the same > > > > mplsTunnelIndexIndex, or what? > > > > > > Yes, the same group of tunnel instances (the same primary > > > tunnel index). > > > > >First of all, it would be good to make that very clear in the > >DESCRIPTION clauses. One can kind of conclude that, but it is > >a very strange thing to see in a MIB table, so make it clear > >that it is intentional. > > > >But it seems BAD to me. > > Why? During the meeting we had concluded that this was > not a bad idea -- that it was pretty nice in fact. The only suggestion > that came out of the meeting was that we make the indexing > style/interpretation mandatory so that there was no confusion > about grouping of tunnel heads with their instances. > I guess I am still confused then. I will await the new rev to see if the DESCRIPTION clauses help me understand. > > > > > And then... if there are 4 entries aggregated, do all 4 entries then > > > > have the same value? > > > > And what is the upTime of each entry? > > > > > > mplsTunnelPrimaryTimeUp shows the time of the primary > > > instance that this tunnel > > > > > > mplsTunnelTotalUpTime is the aggregate time of all > > > instances of this tunnel (head). > > > > > > mplsTunnelInstanceUpTime is the time this instance has > > > been up. > > > > >So you are again not answering my first question: do all 4 > >entries have the same value? And if so that looks BAD to me. > >But maybe it is just me. Any other opinions? > > They have the same value on the tunnelEntry with > instance = 0 (i.e.: the tunnel head). On other instances of > the tunnel, primaryTimeUp/TotalUpTime might be set to > that of the head entry (if possible). TunnelInstanceUpTime > will be different if more than one LSP has been used for > the tunnel head. If no instances exist, only the head does, > and so those variables will only exist on the head entry. > I guess I should give up. If no one in the WG sees this as a problem or being bad, then I will accept it is just me. > > > > I am confused here as to what the purpose of this object > > > is and how > > > > it is computed. Under what circumstances would it "not be > > > available"? > > > > > > It might not be available if no instances exist for > > > the tunnel. I suppose it might be simpler to just remove this > > > text, but the thinking was that we specified an initial value > > > for when no tunnel instances (other than 0) existed. > > > > >Or add the explanation as to when the condition can occur. > >In general, whenever a independent (that is someone who was > >not involved in the devlopment of the protocol and/or the MIB) > >reviewer has a question in the form of "how does that work?" or > >"Do I understand this and that (in)correctly?", then that often > >indicates that it is a good idea to add explanatory text in > >some of the DESCRIPTION clauses. So that not every new reader > >needs to go to the mailing lists to ask the same questions > > Agreed. On the other hand, it is also a requirement in my > mind that independents as you call them, read the protocol > specifications to understand what they are going to manage > using the MIBs. I agree with you in this case, but > in general, I think that people using the MIBs should be > up to speed with how the protocol works so that when the > MIB refers to a term like "tunnel head" that the MIB not > need to define its meaning. The MIB should not be a tutorial > on how the protocol works that it is managing. > Correct, but once should also not assume that people writing management apps and people using the MIB modules will be as intimate with the protocols as you are. > --Tom > Bert From owner-mpls@UU.NET Mon Dec 16 12:38:46 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 MAA11713 for ; Mon, 16 Dec 2002 12:38: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 QQntna26526 for ; Mon, 16 Dec 2002 17:41:39 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 QQntna18443; Mon, 16 Dec 2002 17:37:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQntna18331 for mpls-outgoing; Mon, 16 Dec 2002 17:37: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 QQntna18318 for ; Mon, 16 Dec 2002 17:36:54 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 QQntna27281 for ; Mon, 16 Dec 2002 17:35:27 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 QQntna16973 for ; Mon, 16 Dec 2002 17:35:27 GMT Received: from ns2.vivacenetworks.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [64.221.212.135]) id QQntna16969 for ; Mon, 16 Dec 2002 17:35:26 GMT Received: from AMALIS.vivacenetworks.com ([10.120.0.2]) by vivacenetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 16 Dec 2002 09:35:18 -0800 Message-Id: <5.1.0.14.2.20021216123402.0e98a110@mail.attbi.com> X-Sender: vivacenet\amalis@po1.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 16 Dec 2002 12:35:11 -0500 To: Loa Andersson From: "Andrew G. Malis" Subject: Re: draft-rosen-mpls-in-ip-or-gre-00.txt Cc: mpls wg , George Swallow , Scott Bradner In-Reply-To: <3DFE024D.8090503@pi.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 16 Dec 2002 17:35:19.0447 (UTC) FILETIME=[80E41A70:01C2A529] Sender: owner-mpls@UU.NET Precedence: bulk I support this decision. Andy ------- At 12/16/2002 05:41 PM +0100, Loa Andersson wrote: >All, > >the draft draft-rosen-mpls-in-ip-or-gre-00.txt was presented in Atlanta, >the reception was positive, and there has been no discussion after that >on the mailing list. > >Based on prior response to the mailing list, the response at the >Atlanta meeting and the lack of response after the meeting, it is >the wg chairs intention to make this draft a wg document. > >Please comment before January 7th. > >Loa and George From owner-mpls@UU.NET Mon Dec 16 13:19: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 NAA12961 for ; Mon, 16 Dec 2002 13:19:00 -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 QQntnd29573 for ; Mon, 16 Dec 2002 18:21: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 QQntnd25263; Mon, 16 Dec 2002 18:19:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQntnd10137 for mpls-outgoing; Mon, 16 Dec 2002 18:19:02 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 QQntnd10132 for ; Mon, 16 Dec 2002 18:19:01 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 QQntnd01114 for ; Mon, 16 Dec 2002 18:18: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 QQntnd26390 for ; Mon, 16 Dec 2002 18:18:41 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 QQntnd26382 for ; Mon, 16 Dec 2002 18:18:40 GMT Received: from zircon.juniper.net (zircon.juniper.net [172.17.28.113]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gBGIIeS96024; Mon, 16 Dec 2002 10:18:40 -0800 (PST) (envelope-from arthi@juniper.net) Date: Mon, 16 Dec 2002 10:18:40 -0800 (PST) From: Arthi Ayyangar To: Kireeti Kompella cc: Subject: LSP Ping Questions Message-ID: <20021216100718.M85049-100000@zircon.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have some questions regarding the traceroute mode. 1) In the Downstream Mapping, there is a field 'Downstream IPv4 Router ID' that is basically the router ID of the nexthop node, of a valid recipient of an MPLS echo request. It is assumed that every node knows what the nexthop 'router ID' for an incoming label is. Is this always true? Wouldn't it be enough to fill in just the interface address if the interface is numbered? 2) In section 4.2, it says "If the echo request contains a Downstream Mapping TLV, L MUST further check whether its Router ID matches one of the Downstream IPv4 Router IDs; and if so, whether the given Downstream Label is in fact the ^^^^^^^^^^^^^^^^^^^^^^^^^ label that L sent as its mapping for the FEC...." From this it seems that we are only verifying the contents of the TLV (Downstream Label). Don't we care about the actual incoming label that the echo request arrived with ? Thanks, -arthi From owner-mpls@UU.NET Mon Dec 16 13:33:23 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 NAA13483 for ; Mon, 16 Dec 2002 13:33:22 -0500 (EST) 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 QQntmx13535; Mon, 16 Dec 2002 16:47:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQntmx25758 for mpls-outgoing; Mon, 16 Dec 2002 16:47: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 QQntmx25686 for ; Mon, 16 Dec 2002 16:46: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 QQntmx27520 for ; Mon, 16 Dec 2002 16:45:37 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 QQntmx07586 for ; Mon, 16 Dec 2002 16:45:37 GMT Received: from atlntex01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: exchange.movaz.com [65.205.166.141]) id QQntmx07582 for ; Mon, 16 Dec 2002 16:45:36 GMT Received: from BLIULAPTOP ([172.16.24.104]) by atlntex01.movaz.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 16 Dec 2002 11:45:36 -0500 Message-ID: <00b301c2a522$8ea982a0$681810ac@movaz.com> From: "Adrian Farrel" To: "Sharon Chisholm" , References: <3549C09B853DD5119B540002A52CDD3405BF1927@zcard0ka.ca.nortel.com> Subject: Re: Text for Management Overview Document Date: Mon, 16 Dec 2002 11:45:35 -0500 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: 16 Dec 2002 16:45:36.0478 (UTC) FILETIME=[8EE727E0:01C2A522] Sender: owner-mpls@UU.NET Precedence: bulk Thanks, That's very helpful. I'll massage it and work it. If I have any issues or questions, I'll come back to you. Adrian ----- Original Message ----- From: "Sharon Chisholm" To: Sent: Monday, December 16, 2002 10:36 AM Subject: Text for Management Overview Document > hi > > In the MPLS MIB meeting in Atlanta, I promised to provide > some text for the management overview document to help > demystify the MIBs for general applications trying to > discover and manage LSPs. > > There are still a few aspects I'm not 100% sure of, so > I suspect some cleanup of the text will be required. > > --------- > N. LSP Discovery and Management > > There are three different types of LSPs in MPLS - > Traffic Engineering Tunnels, LDP and single hop > service LSPs. Each of these will be discovered > and managed somewhat differently. > > N.1. Traffic Engineering LSPs > > Traffic engineering LSPs are frequently explicitly > routed and tend to be fairly persistent so can > therefore be managed using techniques similar to > that of connection oriented systems. > > These links can be discovered by reading in the > interface table and matching against entries with > an ifType of mplsTunnel(150). Under normal operation, > ifConnectorPresent will always have a value of 'true'. > As the operational status of these links is > service affecting, ifLinkUpDownTrapEnable should > be changed from its default value of 'false' > to be 'true'. > > Additional information about this type of LSP can be > found in the MPLS LSR MIB and the MPLS Traffic > Engineering MIB. > > N.2. Label Distribution Protocol (LDP) LSPs > > LDP LSPs are implicitly routed LSPs and therefore > most closely resembles traditional routing protocols, > but, unlike protocols like BGP, the components of > the LSP are found in the interfaces table. > > Both active and redundant links can be discovered by > reading in the interface table and matching against entries with > an ifType of mpls (166). A value of 'true' for ifConnectorPresent > indicates that a link is active. Given the redundancy of > links as well as the potential for non-service affecting > changes in the operational status of component links, it > does not really make sense to monitor these interfaces for > linkDown notifications, so ifLinkUpDownTrapEnable has a > default value of disabled for this type of interface. > > Additional information about this type of LSP can be > found in the MPLS LSR MIB and the MPLS LDP MIB. > > N.3. Single Hop Service LSPs > > At the service level, there is a third type of LSPs in > single hop service LSPs (e.g. 2547 BGP, or extended > LDP discovery). It is not a peer layer to TE and > LDP, but an overlay. > > This type of LSP shows up in the interface table > as interfaces with ifType of mplsTunnel(150) layered > over interfaces with ifType of mpls(166). The ifStack > table will show the layering relationship between > the LSPs. > > Additional information about this type of LSP can be > found in the MPLS LSR MIB, the MPLS LDP MIB and the > MPLS TE MIB. > ----- > > Sharon Chisholm > Portfolio Integration > Nortel Networks > Ottawa, Canada From owner-mpls@UU.NET Mon Dec 16 13:59: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 NAA14311 for ; Mon, 16 Dec 2002 13:59:57 -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 QQntng06346 for ; Mon, 16 Dec 2002 19:02: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 QQntng01970; Mon, 16 Dec 2002 19:00:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQntng16709 for mpls-outgoing; Mon, 16 Dec 2002 19:00: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 QQntng16511 for ; Mon, 16 Dec 2002 19:00:27 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 QQntnf12876 for ; Mon, 16 Dec 2002 18:59: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 QQntnf10127 for ; Mon, 16 Dec 2002 18:59:59 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 QQntnf10112 for ; Mon, 16 Dec 2002 18:59:58 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Dec 2002 13:59:58 -0500 Message-ID: <1117F7D44159934FB116E36F4ABF221B0267EDBC@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: mpls@UU.NET Cc: Loa Andersson Subject: RE: draft-rosen-mpls-in-ip-or-gre-00.txt Date: Mon, 16 Dec 2002 13:59:57 -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 Yes, this should be a WG document. > From: Loa Andersson > Date: Mon, 16 Dec 2002 17:41:49 +0100 > CC: George Swallow , Scott Bradner > > > All, > > the draft draft-rosen-mpls-in-ip-or-gre-00.txt was presented in Atlanta, > the reception was positive, and there has been no discussion after that > on the mailing list. > > Based on prior response to the mailing list, the response at the > Atlanta meeting and the lack of response after the meeting, it is > the wg chairs intention to make this draft a wg document. > > Please comment before January 7th. > > Loa and George > > -- > Loa Andersson > > Mobile +46 739 81 21 64 > Email loa@pi.se > Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 From owner-mpls@UU.NET Mon Dec 16 15:01: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 PAA16008 for ; Mon, 16 Dec 2002 15:01:26 -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 QQntnk28606 for ; Mon, 16 Dec 2002 20:04:24 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 QQntnk26005; Mon, 16 Dec 2002 20:03:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQntnk20377 for mpls-outgoing; Mon, 16 Dec 2002 20:02:53 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 QQntnk19888 for ; Mon, 16 Dec 2002 20:02: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 QQntnk16869 for ; Mon, 16 Dec 2002 20:01:05 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 QQntnk09378 for ; Mon, 16 Dec 2002 20:01:04 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 QQntnk09360 for ; Mon, 16 Dec 2002 20:01:04 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 gBGK13S07996; Mon, 16 Dec 2002 12:01:03 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id gBGK17j42254; Mon, 16 Dec 2002 12:01:07 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Mon, 16 Dec 2002 12:01:06 -0800 (PST) From: Kireeti Kompella To: Loa Andersson cc: mpls wg Subject: Re: draft-rosen-mpls-in-ip-or-gre-00.txt In-Reply-To: <3DFE024D.8090503@pi.se> Message-ID: <20021216120029.S42222-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Loa, On Mon, 16 Dec 2002, Loa Andersson wrote: > it is > the wg chairs intention to make this draft a wg document. Works for me. Kireeti. From owner-mpls@UU.NET Mon Dec 16 18:28: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 SAA21481 for ; Mon, 16 Dec 2002 18:28:00 -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 QQntny24057 for ; Mon, 16 Dec 2002 23:30: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 QQntnx19676; Mon, 16 Dec 2002 23:28:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQntnx06300 for mpls-outgoing; Mon, 16 Dec 2002 23:27:53 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 QQntnx06281 for ; Mon, 16 Dec 2002 23:27:41 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 QQntnx17592 for ; Mon, 16 Dec 2002 23:27: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 QQntnx19131 for ; Mon, 16 Dec 2002 23:27:07 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 QQntnx19127 for ; Mon, 16 Dec 2002 23:27:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBGNRcww024848 for ; Mon, 16 Dec 2002 18:27:38 -0500 (EST) 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 SAA04262 for ; Mon, 16 Dec 2002 18:27:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBGNR5014999 for mpls@uu.net; Mon, 16 Dec 2002 18:27:05 -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 QQntnx06141 for ; Mon, 16 Dec 2002 23:26: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 QQntnx23868 for ; Mon, 16 Dec 2002 23:24: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 QQntnx03950 for ; Mon, 16 Dec 2002 23:24:31 GMT Received: from sj-msg-core-3.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-3.cisco.com [171.70.157.152]) id QQntnx03940 for ; Mon, 16 Dec 2002 23:24:30 GMT Received: from toque.cisco.com (IDENT:mirapoint@toque.cisco.com [161.44.201.11]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gBGNNWjU004128; Mon, 16 Dec 2002 15:23:33 -0800 (PST) Received: from cisco.com (che-vpn-cluster-2-11.cisco.com [10.86.242.11]) by toque.cisco.com (Mirapoint) with ESMTP id ABB10809; Mon, 16 Dec 2002 18:15:24 -0500 (EST) Message-ID: <3DFE6089.2816CB10@cisco.com> Date: Mon, 16 Dec 2002 18:23:53 -0500 From: Reshad Rahman Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Manoj Agiwal CC: "'Ccamp (E-mail)" , "'mpls@UU.NET'" Subject: Re: Message ID generation References: <99EC34181384D611BE56000347227B2C01520E@MAILHOSTNB> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit If the hop objects are being populated with a control channel (numbered) address then I think one can either generate the message ids per control channel or have 1 "space" for the whole node. If the control channel addresses are unnumbered or the hop objects contains a node address then there should be only 1 message id space for the whole node. Regards, Reshad. Manoj Agiwal wrote: > Hi , > These are the lines from Refresh Reduction RFC > " Message identification and acknowledgment is done on a per hop > basis. All types of MESSAGE_ID objects contain a message > identifier. The identifier MUST be unique on a per object generator's IP > address basis > In case of Gmpls if Per object generators IP address is control > channel address then Message ID should be unique > for each control channel address , or should it be unique per > Neighbour . > > i.e. If there are two control channel address in a Node that goes to > the same neighbor in the data plane , the Message Id > generation should be unique per control channel address or Message Id > generation should be unique for each neighbor . > > Regards , > Manoj From owner-mpls@UU.NET Mon Dec 16 18:35: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 SAA21648 for ; Mon, 16 Dec 2002 18:35:35 -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 QQntny03722 for ; Mon, 16 Dec 2002 23:38:29 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 QQntny00047; Mon, 16 Dec 2002 23:36:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQntny06976 for mpls-outgoing; Mon, 16 Dec 2002 23:35:51 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 QQntny06958 for ; Mon, 16 Dec 2002 23:35: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 QQntny06372 for ; Mon, 16 Dec 2002 23:35: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 QQntny28651 for ; Mon, 16 Dec 2002 23:35:13 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 QQntny28613 for ; Mon, 16 Dec 2002 23:35:08 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBGNZdfx025481 for ; Mon, 16 Dec 2002 18:35:39 -0500 (EST) 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 SAA04894 for ; Mon, 16 Dec 2002 18:35:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBGNZ6w16686 for mpls@uu.net; Mon, 16 Dec 2002 18:35:06 -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 QQntny06893 for ; Mon, 16 Dec 2002 23:34:24 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 QQntny20438 for ; Mon, 16 Dec 2002 23:33:55 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 QQntny27821 for ; Mon, 16 Dec 2002 23:33:55 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 QQntny27795 for ; Mon, 16 Dec 2002 23:33:53 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 SAA63865; Mon, 16 Dec 2002 18:32:50 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212162332.SAA63865@workhorse.fictitious.org> To: neil.2.harrison@bt.com cc: curtis@fictitious.org, dallan@nortelnetworks.com, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: draft-ietf-mpls-lsp-ping-01.txt - ECMP considerations In-reply-to: Your message of "Sun, 15 Dec 2002 13:06:33 GMT." <0536FC9B908BEC4597EE721BE6A35389014CFD14@i2km07-ukbr.domain1.systemhost.net> Date: Mon, 16 Dec 2002 18:32:50 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <0536FC9B908BEC4597EE721BE6A35389014CFD14@i2km07-ukbr.domain1.system host.net>, neil.2.harrison@bt.com writes: > > > > OK. I think the following summarizes the intent. > > > > MPLS-ping is intended to detect forwarding faults > NH=> These are not defined anywhere that I know of except in Y.1710/1711. There is no intention to list all possible defects. This is not the ITU. > > in an MPLS LSP > > and isolate the fault to the LSR at which traffic stops flowing. > NH=> Not all defects will lead to traffic stopping flowing, eg traffic being > leaked out of an LSP due to unintended replication. If you like we can change the prior sentence to: MPLS-ping is intended to detect forwarding faults which result in traffic failing to flow to the intended destination. > > No attempt is made to determine that cause of the fault or diagnose > > problems any further. > NH=> I think LSP-Ping does actually try and give some indications of the > nature of the defect, eg if the egress the pkt arrives at is a valid egress > or not for a given FEC. However, no consequent actions are > specified......like telling affected client layers. MIBs don't tell you what to do when you get a trap either. That would be out of scope. > > Since MPLS-ping "echo request" packets are > > injected no further upstream than the ingress LSR, faults at the > > ingress related to classifying and directing packets and > > encapsulating them for placement in the LSP are not detected. > > Since the MPLS-ping "echo request" packets are extracted no further > > downstream than the egress LSR, faults at the egress in > > decapsulating and directing traffic further are not detected. > > Persistent faults in transiting the LSP, regardless of their cause, > > can be detected and isolated to one or two LSR. > > > > The document doesn't explicitly state what I have above but it only > > talks about detection and isolation. For example: > > > > 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. > > > > If Kireeti adds this to the document we don't need to enumerate all > > possible faults before getting started. I personally think it is > > obvious enough that it doesn't need to be stated but it won't hurt to > > add it. If this doesn't satisfy you, please explain in greater detail > > what you would like to see discussed or in the document. > NH=> I am not sure we can actually do much more than this in the case of > mp2p (you can for p2p) due to the nature of the construct. However, some > attempt should have been made to identify all the possible types of defect > to at least understand if these can be detected (or the limitations) and > what consequent actions should be taken (or the limitations). These are > given in Y.1710 and simple solutions are given for the p2p case, and > draft-nadeau-ip-basedtool-requirements-00.txt also starts to identify these > too. Further, if detects are to be detected/handled consistently (between > vendors/operators) then there should be deterministic behaviour of the > detection devices used. This is a also a pre-cursor requirement for > defining consistent SLAs (where these are required by operators/customers), > as things like availability SLAs (though what this could posssibly mean in a > mp2p construct beats me) and up-state QoS SLAs are dependent on having > consistent defect detection/handling in the 1st place. I don't think any of > this is simple (or even possible?) for mp2p constructs. MPLS-ping is never going to be all things to all people. MPLS-ping will compliment existing management capabilities provided by the MIB (there is one MIB if I read a parallel thread correctly - and I dare not get that wrong and risk provoking the wrath of the MIB doctors). In the interest of making forward progress I suggest you put your deployment experiences in the protocol experiences document when the document advances from PS to DS. Curtis From owner-mpls@UU.NET Mon Dec 16 18:45:38 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 SAA21831 for ; Mon, 16 Dec 2002 18:45:38 -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 QQntnz15677 for ; Mon, 16 Dec 2002 23:48:30 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 QQntnz11107; Mon, 16 Dec 2002 23:45:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQntnz08105 for mpls-outgoing; Mon, 16 Dec 2002 23:45:34 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 QQntnz08097 for ; Mon, 16 Dec 2002 23:45: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 QQntnz24271 for ; Mon, 16 Dec 2002 23:45: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 QQntnz04748 for ; Mon, 16 Dec 2002 23:45:07 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 QQntnz04736 for ; Mon, 16 Dec 2002 23:45:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBGNjcvw026315 for ; Mon, 16 Dec 2002 18:45:38 -0500 (EST) 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 SAA05483 for ; Mon, 16 Dec 2002 18:45:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBGNj5N18687 for mpls@uu.net; Mon, 16 Dec 2002 18:45:05 -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 QQntny07782 for ; Mon, 16 Dec 2002 23:43: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 QQntny22605 for ; Mon, 16 Dec 2002 23:43: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 QQntny19244 for ; Mon, 16 Dec 2002 23:43:39 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 QQntny19217 for ; Mon, 16 Dec 2002 23:43:38 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 SAA63923; Mon, 16 Dec 2002 18:42:15 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212162342.SAA63923@workhorse.fictitious.org> To: "Cheng-Yin Lee" cc: neil.2.harrison@bt.com, curtis@fictitious.org, Shahram_Davari@pmc-sierra.com, dallan@nortelnetworks.com, swallow@cisco.com, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "15 Dec 2002 22:44:16 EST." <3DFD4C10.6D83A84C@alcatel.com> Date: Mon, 16 Dec 2002 18:42:14 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3DFD4C10.6D83A84C@alcatel.com>, "Cheng-Yin Lee" writes: > Neil, > > Now whilst the above does at least agree that the control-plane must not > > proxy for missing data-plane functionality (and its taken a while to even > > get this bit recognised as required), it still fudges the client/server > > data-plane layer network relationships. This is not a good idea for PWE3 > > applications say where the MPLS client can vary. Ideally one wants the > > *same* solution/behaviour for all client (or server) layer cases (and all > > control-plane cases...inc case of 'none', ie static trails). > Is there a requirement to test the data plane liveliness from ideally > the input > interface of the ingress PE to the output interface of the egress PE for > PWE3 applications? > > thanks > cheng-yin If the PWE3 application is non-IP then you can test up to the egress LSR and no further. The same would be true for an IP VPN. For example, you can't inject test traffic into someone's TDM leased line without corrupting the data flow. That part of the LSP forwarding is not tested. That was my point in an earlier statement I made on this thread. Curtis From owner-mpls@UU.NET Tue Dec 17 08:26: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 IAA13494 for ; Tue, 17 Dec 2002 08:26:16 -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 QQntqb17426 for ; Tue, 17 Dec 2002 13:29: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 QQntqb15008; Tue, 17 Dec 2002 13:28:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQntqb26322 for mpls-outgoing; Tue, 17 Dec 2002 13:27: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 QQntqb26317 for ; Tue, 17 Dec 2002 13:27:34 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 QQntqb03499 for ; Tue, 17 Dec 2002 13:27:03 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 QQntqb15064 for ; Tue, 17 Dec 2002 13:27:03 GMT Received: from parsmtp2.rd.francetelecom.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: parsmtp2.rd.francetelecom.com [194.167.105.14]) id QQntqb15051 for ; Tue, 17 Dec 2002 13:27:02 GMT Received: from lanmhs30.rd.francetelecom.fr ([10.193.21.61]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Dec 2002 14:26:54 +0100 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.6249.0 Subject: RE: draft-rosen-mpls-in-ip-or-gre-00.txt Date: Tue, 17 Dec 2002 14:26:53 +0100 Message-ID: <1FB136FD10CE33409C882630E299F5BED0F870@lanmhs30.rd.francetelecom.fr> Thread-Topic: draft-rosen-mpls-in-ip-or-gre-00.txt Thread-Index: AcKlI3AUQOr7zpkXSByoTu63lMWbSQArBkvw From: "LE ROUX Jean-Louis FTRD/DAC/LAN" To: "Loa Andersson" , "mpls wg" Cc: "George Swallow" , "Scott Bradner" X-OriginalArrivalTime: 17 Dec 2002 13:26:54.0622 (UTC) FILETIME=[F7560BE0:01C2A5CF] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA13494 Hi Folks, I support this as a WG document, JL -----Message d'origine----- De : Loa Andersson [mailto:loa@pi.se] Envoye : lundi 16 decembre 2002 17:42 A : mpls wg Cc : George Swallow; Scott Bradner Objet : draft-rosen-mpls-in-ip-or-gre-00.txt All, the draft draft-rosen-mpls-in-ip-or-gre-00.txt was presented in Atlanta, the reception was positive, and there has been no discussion after that on the mailing list. Based on prior response to the mailing list, the response at the Atlanta meeting and the lack of response after the meeting, it is the wg chairs intention to make this draft a wg document. Please comment before January 7th. Loa and George -- Loa Andersson Mobile +46 739 81 21 64 Email loa@pi.se From owner-mpls@UU.NET Tue Dec 17 10:11: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 KAA15286 for ; Tue, 17 Dec 2002 10:11: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 QQntqi16226 for ; Tue, 17 Dec 2002 15: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 QQntqi07517; Tue, 17 Dec 2002 15:09:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQntqi10004 for mpls-outgoing; Tue, 17 Dec 2002 15:08:40 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 QQntqi09956 for ; Tue, 17 Dec 2002 15:08:23 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 QQntqi05803 for ; Tue, 17 Dec 2002 15:07: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 QQntqi18114 for ; Tue, 17 Dec 2002 15:07:11 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 QQntqi18086 for ; Tue, 17 Dec 2002 15:07:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBHF7cHv024328 for ; Tue, 17 Dec 2002 10:07:38 -0500 (EST) 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 KAA20444 for ; Tue, 17 Dec 2002 10:07:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBHF75u05200 for mpls@uu.net; Tue, 17 Dec 2002 10:07: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 QQntqi09524 for ; Tue, 17 Dec 2002 15:05:56 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 QQntqi01656 for ; Tue, 17 Dec 2002 15:05: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 QQntqi23280 for ; Tue, 17 Dec 2002 15:05:48 GMT Received: from father.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQntqi23272 for ; Tue, 17 Dec 2002 15:05:47 GMT Received: (qmail 7856 invoked by uid 104); 17 Dec 2002 15:05:46 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4237. . Clean. Processed in 0.734398 secs); 17 Dec 2002 15:05:46 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 17 Dec 2002 15:05: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 gBHF5dQ06464; Tue, 17 Dec 2002 07:05:39 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Tue, 17 Dec 2002 07:05:39 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03B9D@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Loa Andersson'" , mpls wg Cc: George Swallow , Scott Bradner Subject: RE: draft-rosen-mpls-in-ip-or-gre-00.txt Date: Tue, 17 Dec 2002 07:05:33 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Loa, Works for me too. -Shahram > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.se] > Sent: Monday, December 16, 2002 11:42 AM > To: mpls wg > Cc: George Swallow; Scott Bradner > Subject: draft-rosen-mpls-in-ip-or-gre-00.txt > > > All, > > the draft draft-rosen-mpls-in-ip-or-gre-00.txt was presented > in Atlanta, > the reception was positive, and there has been no discussion > after that > on the mailing list. > > Based on prior response to the mailing list, the response at the > Atlanta meeting and the lack of response after the meeting, it is > the wg chairs intention to make this draft a wg document. > > Please comment before January 7th. > > Loa and George > > -- > Loa Andersson > > Mobile +46 739 81 21 64 > Email loa@pi.se > > From owner-mpls@UU.NET Tue Dec 17 10:18:47 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 KAA15447 for ; Tue, 17 Dec 2002 10:18:47 -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 QQntqj29988 for ; Tue, 17 Dec 2002 15:21: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 QQntqj26932; Tue, 17 Dec 2002 15:20:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQntqj12141 for mpls-outgoing; Tue, 17 Dec 2002 15:20: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 QQntqj12114 for ; Tue, 17 Dec 2002 15:19: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 QQntqj06692 for ; Tue, 17 Dec 2002 15:19: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 QQntqj26288 for ; Tue, 17 Dec 2002 15:19:38 GMT Received: from tenornetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtu.tenornetworks.com [63.77.213.2]) id QQntqj26282 for ; Tue, 17 Dec 2002 15:19:37 GMT Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id gBHFJXN15010; Tue, 17 Dec 2002 10:19:33 -0500 (EST) Received: from 192.168.0.185 by tenornet.com; TUE, 17 Dec 2002 10:17:20 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Tue, 17 Dec 2002 10:17:20 -0500 Message-ID: <6B190B34070BD411ACA000B0D0214E5601684C73@newman.tenornet.com> From: "Shah, Himanshu" To: "'Loa Andersson'" , mpls wg Cc: George Swallow , Scott Bradner Subject: RE: draft-rosen-mpls-in-ip-or-gre-00.txt Date: Tue, 17 Dec 2002 10:17:20 -0500 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 I support this work. /himanshu > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.se] > Sent: Monday, December 16, 2002 11:42 AM > To: mpls wg > Cc: George Swallow; Scott Bradner > Subject: draft-rosen-mpls-in-ip-or-gre-00.txt > > > All, > > the draft draft-rosen-mpls-in-ip-or-gre-00.txt was presented > in Atlanta, > the reception was positive, and there has been no discussion > after that > on the mailing list. > > Based on prior response to the mailing list, the response at the > Atlanta meeting and the lack of response after the meeting, it is > the wg chairs intention to make this draft a wg document. > > Please comment before January 7th. > > Loa and George > > -- > Loa Andersson > > Mobile +46 739 81 21 64 > Email loa@pi.se > > > From owner-mpls@UU.NET Tue Dec 17 11:19: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 LAA16622 for ; Tue, 17 Dec 2002 11:19:43 -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 QQntqn11623 for ; Tue, 17 Dec 2002 16:22: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 QQntqn09712; Tue, 17 Dec 2002 16:21:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQntqn05110 for mpls-outgoing; Tue, 17 Dec 2002 16:21: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 QQntqn05095 for ; Tue, 17 Dec 2002 16:21:08 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 QQntqn26582 for ; Tue, 17 Dec 2002 16:21:03 GMT From: neil.2.harrison@bt.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 QQntqn09214 for ; Tue, 17 Dec 2002 16:21:02 GMT Received: from cbibipnt05.hc.bt.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQntqn09204 for ; Tue, 17 Dec 2002 16:21:02 GMT Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Tue, 17 Dec 2002 16:20:33 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A35389014CFD37@i2km07-ukbr.domain1.systemhost.net> To: loa@pi.se, mpls@UU.NET Cc: swallow@cisco.com, sob@harvard.edu Subject: RE: draft-rosen-mpls-in-ip-or-gre-00.txt Date: Tue, 17 Dec 2002 16:20:21 -0000 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 I support this work. regards, Neil > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.se] > Sent: 16 December 2002 16:42 > To: mpls wg > Cc: George Swallow; Scott Bradner > Subject: draft-rosen-mpls-in-ip-or-gre-00.txt > > > All, > > the draft draft-rosen-mpls-in-ip-or-gre-00.txt was presented > in Atlanta, > the reception was positive, and there has been no discussion > after that > on the mailing list. > > Based on prior response to the mailing list, the response at the > Atlanta meeting and the lack of response after the meeting, it is > the wg chairs intention to make this draft a wg document. > > Please comment before January 7th. > > Loa and George > > -- > Loa Andersson > > Mobile +46 739 81 21 64 > Email loa@pi.se > > > From owner-mpls@UU.NET Wed Dec 18 09:51: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 JAA09887 for ; Wed, 18 Dec 2002 09:51:47 -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 QQnttz27036 for ; Wed, 18 Dec 2002 14:54:40 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 QQnttz22568; Wed, 18 Dec 2002 14:52:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQnttz27255 for mpls-outgoing; Wed, 18 Dec 2002 14:51: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 QQnttz27241 for ; Wed, 18 Dec 2002 14:51: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 QQnttz09870 for ; Wed, 18 Dec 2002 14:50:09 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 QQnttz19422 for ; Wed, 18 Dec 2002 14:50:08 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 QQnttz19411 for ; Wed, 18 Dec 2002 14:50:08 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBIEoc8A012445 for ; Wed, 18 Dec 2002 09:50:39 -0500 (EST) 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 JAA15307 for ; Wed, 18 Dec 2002 09:50:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBIEo5T13138 for mpls@uu.net; Wed, 18 Dec 2002 09:50:05 -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 QQnttz26954 for ; Wed, 18 Dec 2002 14:49:23 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 QQnttz07793 for ; Wed, 18 Dec 2002 14:49:19 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 QQnttz18707 for ; Wed, 18 Dec 2002 14:49:19 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 QQnttz18685 for ; Wed, 18 Dec 2002 14:49:18 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 JAA74772; Wed, 18 Dec 2002 09:48:04 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212181448.JAA74772@workhorse.fictitious.org> To: Cheng-Yin.Lee@alcatel.com cc: "Kireeti Kompella" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "13 Dec 2002 15:59:28 EST." <3DFA4A2F.9B3A1341@alcatel.com> Date: Wed, 18 Dec 2002 09:48:04 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3DFA4A2F.9B3A1341@alcatel.com>, "Cheng-Yin Lee" writes: > Kireeti et al, > It looks like separating the issues may be useful, for e.g. something along t > he > line: > > For "ping" mode: > 1) send a labeled test pkt on a p2p LSP > 2) send a labeled test pkt on a p2p LSP, with PHP (no label after PHP) > 3) send a labeled test pkt on a mp2p LSP (with and without ECMP) > 4) send a labeled test pkt on a mp2p LSP, with PHP (with and without ECMP) > 5) FRR case, etc... > > Similarly for "traceroute" mode. > > This may not be the best/correct/complete way to separate the issues, if so p > ls > suggest other ways. But I think separating the issues may help in progressing > the > draft in the WG. One may find that it may not be necessary to use 127/8, or t > hat > the problem could be partitioned. Just a thought ... > > thanks, > cheng-yin MP is not specific to p2mp. MP applies to p2p as well. *Any* LSP may take a hop which splits traffic and merges it again. The LSR that does the split must be able to determine that a specific LSP 1) only carries IP and can be split based on IP headers, 2) has a label stack and can be split on labels, 3) can't be split. Curtis From owner-mpls@UU.NET Wed Dec 18 10:16:35 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 KAA10396 for ; Wed, 18 Dec 2002 10:16:35 -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 QQntub15464 for ; Wed, 18 Dec 2002 15:19: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 QQntub12783; Wed, 18 Dec 2002 15:18:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQntub18099 for mpls-outgoing; Wed, 18 Dec 2002 15:17:48 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 QQntub18094 for ; Wed, 18 Dec 2002 15:17: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 QQntub05713 for ; Wed, 18 Dec 2002 15:16: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 QQntub11178 for ; Wed, 18 Dec 2002 15:16:09 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 QQntub11142 for ; Wed, 18 Dec 2002 15:16:08 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBIFGdRP016565 for ; Wed, 18 Dec 2002 10:16:39 -0500 (EST) 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 KAA17056 for ; Wed, 18 Dec 2002 10:16:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBIFG5F16139 for mpls@uu.net; Wed, 18 Dec 2002 10:16:05 -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 QQntub17722 for ; Wed, 18 Dec 2002 15:15: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 QQntua09968 for ; Wed, 18 Dec 2002 15:14: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 QQntua09268 for ; Wed, 18 Dec 2002 15:14:06 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 QQntua09263 for ; Wed, 18 Dec 2002 15:14:05 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 KAA74817; Wed, 18 Dec 2002 10:12:55 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212181512.KAA74817@workhorse.fictitious.org> To: Kireeti Kompella cc: "Gray, Eric" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Fri, 13 Dec 2002 13:52:16 PST." <20021213134746.H31175-100000@kummer.juniper.net> Date: Wed, 18 Dec 2002 10:12:55 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <20021213134746.H31175-100000@kummer.juniper.net>, Kireeti Kompella writes: > > 23) The last paragraph in section 8 ... > ^^^ > > Thanks, Eric! > > All I need now is two counts: (a) the number of emails for this Last > Call; (b) the number of individual comments/nits/fixes that were made. > > Loa, George, what are the current records for these? :-) > > Kireeti. Kireeti, You clearly need to revise this document and present it for comment to the list again. Its useful in its current form but as a draft that can be advaced to the IESG, its half baked. After initial comments on the revision, then redo the last call and keep track of the comments. Curtis From owner-mpls@UU.NET Wed Dec 18 11:34:26 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 LAA12256 for ; Wed, 18 Dec 2002 11:34:26 -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 QQntug17481 for ; Wed, 18 Dec 2002 16:37: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 QQntug10001; Wed, 18 Dec 2002 16:33:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQntug12507 for mpls-outgoing; Wed, 18 Dec 2002 16:33: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 QQntug12502 for ; Wed, 18 Dec 2002 16:33:07 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 QQntug25691 for ; Wed, 18 Dec 2002 16:32:09 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 QQntug17312 for ; Wed, 18 Dec 2002 16:32:08 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 QQntug17298 for ; Wed, 18 Dec 2002 16:32:08 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBIGWe1B029557 for ; Wed, 18 Dec 2002 11:32:40 -0500 (EST) 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 LAA23232 for ; Wed, 18 Dec 2002 11:32:07 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBIGW7E21810 for mpls@uu.net; Wed, 18 Dec 2002 11:32:07 -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 QQntug12304 for ; Wed, 18 Dec 2002 16:30:55 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 QQntuf19562 for ; Wed, 18 Dec 2002 16:28:09 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 QQntuf04136 for ; Wed, 18 Dec 2002 16:28:09 GMT Received: from father.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQntuf04106 for ; Wed, 18 Dec 2002 16:28:08 GMT Received: (qmail 3447 invoked by uid 104); 18 Dec 2002 16:28:07 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4237. . Clean. Processed in 0.47211 secs); 18 Dec 2002 16:28:07 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 18 Dec 2002 16:28:07 -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 gBIGS6Q27035; Wed, 18 Dec 2002 08:28:06 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Wed, 18 Dec 2002 08:28:05 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03BA9@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'curtis@fictitious.org'" , Kireeti Kompella Cc: "Gray, Eric" , mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Wed, 18 Dec 2002 08:28:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > > Kireeti, > > You clearly need to revise this document and present it for comment to > the list again. Its useful in its current form but as a draft that > can be advaced to the IESG, its half baked. After initial comments on > the revision, then redo the last call and keep track of the comments. > > Curtis Kireeti, Before revising the document, I suggest answering all the follow up comments. -Shahram From owner-mpls@UU.NET Wed Dec 18 12:38: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 MAA13681 for ; Wed, 18 Dec 2002 12:38:43 -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 QQntuk12091 for ; Wed, 18 Dec 2002 17:41: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 QQntuk04640; Wed, 18 Dec 2002 17:37:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQntuk06448 for mpls-outgoing; Wed, 18 Dec 2002 17:37:09 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 QQntuk06443 for ; Wed, 18 Dec 2002 17:36: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 QQntuk03498 for ; Wed, 18 Dec 2002 17:36: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 QQntuk03976 for ; Wed, 18 Dec 2002 17:36:18 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 QQntuk03962 for ; Wed, 18 Dec 2002 17:36:17 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBIHaeQe008958 for ; Wed, 18 Dec 2002 12:36:49 -0500 (EST) 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 MAA28631 for ; Wed, 18 Dec 2002 12:36:07 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBIHa7c27814 for mpls@uu.net; Wed, 18 Dec 2002 12:36:07 -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 QQntuk06203 for ; Wed, 18 Dec 2002 17:34:53 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 QQntuk08566 for ; Wed, 18 Dec 2002 17:34:28 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 QQntuk13094 for ; Wed, 18 Dec 2002 17:34:28 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 QQntuk13084 for ; Wed, 18 Dec 2002 17:34:27 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 MAA75619; Wed, 18 Dec 2002 12:33:03 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212181733.MAA75619@workhorse.fictitious.org> To: Shahram Davari cc: "'curtis@fictitious.org'" , Kireeti Kompella , "Gray, Eric" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Wed, 18 Dec 2002 08:28:00 PST." <4B6D09F3B826D411A67300D0B706EFDEB03BA9@nt-exch-yow.pmc-sierra.bc.ca> Date: Wed, 18 Dec 2002 12:33:03 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4B6D09F3B826D411A67300D0B706EFDEB03BA9@nt-exch-yow.pmc-sierra.bc.ca >, Shahram Davari writes: > > > > Kireeti, > > > > You clearly need to revise this document and present it for comment to > > the list again. Its useful in its current form but as a draft that > > can be advaced to the IESG, its half baked. After initial comments on > > the revision, then redo the last call and keep track of the comments. > > > > Curtis > > Kireeti, > > Before revising the document, I suggest answering all the follow up comments. > > -Shahram Shahram, I suggest not. It would be more productive to revise the document reflecting the (sometimes long and largely unproductive) threads rather than respond to every message. After the document is revised, provide an opportunity for new comments or for comments to be repeated if clarifications didn't help or prior (valid) comments were not reflected in the revision. Its clear this document wasn't ready for last call, but at least the false start drew some useful dialog (and some less so) and could substantially improve the document if the comments are reflected. Curtis From owner-mpls@UU.NET Wed Dec 18 12:40:59 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 MAA13719 for ; Wed, 18 Dec 2002 12:40:58 -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 QQntuk25457 for ; Wed, 18 Dec 2002 17:43:53 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 QQntuk18232; Wed, 18 Dec 2002 17:40:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQntuk06575 for mpls-outgoing; Wed, 18 Dec 2002 17:39: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 QQntuk06563 for ; Wed, 18 Dec 2002 17:39:36 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 QQntuk15010 for ; Wed, 18 Dec 2002 17:39: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 QQntuk17293 for ; Wed, 18 Dec 2002 17:39:15 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 QQntuk17275 for ; Wed, 18 Dec 2002 17:39:15 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBIHdlmx009378 for ; Wed, 18 Dec 2002 12:39:48 -0500 (EST) 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 MAA28896 for ; Wed, 18 Dec 2002 12:39:14 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBIHdEu28060 for mpls@uu.net; Wed, 18 Dec 2002 12:39:14 -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 QQntuk06485 for ; Wed, 18 Dec 2002 17:38:18 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 QQntuk07880 for ; Wed, 18 Dec 2002 17:37:45 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 QQntuk08034 for ; Wed, 18 Dec 2002 17:37:44 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 QQntuk08015 for ; Wed, 18 Dec 2002 17:37:42 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 MAA75737; Wed, 18 Dec 2002 12:36:28 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212181736.MAA75737@workhorse.fictitious.org> To: mpls@UU.NET cc: curtis@fictitious.org Reply-To: curtis@fictitious.org Subject: suggested clarification to intro parts of draft-ietf-mpls-lsp-ping-01 Date: Wed, 18 Dec 2002 12:36:28 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In the interest of making progress on this document, below are some suggested addtions to draft-ietf-mpls-lsp-ping-01 to provide clarification and reflect some of the conversations on the list. I had some private conversations with Alia about the points she brought up about TTL processing. These are reflected below. I intend this to be one of three parts. I'm writing and sending them in order of expected most baked and least controversial first. The second is an addition at the end of the document to clarify how traceroute mode works (only ping more is defined) and to very briefly suggest how ping and traceroute can be used for path identification (including MP), continuity testing, and in problem isolation. The third is the revised protocol bits for MP. In the interest of being as constructive as I could be, rather than just complaining, I provided this as diffs to the existing draft. I did not incorporate Eric Gray's comments. (Someone needs to incorporate changes reflecting those comments or respond to Eric). Curtis ps - If no controversy errupts, the second part will follow shortly. @@ -108,41 +108,59 @@ Kompella et al Standards Track [Page 2] Internet Draft Detecting MPLS Data Plane Liveness October 2002 1. Introduction - This document describes a simple and efficient mechanism that can be - used to detect data plane failures in MPLS LSPs. There are two parts + This document describes a mechanism that can be used to detect data + plane failures in MPLS LSPs. The mechanisms described here are + intended to detect forwarding faults in an MPLS LSP which prevent + traffic from being delivered to its intended destination and + isolate the fault to the LSR at which traffic stops flowing. No + attempt is made to determine that cause of the fault or diagnose + problems any further. Enumeration of all possible fault types is + outside the scope of this document. + + There are two parts to this document: information carried in an MPLS "echo request" and "echo reply"; and mechanisms for transporting the echo reply. The first part aims at providing enough information to check correct operation of the data plane, as well as a mechanism to verify the data plane against the control plane, and thereby localize faults. The second part suggests two methods of reliable reply channels for the echo request message, for more robust fault isolation. An important consideration in this design is that MPLS echo requests follow the same data path that normal MPLS packets would traverse. MPLS echo requests are meant primarily to validate the data plane, and secondarily to verify the data plane against the control plane. Mechanisms to check the control plane are valuable, but are not covered in this document. + Most persistent faults in transiting an LSP from ingress to egress + can be detected and isolated to one or two LSR. Since MPLS-ping + "echo request" packets are injected no further upstream than the + ingress LSR, faults at the ingress related to classifying and + directing packets and encapsulating them for placement in the LSP + are not detected. Since the MPLS-ping "echo request" packets are + extracted no further downstream than the egress LSR, faults at the + egress in decapsulating and directing traffic further are not + detected. + To avoid potential Denial of Service attacks, it is recommended to regulate the MPLS ping traffic going to the control plane. A rate limiter should be applied to the well-known UDP port defined below. 1.1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS]. 1.2. Changes since last revision @@ -205,30 +223,111 @@ determined as the path. One way these tools can be used is to periodically ping a FEC to ensure connectivity. If the ping fails, one can then initiate a traceroute to determine where the fault lies. One can also periodically traceroute FECs to verify that forwarding matches the control plane; however, this places a greater burden on transit LSRs and thus should be used with caution. +2.1. Multipath Considerations - - - - - + Multipath has been implemented in both IP based forwarding and in + MPLS. The foundation for multipath in IP can be found in the + definition of ECMP for OSPF [OSPF]. Important consideration for + implementation of multipath and insights into behaviour of existing + implementations can be found in [MP-NH aka RFC2991]. + + For MPLS LSPs multipath may be encountered in one of the following + forms: + + 1. IP traffic at an ingress LSR is put on multiple LSPs. The + decision regarding a traffic split is made on the basis of + information in the IP header exactly as it is done for OSPF + ECMP. + + 2. An LSP splits traffic at one or more midpoints based on + labels beneath the top label. Existing implementations may + use all labels in the stack in this decision, or impose a + fixed limit on the number of labels considered. + + 3. An LSP may be known to contain IP traffic (either through + signaling or other means outside the scope of this + document). For such an LSP traffic may split at one or more + midpoints based on IP header information exactly as it is + done for OSPF ECMP. + + 4. Traffic may be spread over more than one resource (for + example: forwarding ASIC, switch fabric channel, external + link) where the component path needs to be exposed for a + thorough test. + + Instances of each of the above applications of multipath are known + to be deployed. Considerations are made which address the + requirements to identify all paths and test each path + independently. + + The analogous multipath diagnostic capability is not currently + provided by IP traceroute and ping. The analogous control plane + trace is available for IP through the technique known as MIB + traceroute. The ability to verify forwarding on all paths is + provided for IP by using test traffic random destinations and using + the record route option to determine that all paths have been + exercised. Service providers are aware of these techniques and + make use of them. + + +2.2. TTL Processing during Forwarding + + Three forms of TTL processing for MPLS LSR is specified in + [draft-ietf-mpls-ttl-04], Uniform, Pipe, and Short Pipe. The + Uniform Model corresponds to TTL processing specified in RFC3032. + + Like IP traceroute, for MPLS traceroute the ingress sends test + traffic with an initial TTL of one and increases TTL to acquire + path information. Unlike IP traceroute, MPLS traceroute may have + to work with a label stack. + + The method of TTL processing will not affect tracing the path of + the top label, if the LSP does not traverse a hierarchical hop as + defined in [draft-ietf-mpls-lsp-hierarchy-08] or otherwise enter an + outer LSP as would occur when LDP takes a directed hop through an + MPLS RSVP-TE LSP. For a given hierarchical hop, if the ingress LSR + for the inner LSP under test is not the ingress of the outer LSP, + then testability will be limited if the Pipe Model is used. + + For hierarchical LSPs where the outer LSP uses Pipe Mode, if the + outer (upper) TTL is copied from the inner TTL, then the outer LSP + will be traced but a number of inner LSP hops (the LSP actually + under test) will not be traceable. If the outer TTL is + independently set to a high initial number, then the outer LSP will + not be traced but instead will appear as a single hop. The latter + case is known to be the more common. If the Uniform Model is used, + then all hops of the outer and inner LSP will appear in the trace. + + When the LSP being tested represents an inner label in the label + stack and this LSP and an upper LSP both terminate at the same LSR, + processing of the S bit on the inner LSP at the egress LSR may + require change. For pseudo-wire [ccc, martinni, PW?] and virtual + private network services [BGPVPN] this label is normally popped and + the packet underneath is forwarded uniterpreted to an outgoing + interface. The presence of another label (absense of the "S" or + "bottom of stack" bit) should suppress this delivery and instead + cause inspection of the next label in the stack. If the egress is + configured to implement Pipe Mode TTL processing, the TTL of the + lower label will not expire premempting this forwarding. + Kompella et al Standards Track [Page 4] Internet Draft Detecting MPLS Data Plane Liveness October 2002 3. Packet Format An MPLS echo request is a (possibly labelled) UDP packet; the contents of the UDP packet have the following format: From owner-mpls@UU.NET Wed Dec 18 12:48: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 MAA13927 for ; Wed, 18 Dec 2002 12:48:49 -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 QQntul01109 for ; Wed, 18 Dec 2002 17:51: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 QQntuk16329; Wed, 18 Dec 2002 17:43:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQntuk07055 for mpls-outgoing; Wed, 18 Dec 2002 17:43:27 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 QQntuk07028 for ; Wed, 18 Dec 2002 17:43:23 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 QQntuk23775 for ; Wed, 18 Dec 2002 17:42: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 QQntuk13756 for ; Wed, 18 Dec 2002 17:42:32 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 QQntuk13710 for ; Wed, 18 Dec 2002 17:42:31 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBIHh2CI009854 for ; Wed, 18 Dec 2002 12:43:03 -0500 (EST) 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 MAA29165 for ; Wed, 18 Dec 2002 12:42:29 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBIHgTV28737 for mpls@uu.net; Wed, 18 Dec 2002 12:42:29 -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 QQntuk06613 for ; Wed, 18 Dec 2002 17:40: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 QQntuk07651 for ; Wed, 18 Dec 2002 17:39:46 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 QQntuk17788 for ; Wed, 18 Dec 2002 17:39:46 GMT Received: from father.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQntuk17776 for ; Wed, 18 Dec 2002 17:39:45 GMT Received: (qmail 10588 invoked by uid 104); 18 Dec 2002 17:39:44 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4237. . Clean. Processed in 0.489212 secs); 18 Dec 2002 17:39:44 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 18 Dec 2002 17:39:44 -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 gBIHdhQ12506; Wed, 18 Dec 2002 09:39:43 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Wed, 18 Dec 2002 09:39:43 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03BB0@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'curtis@fictitious.org'" Cc: Kireeti Kompella , "Gray, Eric" , mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Wed, 18 Dec 2002 09:39:40 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > > > > Before revising the document, I suggest answering all the > follow up comments. > > > > -Shahram > > > Shahram, > > I suggest not. It would be more productive to revise the document > reflecting the (sometimes long and largely unproductive) threads > rather than respond to every message. After the document is revised, > provide an opportunity for new comments or for comments to be repeated > if clarifications didn't help or prior (valid) comments were not > reflected in the revision. > > Its clear this document wasn't ready for last call, but at least the > false start drew some useful dialog (and some less so) and could > substantially improve the document if the comments are reflected. > > Curtis > Up to you, but that would leave the comments raised as unresolved. And people will certainly repeat those comments that have not been responded to, which would then require a couple of more last calls. -Shahram From owner-mpls@UU.NET Wed Dec 18 13:15: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 NAA14829 for ; Wed, 18 Dec 2002 13:15:02 -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 QQntun14377 for ; Wed, 18 Dec 2002 18:17:57 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 QQntun12233; Wed, 18 Dec 2002 18:16:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQntun29078 for mpls-outgoing; Wed, 18 Dec 2002 18:16:18 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 QQntun28884 for ; Wed, 18 Dec 2002 18:16:00 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 QQntun16058 for ; Wed, 18 Dec 2002 18:15: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 QQntun20189 for ; Wed, 18 Dec 2002 18:15:09 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 QQntun20175 for ; Wed, 18 Dec 2002 18:15:08 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBIIFe2N014644 for ; Wed, 18 Dec 2002 13:15:40 -0500 (EST) 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 NAA02132 for ; Wed, 18 Dec 2002 13:15:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBIIF6J06462 for mpls@uu.net; Wed, 18 Dec 2002 13:15:06 -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 QQntum28573 for ; Wed, 18 Dec 2002 18:14:08 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 QQntum24439 for ; Wed, 18 Dec 2002 18:13: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 QQntum27201 for ; Wed, 18 Dec 2002 18:13:16 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 QQntum27178 for ; Wed, 18 Dec 2002 18:13:15 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 NAA76043; Wed, 18 Dec 2002 13:11:59 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212181811.NAA76043@workhorse.fictitious.org> To: Shahram Davari cc: "'curtis@fictitious.org'" , Kireeti Kompella , "Gray, Eric" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Wed, 18 Dec 2002 09:39:40 PST." <4B6D09F3B826D411A67300D0B706EFDEB03BB0@nt-exch-yow.pmc-sierra.bc.ca> Date: Wed, 18 Dec 2002 13:11:59 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4B6D09F3B826D411A67300D0B706EFDEB03BB0@nt-exch-yow.pmc-sierra.bc.ca >, Shahram Davari writes: > > > > > > > Before revising the document, I suggest answering all the > > follow up comments. > > > > > > -Shahram > > > > > > Shahram, > > > > I suggest not. It would be more productive to revise the document > > reflecting the (sometimes long and largely unproductive) threads > > rather than respond to every message. After the document is revised, > > provide an opportunity for new comments or for comments to be repeated > > if clarifications didn't help or prior (valid) comments were not > > reflected in the revision. > > > > Its clear this document wasn't ready for last call, but at least the > > false start drew some useful dialog (and some less so) and could > > substantially improve the document if the comments are reflected. > > > > Curtis > > > > Up to you, but that would leave the comments raised as unresolved. And > people will certainly repeat those comments that have not been responded > to, which would then require a couple of more last calls. > > -Shahram > I'm not suggesting comments should be ignored. For example: This document describes a mechanism that can be used to detect data plane failures in MPLS LSPs. The mechanisms described here are intended to detect forwarding faults in an MPLS LSP which prevent traffic from being delivered to its intended destination and isolate the fault to the LSR at which traffic stops flowing. No attempt is made to determine that cause of the fault or diagnose problems any further. Enumeration of all possible fault types is outside the scope of this document. Removing "simple and efficient" in the first sentence addresses a long message voicing an objection. The last two sentences address some diatribe on this list about lsp-ping != Y.1711 by agreeing that lsp-ping != Y.1711. Its a feature. I think a lot of comment resulted from a poor understanding of how traceroute mode was supposed to work. I responded earlier by saying that "like IP tracroute" was sufficient for me but needed to be in the document. So we'll put it there. There was a lot of noise on this list. If there were useful comments that were missed they can be repeated. We don't want to repeat the bgp-17 experience where comments were made and the document remained unchanged for 10 months and no one was quite sure what had been agreed to and what was being reviewed. Curtis From owner-mpls@UU.NET Wed Dec 18 13:41: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 NAA15471 for ; Wed, 18 Dec 2002 13:41: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 QQntuo05449 for ; Wed, 18 Dec 2002 18:44:44 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 QQntuo28532; Wed, 18 Dec 2002 18:41:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQntuo01127 for mpls-outgoing; Wed, 18 Dec 2002 18:41:05 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 QQntuo01027 for ; Wed, 18 Dec 2002 18:41:01 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 QQntuo27780 for ; Wed, 18 Dec 2002 18:39:09 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 QQntuo25936 for ; Wed, 18 Dec 2002 18:39:08 GMT Received: from zcars04f.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQntuo25908 for ; Wed, 18 Dec 2002 18:39:08 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 gBIIchN04438; Wed, 18 Dec 2002 13:38:44 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Dec 2002 13:38:43 -0500 Message-ID: From: "David Allan" To: curtis@fictitious.org Cc: mpls@UU.NET Subject: RE: suggested clarification to intro parts of draft-ietf-mpls-lsp -ping-01 Date: Wed, 18 Dec 2002 13:38:44 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Curtis: Glad to see the material on TTL (this has been a concern of mine), but a few questions/comments...(in line) > +2.2. TTL Processing during Forwarding > + > + Three forms of TTL processing for MPLS LSR is specified in > + [draft-ietf-mpls-ttl-04], Uniform, Pipe, and Short Pipe. The > + Uniform Model corresponds to TTL processing specified in RFC3032. > + > + Like IP traceroute, for MPLS traceroute the ingress sends test > + traffic with an initial TTL of one and increases TTL to acquire > + path information. Unlike IP traceroute, MPLS traceroute may have > + to work with a label stack. > + > + The method of TTL processing will not affect tracing the path of > + the top label, if the LSP does not traverse a hierarchical hop as > + defined in [draft-ietf-mpls-lsp-hierarchy-08] or > otherwise enter an > + outer LSP as would occur when LDP takes a directed hop through an > + MPLS RSVP-TE LSP. For a given hierarchical hop, if the > ingress LSR > + for the inner LSP under test is not the ingress of the outer LSP, > + then testability will be limited if the Pipe Model is used. > + > + For hierarchical LSPs where the outer LSP uses Pipe Mode, if the > + outer (upper) TTL is copied from the inner TTL, The outer LSP seems to use uniform mode as described, not pipe mode in order to inherit the TTL of the inner LSP. If the outer LSP was pipe mode, then it would start with a fixed value, not copied from the inner LSP. > + then the outer LSP > + will be traced but a number of inner LSP hops (the LSP actually > + under test) will not be traceable. Similarly, the inner LSP PING origin may not be routable LSRs transited by the outer LSP. Normally this just results in gaps in any traceroute, and if downstream mapping TLV is used, this would most likely be identifiable from an analysis of the returned results, but results would require interpretation. Of course when uniform model is used and you are tracing an inner LSP, and you are routable from the outer LSP, it is not clear that the results will be comprehensible - downstream mapping has the capability to return the additional level at the ingress, but the error codes while tracing that level would appear to be consistently "no mapping for the FEC". then when encoutering PHP at that level, the inner label would not be known, so presumably the ping request carries implicit null as the downstream mapping, and hopefully you synch back up on both "FEC mapping" and "is downstream router" past that point. Re-reading this para, re-enfoces my opinion that the return code should permit multiple outcomes. If I am tracing an inner LSP with uniform model, "no FEC mapping but is downstream LSR" is a legit response and knowing both things is useful. > + If the outer TTL is > + independently set to a high initial number, then the outer LSP will > + not be traced but instead will appear as a single hop. The latter > + case is known to be the more common. If the Uniform > Model is used, > + then all hops of the outer and inner LSP will appear in the trace. again with the proviso that the inner ping origin is routable from the outer LSR. (BTW, I cannot envision using uniform model across levels that are not routable, but then I suspect that not all hardware supports a choice, and there is no mechanism to control or configure this). > + > + When the LSP being tested represents an inner label in the label > + stack and this LSP and an upper LSP both terminate at the > same LSR, > + processing of the S bit on the inner LSP at the egress LSR may > + require change. For pseudo-wire [ccc, martinni, PW?] and virtual > + private network services [BGPVPN] this label is normally > popped and > + the packet underneath is forwarded uniterpreted to an outgoing > + interface. if the implication here is PHP of service labels at the PE, this is what the label stack features seem to be designed to support. You proxy testing the PW via testing the PSN with a stack. > + The presence of another label (absense of the "S" or > + "bottom of stack" bit) should suppress this delivery and instead > + cause inspection of the next label in the stack. If the egress is > + configured to implement Pipe Mode TTL processing, the TTL of the > + lower label will not expire premempting this forwarding. cheers Dave From owner-mpls@UU.NET Wed Dec 18 15:11:47 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 PAA17782 for ; Wed, 18 Dec 2002 15:11: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 QQntuu01044 for ; Wed, 18 Dec 2002 20: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 QQntuu25995; Wed, 18 Dec 2002 20:11:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQntuu14839 for mpls-outgoing; Wed, 18 Dec 2002 20:11: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 QQntuu14827 for ; Wed, 18 Dec 2002 20: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 QQntuu07246 for ; Wed, 18 Dec 2002 20:11: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 QQntuu19789 for ; Wed, 18 Dec 2002 20:11: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 QQntuu19785 for ; Wed, 18 Dec 2002 20:11:06 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBIKBcgi002916 for ; Wed, 18 Dec 2002 15:11:38 -0500 (EST) 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 PAA13499 for ; Wed, 18 Dec 2002 15:11:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBIKB5216615 for mpls@uu.net; Wed, 18 Dec 2002 15:11:05 -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 QQntuu14095 for ; Wed, 18 Dec 2002 20:09: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 QQntuu07278 for ; Wed, 18 Dec 2002 20:06: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 QQntuu22655 for ; Wed, 18 Dec 2002 20:06:45 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 QQntuu22601 for ; Wed, 18 Dec 2002 20:06:44 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 PAA76605; Wed, 18 Dec 2002 15:05:26 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212182005.PAA76605@workhorse.fictitious.org> To: "David Allan" cc: curtis@fictitious.org, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: suggested clarification to intro parts of draft-ietf-mpls-lsp -ping-01 In-reply-to: Your message of "Wed, 18 Dec 2002 13:38:44 EST." Date: Wed, 18 Dec 2002 15:05:26 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk Dave, Thanks for the comments. Lets hope Kireeti, Ping, George, et al are in agreement. In message , "Da vid Allan" writes: > > > Curtis: > > Glad to see the material on TTL (this has been a concern of mine), but a few > questions/comments...(in line) > > > > +2.2. TTL Processing during Forwarding > > + > > + Three forms of TTL processing for MPLS LSR is specified in > > + [draft-ietf-mpls-ttl-04], Uniform, Pipe, and Short Pipe. The > > + Uniform Model corresponds to TTL processing specified in RFC3032. > > + > > + Like IP traceroute, for MPLS traceroute the ingress sends test > > + traffic with an initial TTL of one and increases TTL to acquire > > + path information. Unlike IP traceroute, MPLS traceroute may have > > + to work with a label stack. > > + > > + The method of TTL processing will not affect tracing the path of > > + the top label, if the LSP does not traverse a hierarchical hop as > > + defined in [draft-ietf-mpls-lsp-hierarchy-08] or > > otherwise enter an > > + outer LSP as would occur when LDP takes a directed hop through an > > + MPLS RSVP-TE LSP. For a given hierarchical hop, if the > > ingress LSR > > + for the inner LSP under test is not the ingress of the outer LSP, > > + then testability will be limited if the Pipe Model is used. > > + > > + For hierarchical LSPs where the outer LSP uses Pipe Mode, if the > > + outer (upper) TTL is copied from the inner TTL, > > The outer LSP seems to use uniform mode as described, not pipe mode > in order to inherit the TTL of the inner LSP. If the outer LSP was pipe > mode, then it would start with a fixed value, not copied from the inner LSP. The draft doesn't actually say that. Plus, the ingress can think its Uniform Mode and the egress can think its Pipe Mode. > > + then the outer LSP > > + will be traced but a number of inner LSP hops (the LSP actually > > + under test) will not be traceable. > > Similarly, the inner LSP PING origin may not be routable LSRs > transited by the outer LSP. Normally this just results in gaps in any > traceroute, and if downstream mapping TLV is used, this would most likely be > identifiable from an analysis of the returned results, but results would > require interpretation. Of course when uniform model is used and you are > tracing an inner LSP, and you are routable from the outer LSP, it is not > clear that the results will be comprehensible - downstream mapping has the > capability to return the additional level at the ingress, but the error > codes while tracing that level would appear to be consistently "no mapping > for the FEC". then when encoutering PHP at that level, the inner label would > not be known, so presumably the ping request carries implicit null as the > downstream mapping, and hopefully you synch back up on both "FEC mapping" > and "is downstream router" past that point. Re-reading this para, re-enfoces > my opinion that the return code should permit multiple outcomes. If I am > tracing an inner LSP with uniform model, "no FEC mapping but is downstream > LSR" is a legit response and knowing both things is useful. If the core LSRs are not IP reachable except from within the core or the ingress not reachable from the core, then Pipe Model should be used or RSVP reply will have to be specified by the ingress. Otherwise some interpretation of results will be required. Presumably the service provider or party initiating the ping can write perl code or something to accomplish this. No different from using IP ping. Some minimal intellegence is needed somewhere. We provide the tools. ISP can still try to pound a square peg into a round hole (or pick your favorite analogy). > > + If the outer TTL is > > + independently set to a high initial number, then the outer LSP will > > + not be traced but instead will appear as a single hop. The latter > > + case is known to be the more common. If the Uniform > > Model is used, > > + then all hops of the outer and inner LSP will appear in the trace. > > again with the proviso that the inner ping origin is routable from > the outer LSR. (BTW, I cannot envision using uniform model across levels > that are not routable, but then I suspect that not all hardware supports a > choice, and there is no mechanism to control or configure this). Same response as above. IMHO - as someone formerly involved in operation at a very large ISP - Its almost silly to discuss diagnostics from an outside IP address that isn't reachable from the inside. > > + > > + When the LSP being tested represents an inner label in the label > > + stack and this LSP and an upper LSP both terminate at the > > same LSR, > > + processing of the S bit on the inner LSP at the egress LSR may > > + require change. For pseudo-wire [ccc, martinni, PW?] and virtual > > + private network services [BGPVPN] this label is normally > > popped and > > + the packet underneath is forwarded uniterpreted to an outgoing > > + interface. > > if the implication here is PHP of service labels at the PE, this is > what the label stack features seem to be designed to support. You proxy > testing the PW via testing the PSN with a stack. IMHO - PHP was a mistake. One that we have to live with. > > + The presence of another label (absense of the "S" or > > + "bottom of stack" bit) should suppress this delivery and instead > > + cause inspection of the next label in the stack. If the egress is > > + configured to implement Pipe Mode TTL processing, the TTL of the > > + lower label will not expire premempting this forwarding. > > cheers > Dave Dave - I hope we're making forward progress. It seems to me like you and I are in close agreement at least on the points here. After I send the next part (which is related but should go in section 4, not here) please let me know if I missed something that should be in the intro part. Curtis From owner-mpls@UU.NET Wed Dec 18 15:32: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 PAA18094 for ; Wed, 18 Dec 2002 15:32:36 -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 QQntuw00903 for ; Wed, 18 Dec 2002 20:35:34 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 QQntuw29064; Wed, 18 Dec 2002 20:34:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQntuw16906 for mpls-outgoing; Wed, 18 Dec 2002 20:34:38 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 QQntuw16901 for ; Wed, 18 Dec 2002 20:34:37 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 QQntuw03194 for ; Wed, 18 Dec 2002 20:33: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 QQntuw28441 for ; Wed, 18 Dec 2002 20:33:40 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 QQntuw28434 for ; Wed, 18 Dec 2002 20:33:40 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 gBIKXON14263; Wed, 18 Dec 2002 15:33:24 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Dec 2002 15:33:24 -0500 Message-ID: From: "David Allan" To: curtis@fictitious.org Cc: curtis@fictitious.org, mpls@UU.NET Subject: RE: suggested clarification to intro parts of draft-ietf-mpls-lsp -ping-01 Date: Wed, 18 Dec 2002 15:33:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2A6D4.B61AE56E" 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_01C2A6D4.B61AE56E Content-Type: text/plain; charset="iso-8859-1" Hi Curtis: > Dave, > > Thanks for the comments. Lets hope Kireeti, Ping, George, et al are > in agreement. ditto....still have a ways to go, mind you > > > > The outer LSP seems to use uniform mode as > described, not pipe mode > > in order to inherit the TTL of the inner LSP. If the outer > LSP was pipe > > mode, then it would start with a fixed value, not copied > from the inner LSP. > > The draft doesn't actually say that. Don't quite grok, if the outer is pipe mode, it does not copy from the inner when the outer is pushed. > > Plus, the ingress can think its Uniform Mode and the egress can think > its Pipe Mode. True, IMHO TTL is a bit of a messy space. > > > > + then the outer LSP > > > + will be traced but a number of inner LSP hops (the > LSP actually > > > + under test) will not be traceable. > > > > Similarly, the inner LSP PING origin may not be routable LSRs > > transited by the outer LSP. Normally this just results in > gaps in any > > traceroute, and if downstream mapping TLV is used, this > would most likely be > > identifiable from an analysis of the returned results, but > results would > > require interpretation. Of course when uniform model is > used and you are > > tracing an inner LSP, and you are routable from the outer > LSP, it is not > > clear that the results will be comprehensible - downstream > mapping has the > > capability to return the additional level at the ingress, > but the error > > codes while tracing that level would appear to be > consistently "no mapping > > for the FEC". then when encoutering PHP at that level, the > inner label would > > not be known, so presumably the ping request carries > implicit null as the > > downstream mapping, and hopefully you synch back up on both > "FEC mapping" > > and "is downstream router" past that point. Re-reading this > para, re-enfoces > > my opinion that the return code should permit multiple > outcomes. If I am > > tracing an inner LSP with uniform model, "no FEC mapping > but is downstream > > LSR" is a legit response and knowing both things is useful. > > If the core LSRs are not IP reachable except from within the core or > the ingress not reachable from the core, then Pipe Model should be > used or RSVP reply will have to be specified by the ingress. > Otherwise some interpretation of results will be required. Presumably > the service provider or party initiating the ping can write perl code > or something to accomplish this. No different from using IP ping. > Some minimal intellegence is needed somewhere. > > We provide the tools. ISP can still try to pound a square peg into a > round hole (or pick your favorite analogy). > > > > + If the outer TTL is > > > + independently set to a high initial number, then the > outer LSP will > > > + not be traced but instead will appear as a single > hop. The latter > > > + case is known to be the more common. If the Uniform > > > Model is used, > > > + then all hops of the outer and inner LSP will appear > in the trace. > > > > again with the proviso that the inner ping origin is > routable from > > the outer LSR. (BTW, I cannot envision using uniform model > across levels > > that are not routable, but then I suspect that not all > hardware supports a > > choice, and there is no mechanism to control or configure this). > > Same response as above. > > IMHO - as someone formerly involved in operation at a very large ISP - > Its almost silly to discuss diagnostics from an outside IP address > that isn't reachable from the inside. Agreed, simply an artifact of overlaying disjoint networks on hardware that uses uniform model. However, as noted above the more interesting case is when it is not a disjoint network, uniform model is used, and I hit a tunnel entrance. Suddently all LSRs along the TE tunnel have no knowledge of the FEC, but the downstream mappings synch up. Like I said, there are multiple outcomes of a single operation and knowing that matters. If a TE ingress implements uniform model, the downstream mapping TLV should indicate this in the stack returned. If the TE ingress implements pipe model, then the downstream mapping TLV should only return the current level, else I get more errors that require lots of interpretation. > > > > + > > > + When the LSP being tested represents an inner label > in the label > > > + stack and this LSP and an upper LSP both terminate at the > > > same LSR, > > > + processing of the S bit on the inner LSP at the egress LSR may > > > + require change. For pseudo-wire [ccc, martinni, PW?] > and virtual > > > + private network services [BGPVPN] this label is normally > > > popped and > > > + the packet underneath is forwarded uniterpreted to an outgoing > > > + interface. > > > > if the implication here is PHP of service labels at > the PE, this is > > what the label stack features seem to be designed to > support. You proxy > > testing the PW via testing the PSN with a stack. > > IMHO - PHP was a mistake. One that we have to live with. Agree it was a mistake, not sure living with it forever is the answer. > > > > + The presence of another label (absense of the "S" or > > > + "bottom of stack" bit) should suppress this delivery > and instead > > > + cause inspection of the next label in the stack. If > the egress is > > > + configured to implement Pipe Mode TTL processing, the > TTL of the > > > + lower label will not expire premempting this forwarding. > > > > cheers > > Dave > > Dave - I hope we're making forward progress. It seems to me like you > and I are in close agreement at least on the points here. After I > send the next part (which is related but should go in section 4, not > here) please let me know if I missed something that should be in the > intro part. I think understanding is being achieved, colleagues tell me they are learning a lot following the thread ;-) Time will tell if we turn this into progress... cheers Dave > ------_=_NextPart_001_01C2A6D4.B61AE56E Content-Type: text/html; charset="iso-8859-1" RE: suggested clarification to intro parts of draft-ietf-mpls-lsp -ping-01

Hi Curtis:

> Dave,
>
> Thanks for the comments.  Lets hope Kireeti, Ping, George, et al are
> in agreement.

ditto....still have a ways to go, mind you

<snip>
> >
> > <DAVE> The outer LSP seems to use uniform mode as
> described, not pipe mode
> > in order to inherit the TTL of the inner LSP. If the outer
> LSP was pipe
> > mode, then it would start with a fixed value, not copied
> from the inner LSP.
>
> The draft doesn't actually say that.

Don't quite grok, if the outer is pipe mode, it does not copy from the inner when the outer is pushed.
>
> Plus, the ingress can think its Uniform Mode and the egress can think
> its Pipe Mode.

True, IMHO TTL is a bit of a messy space.

>
> > > +   then the outer LSP
> > > +   will be traced but a number of inner LSP hops (the
> LSP actually
> > > +   under test) will not be traceable. 
> >
> > <DAVE> Similarly, the inner LSP PING origin may not be routable LSRs
> > transited by the outer LSP. Normally this just results in
> gaps in any
> > traceroute, and if downstream mapping TLV is used, this
> would most likely be
> > identifiable from an analysis of the returned results, but
> results would
> > require interpretation. Of course when uniform model is
> used and you are
> > tracing an inner LSP, and you are routable from the outer
> LSP, it is not
> > clear that the results will be comprehensible - downstream
> mapping has the
> > capability to return the additional level at the ingress,
> but the error
> > codes while tracing that level would appear to be
> consistently "no mapping
> > for the FEC". then when encoutering PHP at that level, the
> inner label would
> > not be known, so presumably the ping request carries
> implicit null as the
> > downstream mapping, and hopefully you synch back up on both
> "FEC mapping"
> > and "is downstream router" past that point. Re-reading this
> para, re-enfoces
> > my opinion that the return code should permit multiple
> outcomes. If I am
> > tracing an inner LSP with uniform model, "no FEC mapping
> but is downstream
> > LSR" is a legit response and knowing both things is useful.
>
> If the core LSRs are not IP reachable except from within the core or
> the ingress not reachable from the core, then Pipe Model should be
> used or RSVP reply will have to be specified by the ingress.
> Otherwise some interpretation of results will be required.  Presumably
> the service provider or party initiating the ping can write perl code
> or something to accomplish this.  No different from using IP ping.
> Some minimal intellegence is needed somewhere.
>
> We provide the tools.  ISP can still try to pound a square peg into a
> round hole (or pick your favorite analogy).
>
> > > +   If the outer TTL is
> > > +   independently set to a high initial number, then the
> outer LSP will
> > > +   not be traced but instead will appear as a single
> hop.  The latter
> > > +   case is known to be the more common.  If the Uniform
> > > Model is used,
> > > +   then all hops of the outer and inner LSP will appear
> in the trace.
> >
> > <DAVE> again with the proviso that the inner ping origin is
> routable from
> > the outer LSR. (BTW, I cannot envision using uniform model
> across levels
> > that are not routable, but then I suspect that not all
> hardware supports a
> > choice, and there is no mechanism to control or configure this).
>
> Same response as above.
>
> IMHO - as someone formerly involved in operation at a very large ISP -
> Its almost silly to discuss diagnostics from an outside IP address
> that isn't reachable from the inside.

Agreed, simply an artifact of overlaying disjoint networks on hardware that uses uniform model. However, as noted above the more interesting case is when it is not a disjoint network, uniform model is used, and I hit a tunnel entrance. Suddently all LSRs along the TE tunnel have no knowledge of the FEC, but the downstream mappings synch up. Like I said, there are multiple outcomes of a single operation and knowing that matters.

If a TE ingress implements uniform model, the downstream mapping TLV should indicate this in the stack returned. If the TE ingress implements pipe model, then the downstream mapping TLV should only return the current level, else I get more errors that require lots of interpretation.


>
> > > +
> > > +   When the LSP being tested represents an inner label
> in the label
> > > +   stack and this LSP and an upper LSP both terminate at the
> > > same LSR,
> > > +   processing of the S bit on the inner LSP at the egress LSR may
> > > +   require change.  For pseudo-wire [ccc, martinni, PW?]
> and virtual
> > > +   private network services [BGPVPN] this label is normally
> > > popped and
> > > +   the packet underneath is forwarded uniterpreted to an outgoing
> > > +   interface. 
> >
> > <DAVE> if the implication here is PHP of service labels at
> the PE, this is
> > what the label stack features seem to be designed to
> support. You proxy
> > testing the PW via testing the PSN with a stack.
>
> IMHO - PHP was a mistake.  One that we have to live with.

Agree it was a mistake, not sure living with it forever is the answer.

>
> > > +   The presence of another label (absense of the "S" or
> > > +   "bottom of stack" bit) should suppress this delivery
> and instead
> > > +   cause inspection of the next label in the stack.  If
> the egress is
> > > +   configured to implement Pipe Mode TTL processing, the
> TTL of the
> > > +   lower label will not expire premempting this forwarding.
> >
> > cheers
> > Dave
>
> Dave - I hope we're making forward progress.  It seems to me like you
> and I are in close agreement at least on the points here.  After I
> send the next part (which is related but should go in section 4, not
> here) please let me know if I missed something that should be in the
> intro part.

I think understanding is being achieved, colleagues tell me they are learning a lot following the thread ;-) Time will tell if we turn this into progress...

cheers
Dave

>

------_=_NextPart_001_01C2A6D4.B61AE56E-- From owner-mpls@UU.NET Wed Dec 18 15:40:48 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 PAA18208 for ; Wed, 18 Dec 2002 15:40:47 -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 QQntuw17123 for ; Wed, 18 Dec 2002 20:43: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 QQntuw04190; Wed, 18 Dec 2002 20:36:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQntuw17139 for mpls-outgoing; Wed, 18 Dec 2002 20:36:19 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 QQntuw17124 for ; Wed, 18 Dec 2002 20:36:11 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 QQntuw07678 for ; Wed, 18 Dec 2002 20:35: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 QQntuw11290 for ; Wed, 18 Dec 2002 20:35:22 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 QQntuw11243 for ; Wed, 18 Dec 2002 20:35:17 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBIKZm40006562 for ; Wed, 18 Dec 2002 15:35:49 -0500 (EST) 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 PAA15553 for ; Wed, 18 Dec 2002 15:35:15 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBIKZFd20060 for mpls@uu.net; Wed, 18 Dec 2002 15:35:15 -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 QQntuw16880 for ; Wed, 18 Dec 2002 20:34:05 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 QQntuw02680 for ; Wed, 18 Dec 2002 20:33:13 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 QQntuw10319 for ; Wed, 18 Dec 2002 20:33:12 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 QQntuw10312 for ; Wed, 18 Dec 2002 20:33:11 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 PAA76681; Wed, 18 Dec 2002 15:31:55 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212182031.PAA76681@workhorse.fictitious.org> To: Shahram Davari cc: "'curtis@fictitious.org'" , Kireeti Kompella , "Gray, Eric" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Wed, 18 Dec 2002 10:40:25 PST." <4B6D09F3B826D411A67300D0B706EFDEB03BB1@nt-exch-yow.pmc-sierra.bc.ca> Date: Wed, 18 Dec 2002 15:31:55 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4B6D09F3B826D411A67300D0B706EFDEB03BB1@nt-exch-yow.pmc-sierra.bc.ca >, Shahram Davari writes: > Curtis, > > Minor or editorial comments may be left unanswered and be raised > again, but I had some pretty important comments that am not sure > has been resolved. They include: I do sort of agree with you but if the document describes broken bits of protocol, its not the time to look for missing commas. I trust this list is here not because these things haven't already been answereed but as a reminder to put them in the doc. > 1) In L2VPN or L3VPN do we need to push both inner and outer label? > if not then do people agree to add the inner label to the FEC TLV? Depends on which LSP you are testing. Is the inner label semirandom payload to exercise load split or is it the LSP actually under test. > 2) How do we return the label mapping TLV in case RSVP-TE is used > for the return path? (no such object is defined for RSVP-TE) According to the instructions in section 5. Use the RESV. Add the object specified in the doc. What's not clear? > 3) What should be the time stamp format, and should it include the > three time stamps similar to ICMP? "The time is expressed in seconds and microseconds since midnight (0 hour), January 1, 1970". Type "man gettimeofday". Kireeti answered that. I thought it was obvious enough but agree it is better stated. > 4) What happens if in an FEC stack ping, some of the FECs are confirmed > and some are not? Do we need more error codes? How many more? Good question. Let me answer that one separately in another message. It is an ommision in the document. > 5) How are the ATM/FR labels supported in Label-mapping TLV? barf.^h^h^h^r Yes - good point. I don't care^h^h^r I don't know. The amount of thought put into this seems proportional to the deployed base of MPLS over ATM/FR in ISPs. Someone who cares^h^h^r Someone who knows more about this may have to pointlessly beat their head against the wall ^r contribute. :-) [ just kidding - sort of ] > I think it is more constructive to answer protocol impacting questions > rather than leave them unanswered and wait for the 7th version (4 versions un > der draft-pan-lsp-ping and 3 versions under name draft-ietf-mpls-lsp-ping) of > the draft. OK. I still owe you an answer on point 4 and something intellegent on point 5. > Yours, > -Shahram Thanks for the reminders on these points. Curtis From owner-mpls@UU.NET Wed Dec 18 15:48:36 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 PAA18371 for ; Wed, 18 Dec 2002 15:48:36 -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 QQntux07159 for ; Wed, 18 Dec 2002 20:51:32 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 QQntux01735; Wed, 18 Dec 2002 20:48:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQntux18730 for mpls-outgoing; Wed, 18 Dec 2002 20:48:03 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 QQntux18681 for ; Wed, 18 Dec 2002 20:47:53 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 QQntux21263 for ; Wed, 18 Dec 2002 20:46:37 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 QQntux21289 for ; Wed, 18 Dec 2002 20:46:36 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 QQntux21282 for ; Wed, 18 Dec 2002 20:46:36 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBIKl76x008326 for ; Wed, 18 Dec 2002 15:47:08 -0500 (EST) 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 PAA16452 for ; Wed, 18 Dec 2002 15:46:34 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBIKkYl22843 for mpls@uu.net; Wed, 18 Dec 2002 15:46:34 -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 QQntux18169 for ; Wed, 18 Dec 2002 20:45:08 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 QQntuw18694 for ; Wed, 18 Dec 2002 20:44: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 QQntuw18132 for ; Wed, 18 Dec 2002 20:44:41 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 QQntuw18098 for ; Wed, 18 Dec 2002 20:44:39 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 PAA76964; Wed, 18 Dec 2002 15:43:29 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212182043.PAA76964@workhorse.fictitious.org> To: mpls@UU.NET cc: curtis@fictitious.org Reply-To: curtis@fictitious.org Subject: suggested clarification to section 4 of draft-ietf-mpls-lsp-ping-01 Date: Wed, 18 Dec 2002 15:43:29 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk I intend this to send three parts. So far the comments are very constructive. This is part two. Same format - diffs. I'm offering this to the authors as my interpretation of their intent so if I got it wrong please say so. I also may be rushing this but hopefully I didn't say anything too stupid (not since my last response on ATM/FR anyway:). The next part is the multipath stuff (take two on that). I dont' think this completes MPLS ping but I think its a step forward. The real authors should stop me if I shouldn't be doing this. Curtis @@ -790,24 +889,129 @@ 4.5. Non-compliant Routers If the egress for the FEC Stack being pinged does not support MPLS ping, then no reply will be sent, resulting in possible "false negatives". If in "traceroute" mode, a transit LSR does not support MPLS ping, then no reply will be forthcoming from that LSR for some TTL, say n. The LSR originating the echo request SHOULD try sending the echo request with TTL=n+1, n+2, ..., n+k in the hope that some transit LSR further downstream may support MPLS echo requests and reply. In such a case, the echo request for TTL>n MUST NOT have Downstream Mapping TLVs, until a reply is received with a Downstream Mapping. + +4.6. Operation of Traceroute Mode + + In traceroute mode, either the set of one or more paths for an LSP + is being determined, or after a fault has been identified, the + approximate location of the fault is being determined. + + In traceroute mode the ingress begins with a TTL=1. The test + traffic will reach the first LSR that decrements TTL. In the past + LSR have been configured to not decrement TTL. This practice is + discouraged, and may no longer be in use. For LSPs with more than + one hop that decrements TTL, when TTL is decremented the "TTL + Expired" processing will be initiated. The destination address in + the range of 127/8 will direct the packet on an MPLS ping compliant + router to local delivery to the 3503 UDP port. The packet will be + processed as defined in "4.2. Receiving an MPLS Echo Request" and + "4.3. Sending an MPLS Echo Reply". + + As TTL is incremented by the ingress, traceroute mode test traffic + will reach further intermediate hops. The intended control plane + information is returned in Downstream Mappings. For each increment + of TTL another forwarding hop is exercised and further verfied by + the next hop downstream. + + At multipath (MP) branch points more than one Downstream Mapping is + applicable. Multiple Downstream Mapping TLVs are returned, + encapsulated in a single Downstream Multipath Mapping TLV. The + Multipath Exercise TLVs contained in the Downstream Multipath + Mapping TLV provide destination addresses which can be used to + exercise the forwarding for specific component paths eminating from + the MP branch point. + + At hierarchical PSC type hops, the midpoint for an LSP under test + is the ingress for an outer LSP that will be tested by further + incrementing TTL if Uniform Mode TTL ingress processing is used or + skipped transparently if Pipe Mode TTL ingress processing is used. + [***issue: The midpoint LSR needs to indicate the FEC to be added + to the FEC stack if Uniform Mode TTL will be used. This will be + the FEC of the LSP that will see the next TTL expired, at an LSR + that does not have knowledge of the LSPs under the stack. It would + appear that an extension to the Downstream Mapping TLV is needed to + support this as pointed out on the WG mailing list.***] + + Note that FSC, LSC, and TDM hierarchical hops do not decrement TTL + and therefore are always transparent to MPLS ping traceroute, + appearing as a single hop. + + When the egress of an outer LSP is reached, the normal POP + operation is performed. If the push was the initial push provided + by the ingress of the test traffic, then all lower TTLs will be one + and force TTL Expire processing. If the push was the result of + forwarding through a hierarchical PSC type hop, then the next TTL + will be greater than one for an outer LSP of more than one TTL + decrementing hop. If the egress is using Pipe Mode and outer TTL + was forced to a high value at the ingress, then TTL will be one. + If the ingress copied TTL from the inner label to the new outer + label, then TTL will be greater than one when the LSP is exit. If + so, then the outer LSP will be traced, but some hops downstream of + the egress of the hierarchical LSP will be skipped, including the + egress of the hierarchical LSP. + + Similar TTL issues apply to the egress of the bottom label where + such a label is related to a VPN or PW. If the TTL value is + greater than one but additional labels are present on the stack, + the additional labels should be processed. The explicit null label + with TTL=1 should result in local delivery of the packet. + + When the egress of the bottom label and bottom FEC is reached, no + further downstream mappings are available. The ability to extend + MPLS ping to indicate further forwarding, such as VPN or PW egress + interface or IP route can be exercised in future iterations of this + document or in companion documents which extend the TLV set. + +4.7 Operation in Ping Mode + + In ping mode, one or more LSP are being continuity tested. TTL is + set to 255 for those LSP being tested. The packet should be + forwarded using normal MPLS forwarding until the egress of the + bottom LSP under test is reached. This LSR provides the continuity + verification through its MPLS ping Echo Reply. + +4.8 Intended Use of Traceroute and Ping Mode + + Traceroute mode has two uses. It can be used prior to or after a + fault is detected by Ping Mode. + + Traceroute mode can be used to identify the current path prior to + using Ping Mode and determine if multiple paths are available and + need to be tested. For multipath destination addresses which + exercise all paths can be determined. + + Ping mode is used to provide a lower overhead test of forwarding. + If multipath is present or could arise from route change, + destination addresses determined using traceroute and/or randomly + selected addresses in the range 127/8 should be used. In the event + that multipath handling changes, randomly selected addresses should + be used in addition to destination addresses determined using + traceroute, rather than solely using those determined by + traceroute. + + If ping mode failures occur, traceroute mode can be use to isolate + the failure usually to one of two LSR (one the sending or receiving + end of the hop for which forwarding stops). What action to take on + the detection and isolation of failure is outside the scope of this + document. 5. Reliable Reply Path One of the issues that are faced with MPLS ping is to distinguish between a failure in the forward path (the MPLS path being 'pinged') and a failure in the return path. Note that this problem exists with vanilla IP ping as well. In the case of MPLS ping, it is assumed that the IP control and data planes are reliable. However, it could be that the forwarding in the return path is via an MPLS LSP. In this specification, we give two solutions for this problem. One From owner-mpls@UU.NET Wed Dec 18 15:58: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 PAA18565 for ; Wed, 18 Dec 2002 15:58:52 -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 QQntuy06031 for ; Wed, 18 Dec 2002 21:01: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 QQntux27407; Wed, 18 Dec 2002 20:56:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQntux19696 for mpls-outgoing; Wed, 18 Dec 2002 20:56:07 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 QQntux19558 for ; Wed, 18 Dec 2002 20:56:02 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 QQntux03404 for ; Wed, 18 Dec 2002 20:55:43 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 QQntuo04617 for ; Wed, 18 Dec 2002 18:44:16 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBIIii0U019210 for ; Wed, 18 Dec 2002 13:44:48 -0500 (EST) 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 NAA04926 for ; Wed, 18 Dec 2002 13:44:11 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBIIi6Q10304 for mpls@uu.net; Wed, 18 Dec 2002 13:44:06 -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 QQntuo01136 for ; Wed, 18 Dec 2002 18:41:22 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 QQntuo12703 for ; Wed, 18 Dec 2002 18:40:40 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 QQntuo14692 for ; Wed, 18 Dec 2002 18:40:40 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 QQntuo14670 for ; Wed, 18 Dec 2002 18:40:39 GMT Received: (qmail 14818 invoked by uid 104); 18 Dec 2002 18:40:38 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4237. . Clean. Processed in 0.560301 secs); 18 Dec 2002 18:40:38 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 18 Dec 2002 18:40:37 -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 gBIIeRQ19761; Wed, 18 Dec 2002 10:40:28 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Wed, 18 Dec 2002 10:40:27 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03BB1@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'curtis@fictitious.org'" Cc: Kireeti Kompella , "Gray, Eric" , mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Wed, 18 Dec 2002 10:40:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Curtis, Minor or editorial comments may be left unanswered and be raised again, but I had some pretty important comments that am not sure has been resolved. They include: 1) In L2VPN or L3VPN do we need to push both inner and outer label? if not then do people agree to add the inner label to the FEC TLV? 2) How do we return the label mapping TLV in case RSVP-TE is used for the return path? (no such object is defined for RSVP-TE) 3) What should be the time stamp format, and should it include the three time stamps similar to ICMP? 4) What happens if in an FEC stack ping, some of the FECs are confirmed and some are not? Do we need more error codes? How many more? 5) How are the ATM/FR labels supported in Label-mapping TLV? I think it is more constructive to answer protocol impacting questions rather than leave them unanswered and wait for the 7th version (4 versions under draft-pan-lsp-ping and 3 versions under name draft-ietf-mpls-lsp-ping) of the draft. Yours, -Shahram > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: Wednesday, December 18, 2002 1:12 PM > To: Shahram Davari > Cc: 'curtis@fictitious.org'; Kireeti Kompella; Gray, Eric; mpls@UU.NET > Subject: Re: Last call on LSP Ping > > > > In message > <4B6D09F3B826D411A67300D0B706EFDEB03BB0@nt-exch-yow.pmc-sierra.bc.ca > >, Shahram Davari writes: > > > > > > > > > > Before revising the document, I suggest answering all the > > > follow up comments. > > > > > > > > -Shahram > > > > > > > > > Shahram, > > > > > > I suggest not. It would be more productive to revise the document > > > reflecting the (sometimes long and largely unproductive) threads > > > rather than respond to every message. After the document > is revised, > > > provide an opportunity for new comments or for comments > to be repeated > > > if clarifications didn't help or prior (valid) comments were not > > > reflected in the revision. > > > > > > Its clear this document wasn't ready for last call, but > at least the > > > false start drew some useful dialog (and some less so) and could > > > substantially improve the document if the comments are reflected. > > > > > > Curtis > > > > > > > Up to you, but that would leave the comments raised as > unresolved. And > > people will certainly repeat those comments that have not > been responded > > to, which would then require a couple of more last calls. > > > > -Shahram > > > > > I'm not suggesting comments should be ignored. For example: > > This document describes a mechanism that can be used to detect data > plane failures in MPLS LSPs. The mechanisms described here are > intended to detect forwarding faults in an MPLS LSP which prevent > traffic from being delivered to its intended destination and > isolate the fault to the LSR at which traffic stops flowing. No > attempt is made to determine that cause of the fault or diagnose > problems any further. Enumeration of all possible fault types is > outside the scope of this document. > > Removing "simple and efficient" in the first sentence addresses a long > message voicing an objection. > > The last two sentences address some diatribe on this list about > lsp-ping != Y.1711 by agreeing that lsp-ping != Y.1711. Its a > feature. > > I think a lot of comment resulted from a poor understanding of how > traceroute mode was supposed to work. I responded earlier by saying > that "like IP tracroute" was sufficient for me but needed to be in the > document. So we'll put it there. > > There was a lot of noise on this list. If there were useful > comments that were missed they can be repeated. > > We don't want to repeat the bgp-17 experience where comments were made > and the document remained unchanged for 10 months and no one was quite > sure what had been agreed to and what was being reviewed. > > Curtis > From owner-mpls@UU.NET Wed Dec 18 15:59: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 PAA18581 for ; Wed, 18 Dec 2002 15:59:11 -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 QQntuy06244 for ; Wed, 18 Dec 2002 21:01: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 QQntux27368; Wed, 18 Dec 2002 20:56:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQntux19616 for mpls-outgoing; Wed, 18 Dec 2002 20:56: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 QQntux19500 for ; Wed, 18 Dec 2002 20:56:01 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 QQntux01163 for ; Wed, 18 Dec 2002 20:54: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 QQntux28554 for ; Wed, 18 Dec 2002 20:54:57 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 QQntux28542 for ; Wed, 18 Dec 2002 20:54:57 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBIKtTiT009661 for ; Wed, 18 Dec 2002 15:55:29 -0500 (EST) 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 PAA17214 for ; Wed, 18 Dec 2002 15:54:55 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBIKstA24618 for mpls@uu.net; Wed, 18 Dec 2002 15:54:55 -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 QQntux19340 for ; Wed, 18 Dec 2002 20:53:31 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 QQntux07629 for ; Wed, 18 Dec 2002 20:52: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 QQntux26178 for ; Wed, 18 Dec 2002 20:52:32 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 QQntux26162 for ; Wed, 18 Dec 2002 20:52:31 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBIKr3aD009310 for ; Wed, 18 Dec 2002 15:53:04 -0500 (EST) 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 PAA17021 for ; Wed, 18 Dec 2002 15:52:30 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id PAA13741 for ; Wed, 18 Dec 2002 15:52:30 -0500 (EST) Message-Id: <200212182052.PAA13741@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Wed, 18 Dec 2002 13:11:59 EST." <200212181811.NAA76043@workhorse.fictitious.org> Date: Wed, 18 Dec 2002 15:52:30 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk All - I agree with Curtis here. The authors should respin the draft incorporating as much of the comments as they can. Once that is done we will go through another full last call. I think there will be enough changes to the document that it would not be productive to address every last comment. When the new draft comes out, if folks feel that comments have not been addressed, all the rules of a normal last call will apply. ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Dec 18 16:05:10 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 QAA18717 for ; Wed, 18 Dec 2002 16:05:10 -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 QQntuy14017 for ; Wed, 18 Dec 2002 21:08:01 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 QQntuy09438; Wed, 18 Dec 2002 21:05:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQntuy08065 for mpls-outgoing; Wed, 18 Dec 2002 21:04:53 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 QQntuy07729 for ; Wed, 18 Dec 2002 21:04:36 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 QQntuy08460 for ; Wed, 18 Dec 2002 21:02: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 QQntuy06154 for ; Wed, 18 Dec 2002 21:02:22 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 QQntuy06143 for ; Wed, 18 Dec 2002 21:02:21 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBIL2rgq010901 for ; Wed, 18 Dec 2002 16:02:53 -0500 (EST) 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 QAA17920 for ; Wed, 18 Dec 2002 16:02:20 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBIL2KZ26743 for mpls@uu.net; Wed, 18 Dec 2002 16:02:20 -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 QQntux19818 for ; Wed, 18 Dec 2002 20:59: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 QQntux27551 for ; Wed, 18 Dec 2002 20: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 QQntux01753 for ; Wed, 18 Dec 2002 20:58:51 GMT Received: from father.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQntux01738 for ; Wed, 18 Dec 2002 20:58:50 GMT Received: (qmail 23150 invoked by uid 104); 18 Dec 2002 20:58:49 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4237. . Clean. Processed in 0.648929 secs); 18 Dec 2002 20:58:49 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 18 Dec 2002 20:58: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 gBIKwmQ13403; Wed, 18 Dec 2002 12:58:48 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Wed, 18 Dec 2002 12:58:48 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03BB6@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'curtis@fictitious.org'" Cc: Kireeti Kompella , "Gray, Eric" , mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Wed, 18 Dec 2002 12:58:44 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Curtis, > >, Shahram Davari writes: > > Curtis, > > > > Minor or editorial comments may be left unanswered and be raised > > again, but I had some pretty important comments that am not sure > > has been resolved. They include: > > I do sort of agree with you but if the document describes broken bits > of protocol, its not the time to look for missing commas. Agree > > I trust this list is here not because these things haven't already > been answered but as a reminder to put them in the doc. 1, 2, 4, 5 haven't been answered. > > > 1) In L2VPN or L3VPN do we need to push both inner and outer label? > > if not then do people agree to add the inner label to the FEC TLV? > > Depends on which LSP you are testing. Is the inner label semirandom > payload to exercise load split or is it the LSP actually under test. I want to test the inner LSP. Do I need to push both labels? or only the transport label? In case I push both labels there is no way to detect the ping packet at the egress. So my suggestion was to only push the top label and add the inner label to the echo-request. (This point was also raised by Eric Rosen) > > > 2) How do we return the label mapping TLV in case RSVP-TE is used > > for the return path? (no such object is defined for RSVP-TE) > > According to the instructions in section 5. Use the RESV. Add the > object specified in the doc. What's not clear? Section 3.2 describes something called Downstream Mapping TLV. This is defined for IP packets only. When the return path is the RSVP-TE, how does the downstream mapping gets encoded in RESV message? May be the answer is trace-route has no value when the return path is RSVP-TE ! or may be a Downstream mapping Object needs to be defined. > > > 3) What should be the time stamp format, and should it include the > > three time stamps similar to ICMP? > > "The time is expressed in seconds and microseconds since midnight (0 > hour), January 1, 1970". Type "man gettimeofday". Kireeti answered > that. I thought it was obvious enough but agree it is better stated. OK. > > > 4) What happens if in an FEC stack ping, some of the FECs > are confirmed > > and some are not? Do we need more error codes? How many more? > > Good question. Let me answer that one separately in another message. > It is an ommision in the document. OK. > > > 5) How are the ATM/FR labels supported in Label-mapping TLV? > > barf.^h^h^h^r Yes - good point. > I don't care^h^h^r I don't know. > > The amount of thought put into this seems proportional to the deployed > base of MPLS over ATM/FR in ISPs. > > Someone who cares^h^h^r Someone who knows more about this may have to > pointlessly beat their head against the wall ^r contribute. > > :-) [ just kidding - sort of ] > > > I think it is more constructive to answer protocol > impacting questions > > rather than leave them unanswered and wait for the 7th > version (4 versions un > > der draft-pan-lsp-ping and 3 versions under name > draft-ietf-mpls-lsp-ping) of > > the draft. > > OK. I still owe you an answer on point 4 and something intellegent on > point 5. OK. Yours, -Shahram > > > Yours, > > -Shahram > > Thanks for the reminders on these points. > > Curtis > From owner-mpls@UU.NET Wed Dec 18 16:07: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 QAA18759 for ; Wed, 18 Dec 2002 16:07:55 -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 QQntuy05759 for ; Wed, 18 Dec 2002 21:10: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 QQntuy24904; Wed, 18 Dec 2002 21:05:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQntuy07568 for mpls-outgoing; Wed, 18 Dec 2002 21:04: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 QQntuy07504 for ; Wed, 18 Dec 2002 21:04:15 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 QQntuy07540 for ; Wed, 18 Dec 2002 21:03: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 QQntuy07449 for ; Wed, 18 Dec 2002 21:03:31 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 QQntuy07437 for ; Wed, 18 Dec 2002 21:03:30 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBIL421J011067 for ; Wed, 18 Dec 2002 16:04:02 -0500 (EST) 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 QAA18024 for ; Wed, 18 Dec 2002 16:03:28 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBIL3SI27451 for mpls@uu.net; Wed, 18 Dec 2002 16:03:28 -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 QQntux19772 for ; Wed, 18 Dec 2002 20:57: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 QQntux06907 for ; Wed, 18 Dec 2002 20:56:59 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 QQntux15118 for ; Wed, 18 Dec 2002 20:56:59 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 QQntux15111 for ; Wed, 18 Dec 2002 20:56:57 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 PAA77009; Wed, 18 Dec 2002 15:55:41 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212182055.PAA77009@workhorse.fictitious.org> To: "David Allan" cc: curtis@fictitious.org, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: suggested clarification to intro parts of draft-ietf-mpls-lsp -ping-01 In-reply-to: Your message of "Wed, 18 Dec 2002 15:33:23 EST." Date: Wed, 18 Dec 2002 15:55:41 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , "Da vid Allan" writes: > 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_01C2A6D4.B61AE56E > Content-Type: text/plain; > charset="iso-8859-1" > > Hi Curtis: > > > Dave, > > > > Thanks for the comments. Lets hope Kireeti, Ping, George, et al are > > in agreement. > > ditto....still have a ways to go, mind you I agree. > > > > > > > The outer LSP seems to use uniform mode as > > described, not pipe mode > > > in order to inherit the TTL of the inner LSP. If the outer > > LSP was pipe > > > mode, then it would start with a fixed value, not copied > > from the inner LSP. > > > > The draft doesn't actually say that. > > Don't quite grok, if the outer is pipe mode, it does not copy from the inner > when the outer is pushed. My fault for not being clear on that. I meant the TTL draft, draft-ietf-mpls-ttl-04, doesn't say that you MUST put 255 in the outer TTL and in fact you are allowed to put the TTL from the lower label into the outer label. > > Plus, the ingress can think its Uniform Mode and the egress can think > > its Pipe Mode. > > True, IMHO TTL is a bit of a messy space. This would be a minor error but I thought it was worth mentioning what MPLS traceroute would do with this situation. > > IMHO - as someone formerly involved in operation at a very large ISP - > > Its almost silly to discuss diagnostics from an outside IP address > > that isn't reachable from the inside. > > Agreed, simply an artifact of overlaying disjoint networks on hardware that > uses uniform model. However, as noted above the more interesting case is > when it is not a disjoint network, uniform model is used, and I hit a tunnel > entrance. Suddently all LSRs along the TE tunnel have no knowledge of the > FEC, but the downstream mappings synch up. Like I said, there are multiple > outcomes of a single operation and knowing that matters. That's in a comment in the second part gorp I just sent. I didn't solve it, just pointed it out. > If a TE ingress implements uniform model, the downstream mapping TLV should > indicate this in the stack returned. If the TE ingress implements pipe > model, then the downstream mapping TLV should only return the current level, > else I get more errors that require lots of interpretation. There really needs to be a mapping TLV that says "I'm sticking your bits into an LSP and setting TTL such that you'll see the hops" and sends the FEC of the LSP that will be visible. > > IMHO - PHP was a mistake. One that we have to live with. > > Agree it was a mistake, not sure living with it forever is the answer. We're stuck with it. Old core routers never die. They just get moved to the edge (somewhere). > > Dave - I hope we're making forward progress. It seems to me like you > > and I are in close agreement at least on the points here. After I > > send the next part (which is related but should go in section 4, not > > here) please let me know if I missed something that should be in the > > intro part. > > I think understanding is being achieved, colleagues tell me they are > learning a lot following the thread ;-) Time will tell if we turn this into > progress... > > cheers > Dave Kireeti is out there. He just has real work to do. Regards, Curtis From owner-mpls@UU.NET Wed Dec 18 16:24: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 QAA19024 for ; Wed, 18 Dec 2002 16:24:21 -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 QQntuz28782 for ; Wed, 18 Dec 2002 21:27: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 QQntuz15189; Wed, 18 Dec 2002 21:19:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQntuz11037 for mpls-outgoing; Wed, 18 Dec 2002 21:19: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 QQntuz11026 for ; Wed, 18 Dec 2002 21:18:58 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 QQntuz08494 for ; Wed, 18 Dec 2002 21:18: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 QQntuz14073 for ; Wed, 18 Dec 2002 21:18:04 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 QQntuz14060 for ; Wed, 18 Dec 2002 21:18:03 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBILIZc2013401 for ; Wed, 18 Dec 2002 16:18:36 -0500 (EST) 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 QAA19344 for ; Wed, 18 Dec 2002 16:18:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBILI2705934 for mpls@uu.net; Wed, 18 Dec 2002 16:18: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 QQntuy10342 for ; Wed, 18 Dec 2002 21:14:12 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 QQntuy10628 for ; Wed, 18 Dec 2002 21:12: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 QQntuy22555 for ; Wed, 18 Dec 2002 21:12:58 GMT Received: from father.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQntuy22541 for ; Wed, 18 Dec 2002 21:12:57 GMT Received: (qmail 29970 invoked by uid 104); 18 Dec 2002 21:12:36 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4237. . Clean. Processed in 0.519122 secs); 18 Dec 2002 21:12:36 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 18 Dec 2002 21:12:35 -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 gBILCYQ21714; Wed, 18 Dec 2002 13:12:35 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Wed, 18 Dec 2002 13:12:34 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03BB7@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: Shahram Davari , "'curtis@fictitious.org'" Cc: "'Kireeti Kompella'" , "'Gray, Eric'" , "'mpls@UU.NET'" Subject: RE: Last call on LSP Ping Date: Wed, 18 Dec 2002 13:12:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Cusrtis, For point (5) I already suggested (in previous emails) a change to the Downstream mapping TLV as following: To support ATM (28-bit VPI/VCI) and FR (10-bit or 23-bit DLCI) may I suggest changing the size of the Downstream label to 28 bits and right justifying any ATM/FR/MPLS label in this field as following: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream IPv4 Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU | Address Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream Label |Protoco| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream Label |Protoco| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For point (1) I suggested adding the inner label to the echo-request: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Distinguisher | | (8 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW/PSN Label | Must be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Distinguisher | | (8 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 prefix | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW/PSN Label | Must be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -Shahram > > > > > 5) How are the ATM/FR labels supported in Label-mapping TLV? > > > > barf.^h^h^h^r Yes - good point. > > I don't care^h^h^r I don't know. > > > > The amount of thought put into this seems proportional to > the deployed > > base of MPLS over ATM/FR in ISPs. > > > > Someone who cares^h^h^r Someone who knows more about this > may have to > > pointlessly beat their head against the wall ^r contribute. > > > > :-) [ just kidding - sort of ] > > > > > I think it is more constructive to answer protocol > > impacting questions > > > rather than leave them unanswered and wait for the 7th > > version (4 versions un > > > der draft-pan-lsp-ping and 3 versions under name > > draft-ietf-mpls-lsp-ping) of > > > the draft. > > > > OK. I still owe you an answer on point 4 and something > intellegent on > > point 5. > > OK. > > Yours, > -Shahram > > > > > > Yours, > > > -Shahram > > > > Thanks for the reminders on these points. > > > > Curtis > > > From owner-mpls@UU.NET Wed Dec 18 16:28:58 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 QAA19093 for ; Wed, 18 Dec 2002 16:28:58 -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 QQntva15035 for ; Wed, 18 Dec 2002 21:31:58 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 QQntuz05458; Wed, 18 Dec 2002 21:26:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQntuz11987 for mpls-outgoing; Wed, 18 Dec 2002 21:26: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 QQntuz11937 for ; Wed, 18 Dec 2002 21:26: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 QQntuz22975 for ; Wed, 18 Dec 2002 21:25: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 QQntuz20379 for ; Wed, 18 Dec 2002 21:22:24 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 QQntuz20048 for ; Wed, 18 Dec 2002 21:22:11 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBILMh7J014091 for ; Wed, 18 Dec 2002 16:22:43 -0500 (EST) 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 QAA19694 for ; Wed, 18 Dec 2002 16:22:10 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBILMA407386 for mpls@uu.net; Wed, 18 Dec 2002 16:22:10 -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 QQntuz11088 for ; Wed, 18 Dec 2002 21:20:17 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 QQntuz00622 for ; Wed, 18 Dec 2002 21:19: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 QQntuz15571 for ; Wed, 18 Dec 2002 21:19:42 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 QQntuz15540 for ; Wed, 18 Dec 2002 21:19:41 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 QAA77179; Wed, 18 Dec 2002 16:18:21 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212182118.QAA77179@workhorse.fictitious.org> To: curtis@fictitious.org cc: Shahram Davari , Kireeti Kompella , "Gray, Eric" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Wed, 18 Dec 2002 15:31:55 EST." <200212182031.PAA76681@workhorse.fictitious.org> Date: Wed, 18 Dec 2002 16:18:21 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk I'm replying to myself because I gave Shahram some overly short answers. Sorry. I wanted to get out the part 2 message. > > 4) What happens if in an FEC stack ping, some of the FECs are confirmed > > and some are not? Do we need more error codes? How many more? > > Good question. Let me answer that one separately in another message. > It is an ommision in the document. There are a couple of legitimate situations where this will happen. With varying degrees of "legitimate". Some have to do with TTL processing with hierarchy. Another is situation is an LSR that doesn't decrement TTL (hopefully not on an LDP LSP that loops) or one that doesn't understand lsp-ping. What you'd see at the ingress is an error. If you resent the Echo Request without any of the prior mapping TLVs, then you'd see an Echo Reply that confirmed the FEC and gave a downstream mapping TLV. You could then continue the traceroute. Having reached the egress you have a portion of the trace for which you aren't certain how the packets go. If the pings work and the area of uncertainty is outside your administrative domain, you have to accept that delivery happens by some undisclosed magic until delivery fails to happen. If it is within your administrative domain, you can MIB query until such time as you can resolve the problem to get complete traces. > > 5) How are the ATM/FR labels supported in Label-mapping TLV? Lets try again on this one. AFAIK, an ATM or FR LSR doesn't decrement TTL. Therefore this would appear to to be a transparent couple of hops just like FSC, LSC, TDM. This might be one of those situations in point 4 above where there is a discontinuity in the sanity of the traceroute. The downstream mapping gives the next ATM LSR but incrementing TTL does to the end of the VC if TTL isn't decremented. Curtis ps - IMHO - PHP is a thing of technical elegance and beauty compared to MPLS over ATM (or anything over ATM). :-) From owner-mpls@UU.NET Wed Dec 18 16:35:38 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 QAA19270 for ; Wed, 18 Dec 2002 16:35:38 -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 QQntva15797 for ; Wed, 18 Dec 2002 21:38: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 QQntva11372; Wed, 18 Dec 2002 21:35:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQntva12848 for mpls-outgoing; Wed, 18 Dec 2002 21:35: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 QQntva12842 for ; Wed, 18 Dec 2002 21:35:30 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 QQntva19690 for ; Wed, 18 Dec 2002 21:35:10 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 QQntva06705 for ; Wed, 18 Dec 2002 21:35:10 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 QQntva06697 for ; Wed, 18 Dec 2002 21:35:09 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBILZfLq015998 for ; Wed, 18 Dec 2002 16:35:41 -0500 (EST) 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 QAA20849 for ; Wed, 18 Dec 2002 16:35:08 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBILZ8r11973 for mpls@uu.net; Wed, 18 Dec 2002 16:35:08 -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 QQntva12749 for ; Wed, 18 Dec 2002 21:33:50 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 QQntva10882 for ; Wed, 18 Dec 2002 21:33: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 QQntva08978 for ; Wed, 18 Dec 2002 21:33:10 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 QQntva08971 for ; Wed, 18 Dec 2002 21:33:10 GMT Received: (qmail 11601 invoked by uid 104); 18 Dec 2002 21:33:09 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 (uvscan: v4.1.40/v4237. Clear:. Processed in 1.239325 secs); 18 Dec 2002 21:33:09 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 18 Dec 2002 21:33:07 -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 gBILX7Q04467; Wed, 18 Dec 2002 13:33:07 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Wed, 18 Dec 2002 13:33:06 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03BB8@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'George Swallow'" , mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Wed, 18 Dec 2002 13:33:05 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk George, I think Curtis was suggesting to revise the draft, go through another round of comments, then redo the draft and last call. Since there are so many technical changes, it is very unlikely that the next revision would not require any change. -Shahram > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Wednesday, December 18, 2002 3:53 PM > To: mpls@UU.NET > Subject: Re: Last call on LSP Ping > > > All - > > I agree with Curtis here. The authors should respin the draft > incorporating as much of the comments as they can. Once that is done > we will go through another full last call. I think there will be > enough changes to the document that it would not be productive to > address every last comment. When the new draft comes out, if folks > feel that comments have not been addressed, all the rules of a normal > last call will apply. > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 497-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > From owner-mpls@UU.NET Wed Dec 18 16:48:32 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 QAA19565 for ; Wed, 18 Dec 2002 16:48:32 -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 QQntvb28128 for ; Wed, 18 Dec 2002 21:51:28 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 QQntvb17724; Wed, 18 Dec 2002 21:45:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQntvb14199 for mpls-outgoing; Wed, 18 Dec 2002 21:45: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 QQntvb14186 for ; Wed, 18 Dec 2002 21:45:23 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 QQntvb17473 for ; Wed, 18 Dec 2002 21:45: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 QQntvb17031 for ; Wed, 18 Dec 2002 21:45:07 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 QQntvb17023 for ; Wed, 18 Dec 2002 21:45:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBILjdhU017522 for ; Wed, 18 Dec 2002 16:45:39 -0500 (EST) 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 QAA21721 for ; Wed, 18 Dec 2002 16:45:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBILj5j15348 for mpls@uu.net; Wed, 18 Dec 2002 16:45:05 -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 QQntva13801 for ; Wed, 18 Dec 2002 21:43: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 QQntva09221 for ; Wed, 18 Dec 2002 21:43: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 QQntva21584 for ; Wed, 18 Dec 2002 21:43:10 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 QQntva21572 for ; Wed, 18 Dec 2002 21:43:10 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 QAA77371; Wed, 18 Dec 2002 16:41:53 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212182141.QAA77371@workhorse.fictitious.org> To: Shahram Davari cc: "'curtis@fictitious.org'" , Kireeti Kompella , "Gray, Eric" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Wed, 18 Dec 2002 12:58:44 PST." <4B6D09F3B826D411A67300D0B706EFDEB03BB6@nt-exch-yow.pmc-sierra.bc.ca> Date: Wed, 18 Dec 2002 16:41:53 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4B6D09F3B826D411A67300D0B706EFDEB03BB6@nt-exch-yow.pmc-sierra.bc.ca > > I trust this list is here not because these things haven't already > > been answered but as a reminder to put them in the doc. > > 1, 2, 4, 5 haven't been answered. 4 and 5 were deferred. > > > 1) In L2VPN or L3VPN do we need to push both inner and outer label? > > > if not then do people agree to add the inner label to the FEC TLV? > > > > Depends on which LSP you are testing. Is the inner label semirandom > > payload to exercise load split or is it the LSP actually under test. > > I want to test the inner LSP. Do I need to push both labels? or only the > transport label? In case I push both labels there is no way to detect > the ping packet at the egress. So my suggestion was to only push > the top label and add the inner label to the echo-request. > (This point was also raised by Eric Rosen) My interpretation is push both labels. Both start at TTL=1. Increment top, then next label. If they both terminate at the same egress LSR (normal for BGP VPN) then bottom TTL never gets past 1. > > > 2) How do we return the label mapping TLV in case RSVP-TE is used > > > for the return path? (no such object is defined for RSVP-TE) > > > > According to the instructions in section 5. Use the RESV. Add the > > object specified in the doc. What's not clear? > > Section 3.2 describes something called Downstream Mapping TLV. This > is defined for IP packets only. When the return path is the RSVP-TE, > how does the downstream mapping gets encoded in RESV message? May be the > answer is trace-route has no value when the return path is RSVP-TE ! or > may be a Downstream mapping Object needs to be defined. Downstream is in the forward direction so this question doesn't make sense. The Downstream Mapping TLV never refers to the return path. Curtis From owner-mpls@UU.NET Wed Dec 18 16:49:09 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 QAA19588 for ; Wed, 18 Dec 2002 16:49:08 -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 QQntvb00628 for ; Wed, 18 Dec 2002 21:51: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 QQntvb26372; Wed, 18 Dec 2002 21:49:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQntvb14617 for mpls-outgoing; Wed, 18 Dec 2002 21:48: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 QQntvb14593 for ; Wed, 18 Dec 2002 21:48:37 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 QQntvb25600 for ; Wed, 18 Dec 2002 21:47:39 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 QQntvb20797 for ; Wed, 18 Dec 2002 21:47:27 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 QQntvb20733 for ; Wed, 18 Dec 2002 21:47:25 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBILlvH5017836 for ; Wed, 18 Dec 2002 16:47:57 -0500 (EST) 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 QAA21897 for ; Wed, 18 Dec 2002 16:47:24 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBILlOs15879 for mpls@uu.net; Wed, 18 Dec 2002 16:47:24 -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 QQntvb14217 for ; Wed, 18 Dec 2002 21:45:51 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 QQntvb15331 for ; Wed, 18 Dec 2002 21:45: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 QQntvb17413 for ; Wed, 18 Dec 2002 21:45:37 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 QQntvb17406 for ; Wed, 18 Dec 2002 21:45:36 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBILjxET017553; Wed, 18 Dec 2002 16:45:59 -0500 (EST) 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 QAA21741; Wed, 18 Dec 2002 16:45:25 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id QAA18581; Wed, 18 Dec 2002 16:45:25 -0500 (EST) Message-Id: <200212182145.QAA18581@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Shahram Davari cc: "'George Swallow'" , mpls@UU.NET, swallow@cisco.com Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Wed, 18 Dec 2002 13:33:05 PST." <4B6D09F3B826D411A67300D0B706EFDEB03BB8@nt-exch-yow.pmc-sierra.bc.ca> Date: Wed, 18 Dec 2002 16:45:25 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Shahram - You're always invited to comment on any draft as soon as it is published. That will happen prior to the next meeting. If there are lots of comments, then the authors may need yet another re-spin prior to a formal last call. Historically, I haven't seen too many documents get a through review except when we issue a last call. When the next draft is published, I can send a note to the list reminding that comments are welcome, but regardless of whether a note is sent, comments to the list on any WG document that has not gone through last call are always welcome. ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Dec 18 17: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 RAA20145 for ; Wed, 18 Dec 2002 17:11:13 -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 QQntvc23012 for ; Wed, 18 Dec 2002 22:14: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 QQntvc18567; Wed, 18 Dec 2002 22:11:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQntvc04983 for mpls-outgoing; Wed, 18 Dec 2002 22:10:53 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 QQntvc04875 for ; Wed, 18 Dec 2002 22:10: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 QQntvc29419 for ; Wed, 18 Dec 2002 22:09:11 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 QQntvc18096 for ; Wed, 18 Dec 2002 22:09:10 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 QQntvc18076 for ; Wed, 18 Dec 2002 22:09:09 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBIM9f4k021159 for ; Wed, 18 Dec 2002 17:09:41 -0500 (EST) 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 RAA23814 for ; Wed, 18 Dec 2002 17:09:08 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBIM98R23572 for mpls@uu.net; Wed, 18 Dec 2002 17:09:08 -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 QQntvc04150 for ; Wed, 18 Dec 2002 22:08:24 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 QQntvc19374 for ; Wed, 18 Dec 2002 22:05: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 QQntvc13750 for ; Wed, 18 Dec 2002 22:05:22 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 QQntvc13738 for ; Wed, 18 Dec 2002 22:05:21 GMT Received: (qmail 21774 invoked by uid 104); 18 Dec 2002 22:05:20 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 (uvscan: v4.1.40/v4237. Clear:. Processed in 1.564267 secs); 18 Dec 2002 22:05:20 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 18 Dec 2002 22:05:17 -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 gBIM5CQ23643; Wed, 18 Dec 2002 14:05:12 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Wed, 18 Dec 2002 14:05:11 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03BBA@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'curtis@fictitious.org'" Cc: Kireeti Kompella , "Gray, Eric" , mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Wed, 18 Dec 2002 14:05:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > > 1, 2, 4, 5 haven't been answered. > > 4 and 5 were deferred. Thanks got the answers. > > > > > 1) In L2VPN or L3VPN do we need to push both inner and > outer label? > > > > if not then do people agree to add the inner label to > the FEC TLV? > > > > > > Depends on which LSP you are testing. Is the inner label > semirandom > > > payload to exercise load split or is it the LSP actually > under test. > > > > I want to test the inner LSP. Do I need to push both > labels? or only the > > transport label? In case I push both labels there is no way > to detect > > the ping packet at the egress. So my suggestion was to only push > > the top label and add the inner label to the echo-request. > > (This point was also raised by Eric Rosen) > > My interpretation is push both labels. Both start at TTL=1. > Increment top, then next label. If they both terminate at the same > egress LSR (normal for BGP VPN) then bottom TTL never gets past 1. What do you do for pinging the inner LSP? > > > > > 2) How do we return the label mapping TLV in case > RSVP-TE is used > > > > for the return path? (no such object is defined for RSVP-TE) > > > > > > According to the instructions in section 5. Use the > RESV. Add the > > > object specified in the doc. What's not clear? > > > > Section 3.2 describes something called Downstream Mapping TLV. This > > is defined for IP packets only. When the return path is the RSVP-TE, > > how does the downstream mapping gets encoded in RESV > message? May be the > > answer is trace-route has no value when the return path is > RSVP-TE ! or > > may be a Downstream mapping Object needs to be defined. > > Downstream is in the forward direction so this question doesn't make > sense. > > The Downstream Mapping TLV never refers to the return path. Check the last paragraph of section 4.3: If the echo request contains a Downstream Mapping TLV, the replier SHOULD compute its downstream routers and corresponding labels for the incoming label, and add Downstream Mapping TLVs for each one to the echo reply it sends back. -Shahram > > > > Curtis > From owner-mpls@UU.NET Wed Dec 18 17:12: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 RAA20202 for ; Wed, 18 Dec 2002 17:12:01 -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 QQntvc26962 for ; Wed, 18 Dec 2002 22:14:55 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 QQntvc20723; Wed, 18 Dec 2002 22:11:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQntvc05209 for mpls-outgoing; Wed, 18 Dec 2002 22:11: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 QQntvc05196 for ; Wed, 18 Dec 2002 22:11: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 QQntvc04283 for ; Wed, 18 Dec 2002 22:10:20 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 QQntvc19257 for ; Wed, 18 Dec 2002 22:10:19 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 QQntvc19240 for ; Wed, 18 Dec 2002 22:10:19 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBIMAocb021314 for ; Wed, 18 Dec 2002 17:10:51 -0500 (EST) 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 RAA23911 for ; Wed, 18 Dec 2002 17:10:17 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBIMAH423652 for mpls@uu.net; Wed, 18 Dec 2002 17:10:17 -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 QQntvc04282 for ; Wed, 18 Dec 2002 22:09:06 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 QQntvc10893 for ; Wed, 18 Dec 2002 22:08: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 QQntvc16873 for ; Wed, 18 Dec 2002 22:08:54 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 QQntvc16867 for ; Wed, 18 Dec 2002 22:08: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 RAA77430; Wed, 18 Dec 2002 17:07:34 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212182207.RAA77430@workhorse.fictitious.org> To: Shahram Davari cc: "'curtis@fictitious.org'" , "'Kireeti Kompella'" , "'Gray, Eric'" , "'mpls@UU.NET'" Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Wed, 18 Dec 2002 13:12:31 PST." <4B6D09F3B826D411A67300D0B706EFDEB03BB7@nt-exch-yow.pmc-sierra.bc.ca> Date: Wed, 18 Dec 2002 17:07:33 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4B6D09F3B826D411A67300D0B706EFDEB03BB7@nt-exch-yow.pmc-sierra.bc.ca >, Shahram Davari writes: > Cusrtis, > > For point (5) I already suggested (in previous emails) a change to the Downst > ream mapping TLV as following: > > To support ATM (28-bit VPI/VCI) and FR (10-bit or 23-bit DLCI) > may I suggest changing the size of the Downstream label to 28 bits and > right justifying any ATM/FR/MPLS label in this field as following: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Downstream IPv4 Router ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | MTU | Address Type | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Interface Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Downstream Label |Protoco| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . > . . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Downstream Label |Protoco| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > That doesn't help if the ATM LSRs don't decrement TTL. Did this change? Are ATM LSR decrementing TTL these days? The people most interested in MPLS-ping are those people operating networks. The intersection of the set of people operating networks and the set of people interested in ATM LSR might be the null set. But if adding this TLV makes satisfies the set of people interested in ATM LSR, then its fine with me to add this as the Downstream ATM Mapping TLV. > For point (1) I suggested adding the inner label to the echo-request: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Route Distinguisher | > | (8 octets) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv4 prefix | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Prefix Length | Must Be Zero | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PW/PSN Label | Must be Zero | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Route Distinguisher | > | (8 octets) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv6 prefix | > | | > | | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Prefix Length | Must Be Zero | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PW/PSN Label | Must be Zero | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IMHO - That wasn't necessary and its redundant since the next label is on the label stack and there is an entry on the FEC stack as well. > -Shahram Curtis From owner-mpls@UU.NET Wed Dec 18 17:28: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 RAA20635 for ; Wed, 18 Dec 2002 17:28:49 -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 QQntve19545 for ; Wed, 18 Dec 2002 22:31:22 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 QQntvd12261; Wed, 18 Dec 2002 22:27:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQntvd07327 for mpls-outgoing; Wed, 18 Dec 2002 22:26: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 QQntvd07322 for ; Wed, 18 Dec 2002 22:26:37 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 QQntvd04632 for ; Wed, 18 Dec 2002 22:25:50 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 QQntvd10956 for ; Wed, 18 Dec 2002 22:25:49 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 QQntvd10922 for ; Wed, 18 Dec 2002 22:25:44 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBIMQGNV023229 for ; Wed, 18 Dec 2002 17:26:16 -0500 (EST) 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 RAA25179 for ; Wed, 18 Dec 2002 17:25:42 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBIMPge00192 for mpls@uu.net; Wed, 18 Dec 2002 17:25:42 -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 QQntvd06939 for ; Wed, 18 Dec 2002 22:21: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 QQntvd25073 for ; Wed, 18 Dec 2002 22:21:16 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 QQntvd07243 for ; Wed, 18 Dec 2002 22:21:16 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 QQntvd07225 for ; Wed, 18 Dec 2002 22:21:15 GMT Received: (qmail 28895 invoked by uid 104); 18 Dec 2002 22:21:14 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4237. . Clean. Processed in 0.529728 secs); 18 Dec 2002 22:21:14 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 18 Dec 2002 22:21:13 -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 gBIMLDQ03510; Wed, 18 Dec 2002 14:21:13 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Wed, 18 Dec 2002 14:21:13 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03BBB@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'curtis@fictitious.org'" Cc: "'Kireeti Kompella'" , "'Gray, Eric'" , "'mpls@UU.NET'" Subject: RE: Last call on LSP Ping Date: Wed, 18 Dec 2002 14:21:11 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk curtis, > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: Wednesday, December 18, 2002 5:08 PM > To: Shahram Davari > Cc: 'curtis@fictitious.org'; 'Kireeti Kompella'; 'Gray, Eric'; > 'mpls@UU.NET' > Subject: Re: Last call on LSP Ping > > > > In message > <4B6D09F3B826D411A67300D0B706EFDEB03BB7@nt-exch-yow.pmc-sierra.bc.ca > >, Shahram Davari writes: > > Cusrtis, > > > > For point (5) I already suggested (in previous emails) a > change to the Downst > > ream mapping TLV as following: > > > > To support ATM (28-bit VPI/VCI) and FR (10-bit or 23-bit DLCI) > > may I suggest changing the size of the Downstream label to > 28 bits and > > right justifying any ATM/FR/MPLS label in this field as following: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Downstream IPv4 Router ID > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | MTU | Address Type | > Reserved | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Interface Address > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Downstream Label > |Protoco| > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > . > . > > . > . > > . > . > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Downstream Label > |Protoco| > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > That doesn't help if the ATM LSRs don't decrement TTL. Did this > change? Are ATM LSR decrementing TTL these days? > > The people most interested in MPLS-ping are those people operating > networks. The intersection of the set of people operating networks > and the set of people interested in ATM LSR might be the null set. > > But if adding this TLV makes satisfies the set of people interested in > ATM LSR, then its fine with me to add this as the Downstream ATM > Mapping TLV. Agree with you. Since TTL is not decremented by ATM/FR LSRs, then you can't presumably run any trace-route on them. So I retract my suggestion. > > > > For point (1) I suggested adding the inner label to the > echo-request: > > > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Route Distinguisher > | > > | (8 octets) > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | IPv4 prefix > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Prefix Length | Must Be Zero > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | PW/PSN Label | > Must be Zero | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Route Distinguisher > | > > | (8 octets) > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | IPv6 prefix > | > > | > | > > | > | > > | > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Prefix Length | Must Be Zero > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | PW/PSN Label | > Must be Zero | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > IMHO - That wasn't necessary and its redundant since the next label is > on the label stack and there is an entry on the FEC stack as well. A) In ping mode the egress LSR would in fact not look below the inner label and will forward the ping packet to the customer. B) In you trace-route example how do you know that you have reached the egress LSR? Since you may not know that, it is possible to increment the TTL of top label beyond the egress LSR and cause the ping packet to be delivered to the customer. So the inner label should not pushed for LSP-ping packet. Again my suggestion is to only push the transport label and encode the inner label in the echo-request message. -Shahram > > > -Shahram > > Curtis > From owner-mpls@UU.NET Wed Dec 18 17:34: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 RAA20708 for ; Wed, 18 Dec 2002 17:34:52 -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 QQntve21227 for ; Wed, 18 Dec 2002 22:37: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 QQntve17925; Wed, 18 Dec 2002 22:35:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQntve08196 for mpls-outgoing; Wed, 18 Dec 2002 22:35:19 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 QQntve08191 for ; Wed, 18 Dec 2002 22:35:18 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 QQntve11612 for ; Wed, 18 Dec 2002 22:34: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 QQntve23787 for ; Wed, 18 Dec 2002 22:34:00 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 QQntve23762 for ; Wed, 18 Dec 2002 22:34:00 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBIMYVbA024076 for ; Wed, 18 Dec 2002 17:34:31 -0500 (EST) 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 RAA25811 for ; Wed, 18 Dec 2002 17:33:57 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBIMXvn02711 for mpls@uu.net; Wed, 18 Dec 2002 17:33:57 -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 QQntve07878 for ; Wed, 18 Dec 2002 22:31:57 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 QQntve04861 for ; Wed, 18 Dec 2002 22:31: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 QQntve15929 for ; Wed, 18 Dec 2002 22:31:34 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 QQntve15920 for ; Wed, 18 Dec 2002 22:31:33 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 RAA77650; Wed, 18 Dec 2002 17:30:15 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212182230.RAA77650@workhorse.fictitious.org> To: Shahram Davari cc: "'curtis@fictitious.org'" , Kireeti Kompella , "Gray, Eric" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Wed, 18 Dec 2002 14:05:09 PST." <4B6D09F3B826D411A67300D0B706EFDEB03BBA@nt-exch-yow.pmc-sierra.bc.ca> Date: Wed, 18 Dec 2002 17:30:15 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4B6D09F3B826D411A67300D0B706EFDEB03BBA@nt-exch-yow.pmc-sierra.bc.ca >, Shahram Davari writes: > > > 1, 2, 4, 5 haven't been answered. > > > > 4 and 5 were deferred. > > Thanks got the answers. > > > > > > > > 1) In L2VPN or L3VPN do we need to push both inner and > > outer label? > > > > > if not then do people agree to add the inner label to > > the FEC TLV? > > > > > > > > Depends on which LSP you are testing. Is the inner label > > semirandom > > > > payload to exercise load split or is it the LSP actually > > under test. > > > > > > I want to test the inner LSP. Do I need to push both > > labels? or only the > > > transport label? In case I push both labels there is no way > > to detect > > > the ping packet at the egress. So my suggestion was to only push > > > the top label and add the inner label to the echo-request. > > > (This point was also raised by Eric Rosen) > > > > My interpretation is push both labels. Both start at TTL=1. > > Increment top, then next label. If they both terminate at the same > > egress LSR (normal for BGP VPN) then bottom TTL never gets past 1. > > What do you do for pinging the inner LSP? For ping mode, set all the labels that you want tested to TTL=255 and send. If there are any hops after the top, the packet gets delivered to the egress of the label you want tested. Did you mean traceroute? > > > > > 2) How do we return the label mapping TLV in case > > RSVP-TE is used > > > > > for the return path? (no such object is defined for RSVP-TE) > > > > > > > > According to the instructions in section 5. Use the > > RESV. Add the > > > > object specified in the doc. What's not clear? > > > > > > Section 3.2 describes something called Downstream Mapping TLV. This > > > is defined for IP packets only. When the return path is the RSVP-TE, > > > how does the downstream mapping gets encoded in RESV > > message? May be the > > > answer is trace-route has no value when the return path is > > RSVP-TE ! or > > > may be a Downstream mapping Object needs to be defined. > > > > Downstream is in the forward direction so this question doesn't make > > sense. > > > > The Downstream Mapping TLV never refers to the return path. > > Check the last paragraph of section 4.3: > > > If the echo request contains a Downstream Mapping TLV, the replier > SHOULD compute its downstream routers and corresponding labels for > the incoming label, and add Downstream Mapping TLVs for each one to > the echo reply it sends back. > > -Shahram At TTL=4, the packet goes 3 hops, then at the fourth has label=X and get a TTL Expire. The incoming label is X and the outgoing mapping is the mapping in the forward direction, ie: the direction of the LSR which is going to get the next packet when TTL=5. The router at 4 should confirm that the packet arrived with label X and that the last Downstream Mapping TLV in the request (that was originally copied from the LSR at TTL=3) is X. If the LSR at TTL=4 swaps label X for Y it puts Y in the Downstream Mapping TLV in the echo reply. The ingress copies this into the next echo request. The LSR at TTL=5 should see label Y, etc. That is the forward direction. Curtis From owner-mpls@UU.NET Wed Dec 18 17:48: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 RAA20942 for ; Wed, 18 Dec 2002 17:48:01 -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 QQntvf09746 for ; Wed, 18 Dec 2002 22:51: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 QQntve25677; Wed, 18 Dec 2002 22:43:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQntve09140 for mpls-outgoing; Wed, 18 Dec 2002 22:42:53 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 QQntve09113 for ; Wed, 18 Dec 2002 22:42:41 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 QQntve04798 for ; Wed, 18 Dec 2002 22:42: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 QQntve02657 for ; Wed, 18 Dec 2002 22:42: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 QQntve02636 for ; Wed, 18 Dec 2002 22:42:11 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBIMgg3E024963 for ; Wed, 18 Dec 2002 17:42:43 -0500 (EST) 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 RAA26423 for ; Wed, 18 Dec 2002 17:42:09 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBIMg9U05835 for mpls@uu.net; Wed, 18 Dec 2002 17:42:09 -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 QQntve08703 for ; Wed, 18 Dec 2002 22:40:09 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 QQntve25420 for ; Wed, 18 Dec 2002 22:38: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 QQntve22099 for ; Wed, 18 Dec 2002 22:38:51 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 QQntve22081 for ; Wed, 18 Dec 2002 22:38:51 GMT Received: (qmail 1530 invoked by uid 104); 18 Dec 2002 22:38:50 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 (uvscan: v4.1.40/v4237. Clear:. Processed in 1.325329 secs); 18 Dec 2002 22:38:50 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 18 Dec 2002 22:38: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 gBIMclQ13721; Wed, 18 Dec 2002 14:38:47 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Wed, 18 Dec 2002 14:38:47 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03BBC@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'curtis@fictitious.org'" Cc: Kireeti Kompella , "Gray, Eric" , mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Wed, 18 Dec 2002 14:38:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Curtis, > > > 4) What happens if in an FEC stack ping, some of the FECs > are confirmed > > > and some are not? Do we need more error codes? How many more? > > > > Good question. Let me answer that one separately in > another message. > > It is an ommision in the document. > > There are a couple of legitimate situations where this will happen. > With varying degrees of "legitimate". Some have to do with TTL > processing with hierarchy. Another is situation is an LSR that > doesn't decrement TTL (hopefully not on an LDP LSP that loops) or one > that doesn't understand lsp-ping. > > What you'd see at the ingress is an error. If you resent the Echo > Request without any of the prior mapping TLVs, then you'd see an Echo > Reply that confirmed the FEC and gave a downstream mapping TLV. You > could then continue the traceroute. Having reached the egress you > have a portion of the trace for which you aren't certain how the > packets go. If the pings work and the area of uncertainty is outside > your administrative domain, you have to accept that delivery happens > by some undisclosed magic until delivery fails to happen. If it is > within your administrative domain, you can MIB query until such time > as you can resolve the problem to get complete traces. What you just said is true and acceptable for when some of the labels in a Downstream mapping TLV (DM TLV) are confirmed and some are not. In that case, sending an echo-request without DM TLV will be successful and will give you the downstream mapping. My suggestion is changing the description of error code 7 to: Replying router is one of the "Downstream Routers", but its mapping for this FEC are the given label stack." My concern was more on pinging Traget FEC stack. Let's say one of the FECs in the stack is confirmed but other ones are not confirmed. What is the error reporting procedure? My suggestion is changing the description of error code 4 to: " Replying router has no mapping for one or more FECs in the Target FEC stack" > > > > 5) How are the ATM/FR labels supported in Label-mapping TLV? > > > Lets try again on this one. > > AFAIK, an ATM or FR LSR doesn't decrement TTL. Therefore this would > appear to to be a transparent couple of hops just like FSC, LSC, TDM. Agree. -Shahram > > This might be one of those situations in point 4 above where there is > a discontinuity in the sanity of the traceroute. The downstream > mapping gives the next ATM LSR but incrementing TTL does to the end of > the VC if TTL isn't decremented. > > Curtis > > ps - IMHO - PHP is a thing of technical elegance and beauty compared > to MPLS over ATM (or anything over ATM). :-) > From owner-mpls@UU.NET Wed Dec 18 17:55:26 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 RAA21042 for ; Wed, 18 Dec 2002 17:55:26 -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 QQntvf18257 for ; Wed, 18 Dec 2002 22:57: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 QQntvf13257; Wed, 18 Dec 2002 22:55:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQntvf10895 for mpls-outgoing; Wed, 18 Dec 2002 22:54: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 QQntvf10890 for ; Wed, 18 Dec 2002 22:54: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 QQntvf02988 for ; Wed, 18 Dec 2002 22:53: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 QQntvf12204 for ; Wed, 18 Dec 2002 22:53:25 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 QQntvf12199 for ; Wed, 18 Dec 2002 22:53:24 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBIMruFU026064 for ; Wed, 18 Dec 2002 17:53:57 -0500 (EST) 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 RAA27183 for ; Wed, 18 Dec 2002 17:53:23 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBIMrNA10796 for mpls@uu.net; Wed, 18 Dec 2002 17:53:23 -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 QQntvf10729 for ; Wed, 18 Dec 2002 22:51:53 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 QQntvf20106 for ; Wed, 18 Dec 2002 22:50: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 QQntvf06385 for ; Wed, 18 Dec 2002 22:50:51 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 QQntvf06369 for ; Wed, 18 Dec 2002 22:50:50 GMT Received: (qmail 13353 invoked by uid 104); 18 Dec 2002 22:50:49 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4237. . Clean. Processed in 0.521796 secs); 18 Dec 2002 22:50:49 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 18 Dec 2002 22:50: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 gBIMolQ20947; Wed, 18 Dec 2002 14:50:47 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Wed, 18 Dec 2002 14:50:47 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03BBD@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'curtis@fictitious.org'" Cc: Kireeti Kompella , "Gray, Eric" , mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Wed, 18 Dec 2002 14:50:46 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Curtis, > > > My interpretation is push both labels. Both start at TTL=1. > > > Increment top, then next label. If they both terminate > at the same > > > egress LSR (normal for BGP VPN) then bottom TTL never gets past 1. > > > > What do you do for pinging the inner LSP? > > For ping mode, set all the labels that you want tested to TTL=255 and > send. If there are any hops after the top, the packet gets delivered > to the egress of the label you want tested. > > Did you mean traceroute? No I meant ping. But I am not satisfied with your answer. Let's assume we have a PWE3 connection, and the user packets are sent with 2 labels (A & B). Label A is the PW label and label B is the transport label. The egress LSR checks the transport label and terminates it and forwards the packet based on the PW label. It never checks the S-bit. If LSP-ping has the same label stack (A&B) then the LSP-ping will be delivered to the customer. Don't you think so? If the LSR at TTL=4 swaps label X for Y it > puts Y in the Downstream Mapping TLV in the echo reply. T Here is my point. How do you put the Downstream mapping TLV in the RESV message if the return path is via control-plane? -Shahram From owner-mpls@UU.NET Wed Dec 18 18:04: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 SAA21300 for ; Wed, 18 Dec 2002 18:04:39 -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 QQntvg29581 for ; Wed, 18 Dec 2002 23:07:32 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 QQntvg19114; Wed, 18 Dec 2002 23:01:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQntvg16855 for mpls-outgoing; Wed, 18 Dec 2002 23:01:15 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 QQntvg16446 for ; Wed, 18 Dec 2002 23:01:08 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 QQntvg02837 for ; Wed, 18 Dec 2002 23:00: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 QQntvg22390 for ; Wed, 18 Dec 2002 23:00:19 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 QQntvg22301 for ; Wed, 18 Dec 2002 23:00:17 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBIN0k4i026831 for ; Wed, 18 Dec 2002 18:00:46 -0500 (EST) 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 SAA27667 for ; Wed, 18 Dec 2002 18:00:13 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBIN0DR12624 for mpls@uu.net; Wed, 18 Dec 2002 18:00:13 -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 QQntvf11368 for ; Wed, 18 Dec 2002 22:58:33 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 QQntvf20075 for ; Wed, 18 Dec 2002 22:58: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 QQntvf17999 for ; Wed, 18 Dec 2002 22:57:52 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 QQntvf17985 for ; Wed, 18 Dec 2002 22:57:51 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 RAA77860; Wed, 18 Dec 2002 17:56:32 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212182256.RAA77860@workhorse.fictitious.org> To: Shahram Davari cc: "'curtis@fictitious.org'" , "'Kireeti Kompella'" , "'Gray, Eric'" , "'mpls@UU.NET'" Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Wed, 18 Dec 2002 14:21:11 PST." <4B6D09F3B826D411A67300D0B706EFDEB03BBB@nt-exch-yow.pmc-sierra.bc.ca> Date: Wed, 18 Dec 2002 17:56:32 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4B6D09F3B826D411A67300D0B706EFDEB03BBB@nt-exch-yow.pmc-sierra.bc.ca >, Shahram Davari writes: > > A) In ping mode the egress LSR would in fact not look below the inner > label and will forward the ping packet to the customer. That was the point of the discussion that Alia started a while ago on "S" bit handling and/or TTL expire on the TTL=1 labels. The "S" bit would never be clear on a PW label except MPLS ping. > B) In you trace-route example how do you know that you have reached the > egress LSR? Since you may not know that, it is possible to increment the > TTL of top label beyond the egress LSR and cause the ping packet to be delive > red to the customer. I'll send that question to the authors. I'll give my guess. For the common case where the LDP and PW labels terminate at the same router send return code 3 "Replying router is an egress for the FEC". Its not clear what you do for the case where the top label is popped but other FECs in the label stack continue. One clue for the ingress is that the responding router address is equal to the top "RSVP IPv4 Session" IPv4 tunnel end point address. It would help to have a stack of "FEC Egress Reached" TLV in the Echo Reply so the ingress has a clear indication that it is time to take a FEC TLV off the top of the FEC stack before incrementing TTL. > So the inner label should not pushed for LSP-ping packet. Again my suggestion > is to only push the transport label and encode the inner label in the > echo-request message. The set of labels is supposed to match the FEC stack. If you just wanted to confirm the path the transit LSP, then optionally add the next label but don't include the next FEC. If you want to confirm the next label, you must add that label and add that FEC. If you don't add the label, at a MP branch point your packet may take a different path than the VPN label you intend to test for label based MP. Curtis From owner-mpls@UU.NET Wed Dec 18 18:09:08 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 SAA21469 for ; Wed, 18 Dec 2002 18:09:08 -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 QQntvg27067 for ; Wed, 18 Dec 2002 23:12:01 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 QQntvg23395; Wed, 18 Dec 2002 23:09:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQntvg00655 for mpls-outgoing; Wed, 18 Dec 2002 23:09:16 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 QQntvg00641 for ; Wed, 18 Dec 2002 23:09:13 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 QQntvg01802 for ; Wed, 18 Dec 2002 23:09:09 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 QQntvg02781 for ; Wed, 18 Dec 2002 23:09:08 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 QQntvg02777 for ; Wed, 18 Dec 2002 23:09:08 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBIN9eOL027696 for ; Wed, 18 Dec 2002 18:09:40 -0500 (EST) 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 SAA28232 for ; Wed, 18 Dec 2002 18:09:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBIN96i16193 for mpls@uu.net; Wed, 18 Dec 2002 18:09:06 -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 QQntvg00366 for ; Wed, 18 Dec 2002 23:07: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 QQntvg01983 for ; Wed, 18 Dec 2002 23:07:11 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 QQntvg28303 for ; Wed, 18 Dec 2002 23:06:49 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 QQntvg28223 for ; Wed, 18 Dec 2002 23:06:47 GMT Received: (qmail 9536 invoked by uid 104); 18 Dec 2002 23:06:46 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 (uvscan: v4.1.40/v4237. Clear:. Processed in 1.060139 secs); 18 Dec 2002 23:06:46 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 18 Dec 2002 23:06:44 -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 gBIN6iQ00593; Wed, 18 Dec 2002 15:06:44 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Wed, 18 Dec 2002 15:06:43 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03BC1@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'curtis@fictitious.org'" Cc: "'Kireeti Kompella'" , "'mpls@UU.NET'" Subject: RE: Last call on LSP Ping Date: Wed, 18 Dec 2002 15:06:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Curtis, Could you please explain in simple terms how can one check the inner LSP's connectivity in L3VPN and L2VPN? Consider the case where no VRF table lookup is done at the egress. Thanks, -Shahram From owner-mpls@UU.NET Wed Dec 18 18:41:00 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 SAA22115 for ; Wed, 18 Dec 2002 18:41:00 -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 QQntvi03478 for ; Wed, 18 Dec 2002 23:43: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 QQntvi28915; Wed, 18 Dec 2002 23:41:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQntvi04438 for mpls-outgoing; Wed, 18 Dec 2002 23:41:16 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 QQntvi04433 for ; Wed, 18 Dec 2002 23:41:14 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 QQntvi14840 for ; Wed, 18 Dec 2002 23:40:14 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 QQntvi19769 for ; Wed, 18 Dec 2002 23:40:13 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 QQntvi19688 for ; Wed, 18 Dec 2002 23:40:09 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBINeeI2000551 for ; Wed, 18 Dec 2002 18:40:41 -0500 (EST) 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 SAA00094 for ; Wed, 18 Dec 2002 18:40:07 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBINe7V22072 for mpls@uu.net; Wed, 18 Dec 2002 18:40:07 -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 QQntvi04229 for ; Wed, 18 Dec 2002 23:39:02 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 QQntvi14118 for ; Wed, 18 Dec 2002 23:38: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 QQntvi24587 for ; Wed, 18 Dec 2002 23:38:49 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 QQntvi24575 for ; Wed, 18 Dec 2002 23:38:48 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 SAA78260; Wed, 18 Dec 2002 18:37:32 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212182337.SAA78260@workhorse.fictitious.org> To: Shahram Davari cc: "'curtis@fictitious.org'" , "'Kireeti Kompella'" , "'mpls@UU.NET'" Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Wed, 18 Dec 2002 15:06:41 PST." <4B6D09F3B826D411A67300D0B706EFDEB03BC1@nt-exch-yow.pmc-sierra.bc.ca> Date: Wed, 18 Dec 2002 18:37:32 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4B6D09F3B826D411A67300D0B706EFDEB03BC1@nt-exch-yow.pmc-sierra.bc.ca >, Shahram Davari writes: > Curtis, > > Could you please explain in simple terms how can one check the > inner LSP's connectivity in L3VPN and L2VPN? Consider the case > where no VRF table lookup is done at the egress. > > Thanks, > -Shahram You'll have to first explain to me how you do a VPN without doing a VRF lookup. The LSP for normal VPN traffic can't just terminate on the loopback. The last label normally drives the VRF lookup. If "S" is clear or TTL expires, then the packet is directed to the loopback to IP and UDP port 3503 for MPLS-ping processing. MPLS-ping can only check the VRF lookup in the control plane. This was the point of the statement "Since the MPLS-ping 'echo request' packets are extracted no further downstream than the egress LSR, faults at the egress in decapsulating and directing traffic further are not detected." that now appears in the fourth paragraph of "1. Introduction". Did I miss something? Curtis From owner-mpls@UU.NET Wed Dec 18 18:43:06 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 SAA22157 for ; Wed, 18 Dec 2002 18:43:06 -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 QQntvj07285 for ; Wed, 18 Dec 2002 23:46:03 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 QQntvi01918; Wed, 18 Dec 2002 23:43:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQntvi04500 for mpls-outgoing; Wed, 18 Dec 2002 23:42:16 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 QQntvi04482 for ; Wed, 18 Dec 2002 23:41:56 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 QQntvi10104 for ; Wed, 18 Dec 2002 23:39: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 QQntvi18982 for ; Wed, 18 Dec 2002 23:39:27 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 QQntvi18971 for ; Wed, 18 Dec 2002 23:39:26 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBINVdYt029874 for ; Wed, 18 Dec 2002 18:31:40 -0500 (EST) 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 SAA29545 for ; Wed, 18 Dec 2002 18:31:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBINV6p21292 for mpls@uu.net; Wed, 18 Dec 2002 18:31:06 -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 QQntvi03592 for ; Wed, 18 Dec 2002 23:30:06 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 QQntvh29607 for ; Wed, 18 Dec 2002 23:29:43 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 QQntvh12101 for ; Wed, 18 Dec 2002 23:29:43 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 QQntvh12091 for ; Wed, 18 Dec 2002 23:29:42 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 SAA78121; Wed, 18 Dec 2002 18:28:23 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212182328.SAA78121@workhorse.fictitious.org> To: Shahram Davari cc: "'curtis@fictitious.org'" , Kireeti Kompella , "Gray, Eric" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Wed, 18 Dec 2002 14:50:46 PST." <4B6D09F3B826D411A67300D0B706EFDEB03BBD@nt-exch-yow.pmc-sierra.bc.ca> Date: Wed, 18 Dec 2002 18:28:23 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4B6D09F3B826D411A67300D0B706EFDEB03BBD@nt-exch-yow.pmc-sierra.bc.ca >, Shahram Davari writes: > Curtis, > > > > > > > My interpretation is push both labels. Both start at TTL=1. > > > > Increment top, then next label. If they both terminate > > at the same > > > > egress LSR (normal for BGP VPN) then bottom TTL never gets past 1. > > > > > > What do you do for pinging the inner LSP? > > > > For ping mode, set all the labels that you want tested to TTL=255 and > > send. If there are any hops after the top, the packet gets delivered > > to the egress of the label you want tested. > > > > Did you mean traceroute? > > > No I meant ping. But I am not satisfied with your answer. Let's assume > we have a PWE3 connection, and the user packets are sent with 2 labels (A & B > ). > Label A is the PW label and label B is the transport label. The egress LSR ch > ecks the transport label and terminates it and forwards the packet based on t > he > PW label. It never checks the S-bit. If LSP-ping has the same label stack (A& > B) > then the LSP-ping will be delivered to the customer. Don't you think so? That would happen and it would not be a good thing. For a VPN the customer would get a null label packet with MPLS ping payload. For PW, there would be junk and a framing error at some level. > If the LSR at TTL=4 swaps label X for Y it > > puts Y in the Downstream Mapping TLV in the echo reply. T > > Here is my point. How do you put the Downstream mapping TLV in the > RESV message if the return path is via control-plane? Good point. You can't. For some reason I thought there was a place for TLVs in this object. Looks like you can just confirm that the packet reached a router at TTL=x and how long it took. My guess on why this is so is the RSVP object size is too limited to carry a full set of MPLS-ping TLVs. The more I look at "reply via the control plane", the less useful it looks. Perhaps one of the authors can tell us why we can't just drop it. > -Shahram Curtis From owner-mpls@UU.NET Wed Dec 18 21:08:23 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 VAA25811 for ; Wed, 18 Dec 2002 21:08:22 -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 QQntvs10428 for ; Thu, 19 Dec 2002 02:11: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 QQntvs06734; Thu, 19 Dec 2002 02:09:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQntvs11226 for mpls-outgoing; Thu, 19 Dec 2002 02:08: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 QQntvs11203 for ; Thu, 19 Dec 2002 02:08: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 QQntvs16645 for ; Thu, 19 Dec 2002 02:08: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 QQntvs11258 for ; Thu, 19 Dec 2002 02:08:08 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 QQntvs11237 for ; Thu, 19 Dec 2002 02:08:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBJ28dnR013098 for ; Wed, 18 Dec 2002 21:08:39 -0500 (EST) 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 VAA07723 for ; Wed, 18 Dec 2002 21:08:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBJ285g05793 for mpls@uu.net; Wed, 18 Dec 2002 21:08:05 -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 QQntvs10909 for ; Thu, 19 Dec 2002 02:06: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 QQntvs28605 for ; Thu, 19 Dec 2002 02:06: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 QQntvs05939 for ; Thu, 19 Dec 2002 02:06:39 GMT Received: from sj-msg-core-3.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-3.cisco.com [171.70.157.152]) id QQntvs05935 for ; Thu, 19 Dec 2002 02:06:38 GMT Received: from BORA-W2K1.cisco.com (dhcp-171-69-39-81.cisco.com [171.69.39.81]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gBJ262jT006489; Wed, 18 Dec 2002 18:06:02 -0800 (PST) Message-Id: <4.3.2.7.2.20021218180450.04857018@mira-sjc5-9.cisco.com> X-Sender: bora@mira-sjc5-9.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 18 Dec 2002 18:05:08 -0800 To: curtis@fictitious.org From: Bora Akyol Subject: Re: suggested clarification to intro parts of draft-ietf-mpls-lsp -ping-01 Cc: "David Allan" , mpls@UU.NET In-Reply-To: <200212182055.PAA77009@workhorse.fictitious.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 03:55 PM 12/18/2002 -0500, Curtis Villamizar wrote: >My fault for not being clear on that. > >I meant the TTL draft, draft-ietf-mpls-ttl-04, doesn't say that you >MUST put 255 in the outer TTL and in fact you are allowed to put the >TTL from the lower label into the outer label. This in fact is correct. Bora From owner-mpls@UU.NET Wed Dec 18 21:10: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 VAA25853 for ; Wed, 18 Dec 2002 21:10:47 -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 QQntvs14321 for ; Thu, 19 Dec 2002 02:13:13 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 QQntvs07432; Thu, 19 Dec 2002 02:09:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQntvs11250 for mpls-outgoing; Thu, 19 Dec 2002 02:08:43 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 QQntvs11209 for ; Thu, 19 Dec 2002 02:08: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 QQntvs16665 for ; Thu, 19 Dec 2002 02:08: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 QQntvs11268 for ; Thu, 19 Dec 2002 02:08:09 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 QQntvs11252 for ; Thu, 19 Dec 2002 02:08:08 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBJ28dbi013100 for ; Wed, 18 Dec 2002 21:08:40 -0500 (EST) 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 VAA07729 for ; Wed, 18 Dec 2002 21:08:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBJ286b05803 for mpls@uu.net; Wed, 18 Dec 2002 21:08:06 -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 QQntvs10910 for ; Thu, 19 Dec 2002 02:06:53 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 QQntvs25491 for ; Thu, 19 Dec 2002 02:05: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 QQntvs05093 for ; Thu, 19 Dec 2002 02:05:19 GMT Received: from sj-msg-core-3.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-3.cisco.com [171.70.157.152]) id QQntvs05087 for ; Thu, 19 Dec 2002 02:05:19 GMT Received: from BORA-W2K1.cisco.com (dhcp-171-69-39-81.cisco.com [171.69.39.81]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gBJ24WjT005330; Wed, 18 Dec 2002 18:04:32 -0800 (PST) Message-Id: <4.3.2.7.2.20021218180224.046d5888@mira-sjc5-9.cisco.com> X-Sender: bora@mira-sjc5-9.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 18 Dec 2002 18:03:38 -0800 To: curtis@fictitious.org From: Bora Akyol Subject: Re: suggested clarification to intro parts of draft-ietf-mpls-lsp -ping-01 Cc: "David Allan" , mpls@UU.NET In-Reply-To: <200212182005.PAA76605@workhorse.fictitious.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 03:05 PM 12/18/2002 -0500, Curtis Villamizar wrote: > > The outer LSP seems to use uniform mode as described, not pipe mode > > in order to inherit the TTL of the inner LSP. If the outer LSP was pipe > > mode, then it would start with a fixed value, not copied from the inner > LSP. > >The draft doesn't actually say that. > >Plus, the ingress can think its Uniform Mode and the egress can think >its Pipe Mode. I think if ingress thinks uniform and egress thinks pipe, the operator has a serious misconfiguration issue. In general pipe mode hides its intermediary hops from the first layer of the hierarchy. Bora From owner-mpls@UU.NET Wed Dec 18 21:37:58 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 VAA26627 for ; Wed, 18 Dec 2002 21:37:58 -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 QQntvu17300 for ; Thu, 19 Dec 2002 02:40: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 QQntvu06063; Thu, 19 Dec 2002 02:34:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQntvu14741 for mpls-outgoing; Thu, 19 Dec 2002 02:34:11 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 QQntvu14730 for ; Thu, 19 Dec 2002 02:34:03 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 QQntvu09564 for ; Thu, 19 Dec 2002 02:33:40 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 QQntvf19217 for ; Wed, 18 Dec 2002 22:58:32 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBIMx3De026630 for ; Wed, 18 Dec 2002 17:59:04 -0500 (EST) 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 RAA27530 for ; Wed, 18 Dec 2002 17:58:30 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBIMwUB11979 for mpls@uu.net; Wed, 18 Dec 2002 17:58:30 -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 QQntvf11190 for ; Wed, 18 Dec 2002 22:56:46 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 QQntvf03177 for ; Wed, 18 Dec 2002 22:56: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 QQntvf14170 for ; Wed, 18 Dec 2002 22:56:27 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 QQntvf14156 for ; Wed, 18 Dec 2002 22:56:26 GMT Received: (qmail 6449 invoked by uid 104); 18 Dec 2002 22:56:25 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 (uvscan: v4.1.40/v4237. Clear:. Processed in 1.36585 secs); 18 Dec 2002 22:56:25 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 18 Dec 2002 22:56:23 -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 gBIMuNQ24244; Wed, 18 Dec 2002 14:56:23 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Wed, 18 Dec 2002 14:56:23 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03BBF@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: Shahram Davari , "'curtis@fictitious.org'" Cc: Kireeti Kompella , "Gray, Eric" , mpls@UU.NET Subject: RE: Last call on LSP Ping Date: Wed, 18 Dec 2002 14:56:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk A minor correction: Change this: > Replying router is one of the "Downstream Routers", but its > mapping for this FEC are the given label stack." > to: "Replying router is one of the Downstream Routers, but its mapping for this FEC are not the given label stack." -Shahram From owner-mpls@UU.NET Wed Dec 18 22:31: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 WAA27692 for ; Wed, 18 Dec 2002 22:31: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 QQntvy16761 for ; Thu, 19 Dec 2002 03:34: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 QQntvy14085; Thu, 19 Dec 2002 03:33:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQntvy08448 for mpls-outgoing; Thu, 19 Dec 2002 03:32:51 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 QQntvy08441 for ; Thu, 19 Dec 2002 03:32:46 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 QQntvy10503 for ; Thu, 19 Dec 2002 03:32: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 QQntvy14159 for ; Thu, 19 Dec 2002 03:32:09 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 QQntvy14144 for ; Thu, 19 Dec 2002 03:32:08 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBJ3WeEN018963 for ; Wed, 18 Dec 2002 22:32:40 -0500 (EST) 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 WAA11333 for ; Wed, 18 Dec 2002 22:32:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBJ3W6M17826 for mpls@uu.net; Wed, 18 Dec 2002 22:32:06 -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 QQntvy08201 for ; Thu, 19 Dec 2002 03:30: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 QQntvy12827 for ; Thu, 19 Dec 2002 03:30: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 QQntvy12601 for ; Thu, 19 Dec 2002 03:30:18 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 QQntvy12589 for ; Thu, 19 Dec 2002 03:30:17 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 WAA78913; Wed, 18 Dec 2002 22:28:52 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212190328.WAA78913@workhorse.fictitious.org> To: Bora Akyol cc: curtis@fictitious.org, "David Allan" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: suggested clarification to intro parts of draft-ietf-mpls-lsp -ping-01 In-reply-to: Your message of "Wed, 18 Dec 2002 18:03:38 PST." <4.3.2.7.2.20021218180224.046d5888@mira-sjc5-9.cisco.com> Date: Wed, 18 Dec 2002 22:28:52 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4.3.2.7.2.20021218180224.046d5888@mira-sjc5-9.cisco.com>, Bora Akyo l writes: > At 03:05 PM 12/18/2002 -0500, Curtis Villamizar wrote: > > > The outer LSP seems to use uniform mode as described, not pipe mod > e > > > in order to inherit the TTL of the inner LSP. If the outer LSP was pipe > > > mode, then it would start with a fixed value, not copied from the inner > > LSP. > > > >The draft doesn't actually say that. > > > >Plus, the ingress can think its Uniform Mode and the egress can think > >its Pipe Mode. > > I think if ingress thinks uniform and egress thinks pipe, the operator has > a serious misconfiguration issue. In general pipe mode hides its > intermediary hops from the first layer of the hierarchy. > > Bora This exercise is *about* finding errors. Right? Providers *do* make configuration errors and it is a good thing when tools help them identify some of the more subtle errors. Curtis From owner-mpls@UU.NET Thu Dec 19 14:39: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 OAA24900 for ; Thu, 19 Dec 2002 14:39: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 QQntyk23702 for ; Thu, 19 Dec 2002 19:42:00 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 QQntyk16355; Thu, 19 Dec 2002 19:37:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQntyk00806 for mpls-outgoing; Thu, 19 Dec 2002 19:37: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 QQntyk00801 for ; Thu, 19 Dec 2002 19:37: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 QQntyk11133 for ; Thu, 19 Dec 2002 19:36: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 QQntyk25660 for ; Thu, 19 Dec 2002 19:36:25 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 QQntyk25654 for ; Thu, 19 Dec 2002 19:36:25 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBJJavP9026880 for ; Thu, 19 Dec 2002 14:36:57 -0500 (EST) 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 OAA10937 for ; Thu, 19 Dec 2002 14:36:23 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBJJaNw06512 for mpls@uu.net; Thu, 19 Dec 2002 14:36:23 -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 QQntyk00637 for ; Thu, 19 Dec 2002 19:34: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 QQntyk28710 for ; Thu, 19 Dec 2002 19:34:01 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 QQntyk14903 for ; Thu, 19 Dec 2002 19:34:01 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 QQntyk14864 for ; Thu, 19 Dec 2002 19:34:00 GMT Received: (qmail 24845 invoked by uid 104); 19 Dec 2002 19:33:59 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4238. . Clean. Processed in 0.522158 secs); 19 Dec 2002 19:33:59 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 19 Dec 2002 19:33:58 -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 gBJJXcQ10118; Thu, 19 Dec 2002 11:33:48 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Thu, 19 Dec 2002 11:33:38 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03BC6@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'curtis@fictitious.org'" Cc: "'Kireeti Kompella'" , "'mpls@UU.NET'" Subject: RE: Last call on LSP Ping Date: Thu, 19 Dec 2002 11:33:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Curtis, Let me explain my point a bit more. This has already been stated by Alia. RFC2547bis says: "Suppose that a PE has assigned label L to route R, and has distributed this label mapping via BGP. If R is an aggregate of a set of routes in the VRF, the PE will know that packets from the backbone which arrive with this label must have their destination addresses looked up in a VRF. When the PE looks up the label in its Label Information Base, it learns which VRF must be used. On the other hand, if R is not an aggregate, then when the PE looks up the label, it learns the egress attachment circuit, as well as the encapsulation header for the packet. In this case, no lookup in the VRF is done. We would expect that the most common case would be the case where the route is NOT an aggregate." As you can see no VRF lookup is a possible approach for L3VPN. The following text assumes no VRF lookup at the egress PE: Based on the example in the draft, LSP ping could send an IP packet with the specific route's VPN label and then the PSN's label. However, the egress LER would look at the specific route's VPN label and immediately forward the packet, whatever it contained, to the egress attachment circuit. Please note that since the LSP is an IP-carrying LSP, based on the draft no explicit null is required and therefore S=1 for the bottom most label. My question is what criteria is used at the egress LSR to identify and terminate LSP-ping packets? There might be 3 solutions: 1) Use explicit null label even though the traffic is IP, and detect LSP-ping packets from S=0 in the VPN label. This may require HW change, because current implementations don't look at S-bit. 2) Only push the PSN label, and encode the VPN label in the echo-request. 3) In echo-request set the TTL=0 for VPN label, and detect the LSP-ping by sending the TTL=0 packets to the OAM module. This may also require HW change as I am not sure current implementations check the TTL of the VPN label. My suggestion was the 2nd one. What method do you suggest? Thanks, -Shahram > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: Wednesday, December 18, 2002 6:38 PM > To: Shahram Davari > Cc: 'curtis@fictitious.org'; 'Kireeti Kompella'; 'mpls@UU.NET' > Subject: Re: Last call on LSP Ping > > > > In message > <4B6D09F3B826D411A67300D0B706EFDEB03BC1@nt-exch-yow.pmc-sierra.bc.ca > >, Shahram Davari writes: > > Curtis, > > > > Could you please explain in simple terms how can one check the > > inner LSP's connectivity in L3VPN and L2VPN? Consider the case > > where no VRF table lookup is done at the egress. > > > > Thanks, > > -Shahram > > You'll have to first explain to me how you do a VPN without doing a > VRF lookup. The LSP for normal VPN traffic can't just terminate on > the loopback. The last label normally drives the VRF lookup. If "S" > is clear or TTL expires, then the packet is directed to the loopback > to IP and UDP port 3503 for MPLS-ping processing. MPLS-ping can only > check the VRF lookup in the control plane. This was the point of the > statement "Since the MPLS-ping 'echo request' packets are extracted no > further downstream than the egress LSR, faults at the egress in > decapsulating and directing traffic further are not detected." that > now appears in the fourth paragraph of "1. Introduction". > > Did I miss something? > > Curtis > From owner-mpls@UU.NET Thu Dec 19 15:53:06 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 PAA26815 for ; Thu, 19 Dec 2002 15:53:05 -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 QQntyp07123 for ; Thu, 19 Dec 2002 20:56: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 QQntyp02978; Thu, 19 Dec 2002 20:54:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQntyp25969 for mpls-outgoing; Thu, 19 Dec 2002 20:53:42 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 QQntyp25964 for ; Thu, 19 Dec 2002 20:53:33 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 QQntyp15644 for ; Thu, 19 Dec 2002 20:53:09 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 QQntyp01961 for ; Thu, 19 Dec 2002 20:53:09 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 QQntyp01956 for ; Thu, 19 Dec 2002 20:53:08 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 gBJKqej16413; Thu, 19 Dec 2002 15:52:40 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Dec 2002 15:52:41 -0500 Message-ID: From: "David Allan" To: Bora Akyol , curtis@fictitious.org Cc: mpls@UU.NET Subject: RE: suggested clarification to intro parts of draft-ietf-mpls-lsp -ping-01 Date: Thu, 19 Dec 2002 15:52:30 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Bora: Do I understand this correctly, in pipe mode, you MAY copy the TTL from inner to outer LSP at the ingress? But as it is pipe mode, you would not copy TTL back at the egress? thx Dave > -----Original Message----- > From: Bora Akyol [mailto:bora@cisco.com] > Sent: Wednesday, December 18, 2002 9:05 PM > To: curtis@fictitious.org > Cc: Allan, David [CAR:NS00:EXCH]; mpls@UU.NET > Subject: Re: suggested clarification to intro parts of > draft-ietf-mpls-lsp -ping-01 > > > At 03:55 PM 12/18/2002 -0500, Curtis Villamizar wrote: > >My fault for not being clear on that. > > > >I meant the TTL draft, draft-ietf-mpls-ttl-04, doesn't say that you > >MUST put 255 in the outer TTL and in fact you are allowed to put the > >TTL from the lower label into the outer label. > > This in fact is correct. > > Bora > > From owner-mpls@UU.NET Thu Dec 19 16:09: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 QAA27182 for ; Thu, 19 Dec 2002 16:09:25 -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 QQntyq14779 for ; Thu, 19 Dec 2002 21:12:23 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 QQntyq08933; Thu, 19 Dec 2002 21:09:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQntyq14665 for mpls-outgoing; Thu, 19 Dec 2002 21:08: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 QQntyq14644 for ; Thu, 19 Dec 2002 21:08: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 QQntyq22436 for ; Thu, 19 Dec 2002 21:06: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 QQntyq06903 for ; Thu, 19 Dec 2002 21:06:30 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 QQntyq06895 for ; Thu, 19 Dec 2002 21:06:30 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBJL6nLL021861 for ; Thu, 19 Dec 2002 16:06:50 -0500 (EST) 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 QAA18987 for ; Thu, 19 Dec 2002 16:06:13 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBJL6De13630 for mpls@uu.net; Thu, 19 Dec 2002 16:06:13 -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 QQntyq14225 for ; Thu, 19 Dec 2002 21:05:41 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 QQntyq17455 for ; Thu, 19 Dec 2002 21:05:07 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 QQntyq11654 for ; Thu, 19 Dec 2002 21:05:06 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 QQntyq11635 for ; Thu, 19 Dec 2002 21:05:05 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 QAA82250; Thu, 19 Dec 2002 16:04:58 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212192104.QAA82250@workhorse.fictitious.org> To: Shahram Davari cc: "'curtis@fictitious.org'" , "'Kireeti Kompella'" , "'mpls@UU.NET'" Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Thu, 19 Dec 2002 11:33:36 PST." <4B6D09F3B826D411A67300D0B706EFDEB03BC6@nt-exch-yow.pmc-sierra.bc.ca> Date: Thu, 19 Dec 2002 16:04:58 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4B6D09F3B826D411A67300D0B706EFDEB03BC6@nt-exch-yow.pmc-sierra.bc.ca >, Shahram Davari writes: > Curtis, > > Let me explain my point a bit more. This has already been stated by > Alia. RFC2547bis says: > > "Suppose that a PE has assigned label L to route R, and has > distributed this label mapping via BGP. If R is an aggregate of a > set of routes in the VRF, the PE will know that packets from the > backbone which arrive with this label must have their destination > addresses looked up in a VRF. When the PE looks up the label in its > Label Information Base, it learns which VRF must be used. On the > other hand, if R is not an aggregate, then when the PE looks up the > label, it learns the egress attachment circuit, as well as the > encapsulation header for the packet. In this case, no lookup in the > VRF is done. > > We would expect that the most common case would be the case where the > route is NOT an aggregate." > > As you can see no VRF lookup is a possible approach for L3VPN. The following > text assumes no VRF lookup at the egress PE: > > Based on the example in the draft, LSP ping could send an IP packet with the > specific route's VPN label and then the PSN's label. However, the egress LER > would look at the specific route's VPN label and immediately forward the pac > ket, whatever it contained, to the egress attachment circuit. > > Please note that since the LSP is an IP-carrying LSP, based on the draft no > explicit null is required and therefore S=1 for the bottom most label. > > My question is what criteria is used at the egress LSR to identify and termin > ate LSP-ping packets? There might be 3 solutions: > > 1) Use explicit null label even though the traffic is IP, and detect LSP-ping > packets from S=0 in the VPN label. This may require HW change, because curren > t implementations don't look at S-bit. > > 2) Only push the PSN label, and encode the VPN label in the echo-request. > > 3) In echo-request set the TTL=0 for VPN label, and detect the LSP-ping by > sending the TTL=0 packets to the OAM module. This may also require HW change > as I am not sure current implementations check the TTL of the VPN label. > > My suggestion was the 2nd one. What method do you suggest? > > Thanks, > -Shahram I was suggesting you set TTL=1 on the VPN label and include an explicit null label, also with TTL=1. Others can speak up if the change will be a problem. Curtis > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > Sent: Wednesday, December 18, 2002 6:38 PM > > To: Shahram Davari > > Cc: 'curtis@fictitious.org'; 'Kireeti Kompella'; 'mpls@UU.NET' > > Subject: Re: Last call on LSP Ping > > > > > > > > In message > > <4B6D09F3B826D411A67300D0B706EFDEB03BC1@nt-exch-yow.pmc-sierra.bc.ca > > >, Shahram Davari writes: > > > Curtis, > > > > > > Could you please explain in simple terms how can one check the > > > inner LSP's connectivity in L3VPN and L2VPN? Consider the case > > > where no VRF table lookup is done at the egress. > > > > > > Thanks, > > > -Shahram > > > > You'll have to first explain to me how you do a VPN without doing a > > VRF lookup. The LSP for normal VPN traffic can't just terminate on > > the loopback. The last label normally drives the VRF lookup. If "S" > > is clear or TTL expires, then the packet is directed to the loopback > > to IP and UDP port 3503 for MPLS-ping processing. MPLS-ping can only > > check the VRF lookup in the control plane. This was the point of the > > statement "Since the MPLS-ping 'echo request' packets are extracted no > > further downstream than the egress LSR, faults at the egress in > > decapsulating and directing traffic further are not detected." that > > now appears in the fourth paragraph of "1. Introduction". > > > > Did I miss something? > > > > Curtis > > > From owner-mpls@UU.NET Fri Dec 20 06:44:01 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 GAA22268 for ; Fri, 20 Dec 2002 06:44:01 -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 QQnuax01350 for ; Fri, 20 Dec 2002 11:47:00 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 QQnuaw21617; Fri, 20 Dec 2002 11:41:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQnuaw06178 for mpls-outgoing; Fri, 20 Dec 2002 11:40:45 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 QQnuaw06173 for ; Fri, 20 Dec 2002 11:40:34 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 QQnuaw11197 for ; Fri, 20 Dec 2002 11:40:24 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 QQnuaw21474 for ; Fri, 20 Dec 2002 11:40:24 GMT Received: from relay4.clb.oleane.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: relay4.clb.oleane.net [213.56.31.24]) id QQnuaw21457 for ; Fri, 20 Dec 2002 11:40:23 GMT Received: from oleane ([194.250.212.114]) by relay4.clb.oleane.net with SMTP id gBKBeMDh007989 for ; Fri, 20 Dec 2002 12:40:22 +0100 Message-ID: <008801c2a81d$b04dc580$0601a8c0@oleane.com> From: "Peter Lewis" To: Subject: MPLS World Congress 2003 Date: Fri, 20 Dec 2002 12:48:18 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0085_01C2A826.11CF0A00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0085_01C2A826.11CF0A00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Conference + Exhibition + interoperability Testbed Less than two months before the opening of the MPLS World Congress 2003 = next February 4th, Upper Side is pleased to announce an important growth = of the number of registered delegates. The conference will also benefit = by an extension of the exhibiton room.=20 MPLS World will indeed welcome 500 participants who will have the = possibility to meet the top industry players in this area and benefit = from the interoperability platform co-organised by the EANTC, The ETSI = and the MPLS Forum.=20 Above all, more than 40 key speakers will bring them all the necessary = informations in order to succeed their MPLS network roll-out.=20 More details at: http://www.upperside.fr/mplswc2003/mplswc03intro.htm=20 ------=_NextPart_000_0085_01C2A826.11CF0A00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_0085_01C2A826.11CF0A00-- From owner-mpls@UU.NET Fri Dec 20 09:36: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 JAA28210 for ; Fri, 20 Dec 2002 09:36:13 -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 QQnubi15911 for ; Fri, 20 Dec 2002 14:39: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 QQnubi11955; Fri, 20 Dec 2002 14:37:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQnubi13912 for mpls-outgoing; Fri, 20 Dec 2002 14:36:46 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 QQnubi13903 for ; Fri, 20 Dec 2002 14:36:38 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 QQnubi00484 for ; Fri, 20 Dec 2002 14:34: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 QQnubi09514 for ; Fri, 20 Dec 2002 14:34:46 GMT Received: from mailhost.avici.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host201.avici.com [208.246.215.201] (may be forged)) id QQnubi09497 for ; Fri, 20 Dec 2002 14:34:46 GMT Received: from aatlas-lt.avici.com (b2-pc95.avici.com [10.2.100.125]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id gBKEYHr18409; Fri, 20 Dec 2002 09:34:17 -0500 (EST) Message-Id: <5.1.0.14.2.20021220093351.01fa5c28@mailhost.avici.com> X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 20 Dec 2002 09:35:58 -0500 To: curtis@fictitious.org From: Alia Atlas Subject: Re: Last call on LSP Ping Cc: Shahram Davari , "'curtis@fictitious.org'" , "'Kireeti Kompella'" , "'mpls@UU.NET'" In-Reply-To: <200212192104.QAA82250@workhorse.fictitious.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 04:04 PM 12/19/2002 -0500, Curtis Villamizar wrote: > > 1) Use explicit null label even though the traffic is IP, and detect > LSP-ping > > packets from S=0 in the VPN label. This may require HW change, because > curren > > t implementations don't look at S-bit. > > > > 2) Only push the PSN label, and encode the VPN label in the echo-request. > > > > 3) In echo-request set the TTL=0 for VPN label, and detect the LSP-ping by > > sending the TTL=0 packets to the OAM module. This may also require HW > change > > as I am not sure current implementations check the TTL of the VPN label. > > > > My suggestion was the 2nd one. What method do you suggest? > > > > Thanks, > > -Shahram > > >I was suggesting you set TTL=1 on the VPN label and include an >explicit null label, also with TTL=1. Others can speak up if the >change will be a problem. Currently the incoming TTL, which I believe is that checked for the TTL expiring, is based upon the top incoming label. I.e., if the PSN label is still on the packet when it reaches the egress, then its TTL would be used, rather than the TTL of the VPN label underneath. Of course, if the PSN label is not there, because of PHP, then the incoming TTL would be that of the VPN label, and this could work - but that requires PHP :-(. Alia From owner-mpls@UU.NET Fri Dec 20 10:50: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 KAA29964 for ; Fri, 20 Dec 2002 10:50:51 -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 QQnubn13765 for ; Fri, 20 Dec 2002 15:53:38 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 QQnubn08205; Fri, 20 Dec 2002 15:50:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQnubn08289 for mpls-outgoing; Fri, 20 Dec 2002 15:50:05 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 QQnubn08273 for ; Fri, 20 Dec 2002 15:49:47 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 QQnubn26397 for ; Fri, 20 Dec 2002 15:49: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 QQnubn14194 for ; Fri, 20 Dec 2002 15:49:12 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 QQnubn14124 for ; Fri, 20 Dec 2002 15:49:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBKFndmH027244 for ; Fri, 20 Dec 2002 10:49:39 -0500 (EST) 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 KAA15695 for ; Fri, 20 Dec 2002 10:49:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBKFn5a08475 for mpls@uu.net; Fri, 20 Dec 2002 10:49:05 -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 QQnubn08236 for ; Fri, 20 Dec 2002 15:48:08 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 QQnubn08879 for ; Fri, 20 Dec 2002 15:47: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 QQnubn09566 for ; Fri, 20 Dec 2002 15:47:35 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 QQnubn09557 for ; Fri, 20 Dec 2002 15:47:34 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 KAA85963; Fri, 20 Dec 2002 10:47:15 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212201547.KAA85963@workhorse.fictitious.org> To: Alia Atlas cc: curtis@fictitious.org, Shahram Davari , "'Kireeti Kompella'" , "'mpls@UU.NET'" Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Fri, 20 Dec 2002 09:35:58 EST." <5.1.0.14.2.20021220093351.01fa5c28@mailhost.avici.com> Date: Fri, 20 Dec 2002 10:47:15 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <5.1.0.14.2.20021220093351.01fa5c28@mailhost.avici.com>, Alia Atlas writes: > At 04:04 PM 12/19/2002 -0500, Curtis Villamizar wrote: > > > 1) Use explicit null label even though the traffic is IP, and detect > > LSP-ping > > > packets from S=0 in the VPN label. This may require HW change, because > > curren > > > t implementations don't look at S-bit. > > > > > > 2) Only push the PSN label, and encode the VPN label in the echo-request > . > > > > > > 3) In echo-request set the TTL=0 for VPN label, and detect the LSP-ping b > y > > > sending the TTL=0 packets to the OAM module. This may also require HW > > change > > > as I am not sure current implementations check the TTL of the VPN label. > > > > > > My suggestion was the 2nd one. What method do you suggest? > > > > > > Thanks, > > > -Shahram > > > > > >I was suggesting you set TTL=1 on the VPN label and include an > >explicit null label, also with TTL=1. Others can speak up if the > >change will be a problem. > > Currently the incoming TTL, which I believe is that checked for the TTL > expiring, is based upon the top incoming label. I.e., if the PSN label is > still on the packet when it reaches the egress, then its TTL would be used, > rather than the TTL of the VPN label underneath. Of course, if the PSN > label is not there, because of PHP, then the incoming TTL would be that of > the VPN label, and this could work - but that requires PHP :-(. > > Alia We then have to insist that in forwarding, an implementation look beneath the VPN label if the S bit is not set and deliver locally if the next label is an explicit null. If the VPN label is not included many ECMP for LDP implementations at midpoint will not use the same path for the test traffic (hash based on lower labels only) and the test traffic will not take the same path as the VPN traffic which is intended to be tested. Curtis From owner-mpls@UU.NET Fri Dec 20 11:49: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 LAA01904 for ; Fri, 20 Dec 2002 11:49:28 -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 QQnubr02479 for ; Fri, 20 Dec 2002 16:52: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 QQnubr01314; Fri, 20 Dec 2002 16:51:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQnubr01768 for mpls-outgoing; Fri, 20 Dec 2002 16:51:31 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 QQnubr01761 for ; Fri, 20 Dec 2002 16:51:25 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 QQnubr14427 for ; Fri, 20 Dec 2002 16:51:16 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 QQnubr04071 for ; Fri, 20 Dec 2002 16:51:15 GMT Received: from zcars04e.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQnubr04055 for ; Fri, 20 Dec 2002 16:51:15 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 gBKGo7l17638; Fri, 20 Dec 2002 11:50:07 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Dec 2002 11:50:08 -0500 Message-ID: From: "David Allan" To: Alia Atlas , curtis@fictitious.org Cc: Shahram Davari , "'curtis@fictitious.org'" , "'Kireeti Kompella'" , "'mpls@UU.NET'" Subject: RE: Last call on LSP Ping Date: Fri, 20 Dec 2002 11:50:07 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Folks: A couple of thoughts.... 1) Seems on a pop and swap or pop and pop the TTL of both labels would be decremented (pipe mode) or both effectively would be decremented (uniform mode) as the outer would be decremented prior to copying to the inner. Only on PHP (pipe) would the inner label TTL not be decremented. 2) For pop and pop (no PHP case) finding an explicit NULL should mean forward as an IP packet which means 127./8 address. 3) For pop & go (PHP of inner label), the CE gets any inner label OAM traffic :-( I have to admit I am not clear on what circumstances an Explicit NULL can be a top label and if we re breaking somthing if we insist that PEs terminate anything with an Explicit NULL.... cheers Dave > -----Original Message----- > From: Alia Atlas [mailto:aatlas@avici.com] > Sent: Friday, December 20, 2002 9:36 AM > To: curtis@fictitious.org > Cc: Shahram Davari; 'curtis@fictitious.org'; 'Kireeti Kompella'; > 'mpls@UU.NET' > Subject: Re: Last call on LSP Ping > > > At 04:04 PM 12/19/2002 -0500, Curtis Villamizar wrote: > > > 1) Use explicit null label even though the traffic is IP, > and detect > > LSP-ping > > > packets from S=0 in the VPN label. This may require HW > change, because > > curren > > > t implementations don't look at S-bit. > > > > > > 2) Only push the PSN label, and encode the VPN label in > the echo-request. > > > > > > 3) In echo-request set the TTL=0 for VPN label, and > detect the LSP-ping by > > > sending the TTL=0 packets to the OAM module. This may > also require HW > > change > > > as I am not sure current implementations check the TTL of > the VPN label. > > > > > > My suggestion was the 2nd one. What method do you suggest? > > > > > > Thanks, > > > -Shahram > > > > > >I was suggesting you set TTL=1 on the VPN label and include an > >explicit null label, also with TTL=1. Others can speak up if the > >change will be a problem. > > Currently the incoming TTL, which I believe is that checked > for the TTL > expiring, is based upon the top incoming label. I.e., if the > PSN label is > still on the packet when it reaches the egress, then its TTL > would be used, > rather than the TTL of the VPN label underneath. Of course, > if the PSN > label is not there, because of PHP, then the incoming TTL > would be that of > the VPN label, and this could work - but that requires PHP :-(. > > Alia > > From owner-mpls@UU.NET Fri Dec 20 13:21:14 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 NAA04475 for ; Fri, 20 Dec 2002 13:21:14 -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 QQnubx11681 for ; Fri, 20 Dec 2002 18:23:52 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 QQnubx06197; Fri, 20 Dec 2002 18:20:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQnubx14384 for mpls-outgoing; Fri, 20 Dec 2002 18:20:23 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 QQnubx14379 for ; Fri, 20 Dec 2002 18:20:16 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 QQnubx21260 for ; Fri, 20 Dec 2002 18:20: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 QQnubx05573 for ; Fri, 20 Dec 2002 18:20:06 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 QQnubx05553 for ; Fri, 20 Dec 2002 18:20:06 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBKIKch9019246 for ; Fri, 20 Dec 2002 13:20:39 -0500 (EST) 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 NAA27367 for ; Fri, 20 Dec 2002 13:20:04 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBKIK4M18254 for mpls@uu.net; Fri, 20 Dec 2002 13:20:04 -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 QQnubx14337 for ; Fri, 20 Dec 2002 18:18:48 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 QQnubx28884 for ; Fri, 20 Dec 2002 18:18:20 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 QQnubx28444 for ; Fri, 20 Dec 2002 18:18:19 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 QQnubx28414 for ; Fri, 20 Dec 2002 18:18:18 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 NAA86508; Fri, 20 Dec 2002 13:17:52 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212201817.NAA86508@workhorse.fictitious.org> To: "David Allan" cc: Alia Atlas , curtis@fictitious.org, Shahram Davari , "'Kireeti Kompella'" , "'mpls@UU.NET'" Reply-To: curtis@fictitious.org Subject: Re: Last call on LSP Ping In-reply-to: Your message of "Fri, 20 Dec 2002 11:50:07 EST." Date: Fri, 20 Dec 2002 13:17:52 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , "Da vid Allan" writes: > > > Folks: > > A couple of thoughts.... > > 1) Seems on a pop and swap or pop and pop the TTL of both labels would be > decremented (pipe mode) or both effectively would be decremented (uniform > mode) as the outer would be decremented prior to copying to the inner. Only > on PHP (pipe) would the inner label TTL not be decremented. > > 2) For pop and pop (no PHP case) finding an explicit NULL should mean > forward as an IP packet which means 127./8 address. > > 3) For pop & go (PHP of inner label), the CE gets any inner label OAM > traffic :-( > > I have to admit I am not clear on what circumstances an Explicit NULL can be > a top label and if we re breaking somthing if we insist that PEs terminate > anything with an Explicit NULL.... > > cheers > Dave Dave, You seem to be assuming ommision of the VPN label. The problem does not occur for: 1. Uniform mode. (Outer label TTL expires). 2. Pipe mode with PHP. (Outer label removed, VPN TTL expires). 3. Pipe mode without PHP for routers that support the ability to look for a label below the VPN label (newly specified). The problem does occur when Pipe mode is used AND PHP is not used AND the router does not support the ability to look under the VPN label. Since we are talking about a practical problem, specifying a change in forwarding, lets look at a significant chunk of the deplyed base of core routers: Cisco - does PHP as egress. Juniper - does PHP as egress. Avici - does not request PHP but can support the ability to look under the VPN label without hardware change. Even if not, PHP can be enabled by configuration. Someone from Cisco or Juniper can object if this won't work with their routers. If there are any other deployed routers that can't request PHP via implicit null and process it as an egress, and cannot modify forwarding to look under the VPN label if another label exists, then someone needs to speak up. Otherwise it is a hypothetical problem for which there is no known instance and we can move forward. Curtis > > -----Original Message----- > > From: Alia Atlas [mailto:aatlas@avici.com] > > Sent: Friday, December 20, 2002 9:36 AM > > To: curtis@fictitious.org > > Cc: Shahram Davari; 'curtis@fictitious.org'; 'Kireeti Kompella'; > > 'mpls@UU.NET' > > Subject: Re: Last call on LSP Ping > > > > > > At 04:04 PM 12/19/2002 -0500, Curtis Villamizar wrote: > > > > 1) Use explicit null label even though the traffic is IP, > > and detect > > > LSP-ping > > > > packets from S=0 in the VPN label. This may require HW > > change, because > > > curren > > > > t implementations don't look at S-bit. > > > > > > > > 2) Only push the PSN label, and encode the VPN label in > > the echo-request. > > > > > > > > 3) In echo-request set the TTL=0 for VPN label, and > > detect the LSP-ping by > > > > sending the TTL=0 packets to the OAM module. This may > > also require HW > > > change > > > > as I am not sure current implementations check the TTL of > > the VPN label. > > > > > > > > My suggestion was the 2nd one. What method do you suggest? > > > > > > > > Thanks, > > > > -Shahram > > > > > > > > >I was suggesting you set TTL=1 on the VPN label and include an > > >explicit null label, also with TTL=1. Others can speak up if the > > >change will be a problem. > > > > Currently the incoming TTL, which I believe is that checked > > for the TTL > > expiring, is based upon the top incoming label. I.e., if the > > PSN label is > > still on the packet when it reaches the egress, then its TTL > > would be used, > > rather than the TTL of the VPN label underneath. Of course, > > if the PSN > > label is not there, because of PHP, then the incoming TTL > > would be that of > > the VPN label, and this could work - but that requires PHP :-(. > > > > Alia > > > > > From owner-mpls@UU.NET Fri Dec 20 14:09: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 OAA06707 for ; Fri, 20 Dec 2002 14:09:25 -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 QQnuca16467 for ; Fri, 20 Dec 2002 19:12:24 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 QQnuca13445; Fri, 20 Dec 2002 19:10:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQnuca06324 for mpls-outgoing; Fri, 20 Dec 2002 19:10: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 QQnuca06276 for ; Fri, 20 Dec 2002 19:10:15 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 QQnuca13785 for ; Fri, 20 Dec 2002 19:09: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 QQnuca12411 for ; Fri, 20 Dec 2002 19:09:45 GMT Received: from zcars04f.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQnuca12399 for ; Fri, 20 Dec 2002 19:09:45 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 gBKJ95U12623; Fri, 20 Dec 2002 14:09:05 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Dec 2002 14:09:05 -0500 Message-ID: From: "David Allan" To: curtis@fictitious.org Cc: Alia Atlas , curtis@fictitious.org, Shahram Davari , "'Kireeti Kompella'" , "'mpls@UU.NET'" Subject: RE: Last call on LSP Ping Date: Fri, 20 Dec 2002 14:09:04 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Hi Curtis: > Dave, > > You seem to be assuming ommision of the VPN label. ???????? > The problem does not occur for: > > 1. Uniform mode. (Outer label TTL expires). > > 2. Pipe mode with PHP. (Outer label removed, VPN TTL expires). > > 3. Pipe mode without PHP for routers that support the ability to > look for a label below the VPN label (newly specified). > > The problem does occur when > > Pipe mode is used AND PHP is not used AND the router does not > support the ability to look under the VPN label. > > Since we are talking about a practical problem, specifying a change in > forwarding, lets look at a significant chunk of the deplyed base of > core routers: > > Cisco - does PHP as egress. > Juniper - does PHP as egress. > Avici - does not request PHP but can support the ability to look > under the VPN label without hardware change. Even if not, PHP > can be enabled by configuration. > > Someone from Cisco or Juniper can object if this won't work with their > routers. > > If there are any other deployed routers that can't request PHP via > implicit null and process it as an egress, and cannot modify > forwarding to look under the VPN label if another label exists, then > someone needs to speak up. Otherwise it is a hypothetical problem for > which there is no known instance and we can move forward. > > Curtis If I understand the problem statement correctly, it was how do you test the inner label in a PW or VPN application. Currently as written in the document it is via testing the outer label with an FEC stack (proxy test) on the assumption that a probe under the inner label MAY NOT be visible to the egress PE. I can also try to force visibility by setting the inner label TTL to 1 which assumes pipe mode at the PHP LSR. Uniform model at the egress and all bets are off as the VPN label TTL will be overwritten by the PSN label TTL value. TTL exhaustion for ping mode is potentially undesirable as theoretically ICMP TTL exhaust messages are a byproduct. I got the impression that testing the inner label was primarily via testing the outer label with a FEC stack. Looks simpler than some of the other implications (what is the address of the inner label ping origin..?) Dave From owner-mpls@UU.NET Fri Dec 20 15:56:47 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 PAA10654 for ; Fri, 20 Dec 2002 15:56:46 -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 QQnuch15130 for ; Fri, 20 Dec 2002 20:59: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 QQnuch10798; Fri, 20 Dec 2002 20:56:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQnuch03087 for mpls-outgoing; Fri, 20 Dec 2002 20:56:42 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 QQnuch03082 for ; Fri, 20 Dec 2002 20:56:36 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 QQnuch23225 for ; Fri, 20 Dec 2002 20:55: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 QQnuch02921 for ; Fri, 20 Dec 2002 20:55:08 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 QQnuch02915 for ; Fri, 20 Dec 2002 20:55:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBKKte6Q012037 for ; Fri, 20 Dec 2002 15:55:40 -0500 (EST) 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 PAA09676 for ; Fri, 20 Dec 2002 15:55:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBKKt6E27948 for mpls@uu.net; Fri, 20 Dec 2002 15:55:06 -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 QQnuch02858 for ; Fri, 20 Dec 2002 20:54:07 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 QQnuch11895 for ; Fri, 20 Dec 2002 20:53:40 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 QQnuch08545 for ; Fri, 20 Dec 2002 20:53:39 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 QQnuch08534 for ; Fri, 20 Dec 2002 20:53:39 GMT Received: (qmail 21842 invoked by uid 104); 20 Dec 2002 20:53:38 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 (uvscan: v4.1.40/v4238. Clear:. Processed in 0.471983 secs); 20 Dec 2002 20:53:38 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 20 Dec 2002 20:53:37 -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 gBKKrRQ23890; Fri, 20 Dec 2002 12:53:28 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Fri, 20 Dec 2002 12:53:27 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03BD3@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'curtis@fictitious.org'" , David Allan Cc: Alia Atlas , "'Kireeti Kompella'" , "'mpls@UU.NET'" Subject: RE: Last call on LSP Ping Date: Fri, 20 Dec 2002 12:53:24 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Curtis, > Dave, > > You seem to be assuming ommision of the VPN label. Seems you are assuming only trace-route > > The problem does not occur for: > > 1. Uniform mode. (Outer label TTL expires). True for trace-route, not true for ping. > > 2. Pipe mode with PHP. (Outer label removed, VPN TTL expires). No it doesn't. The packet arrives with VPN label, which has TTL=1 to the egress LSR. The egress LSR should accept this packet and forward it if possible. Remember RFC1812 says: " A router MUST NOT discard a datagram just because it was received with TTL equal to zero or one; if it is to the router and otherwise valid, the router MUST attempt to receive it. " So the packet received would be accepted and a lookup of the VPN label results forwarding the payload to the Customer. > > 3. Pipe mode without PHP for routers that support the ability to > look for a label below the VPN label (newly specified). I think you mean for those that can check the S-bit and make decision based on S-bit. But I think you are fundamentally changing the standard MPLS behavior. Now the forwarding table is based on not only on MPLS label (VPN label) but also on S-bit. While the standard MPLS forwarding does not S-bit for forwarding decision, rather only as a PID for encapsulated packet. Yours, -Shahram > > The problem does occur when > > Pipe mode is used AND PHP is not used AND the router does not > support the ability to look under the VPN label. > > Since we are talking about a practical problem, specifying a change in > forwarding, lets look at a significant chunk of the deplyed base of > core routers: > > Cisco - does PHP as egress. > Juniper - does PHP as egress. > Avici - does not request PHP but can support the ability to look > under the VPN label without hardware change. Even if not, PHP > can be enabled by configuration. > > Someone from Cisco or Juniper can object if this won't work with their > routers. > > If there are any other deployed routers that can't request PHP via > implicit null and process it as an egress, and cannot modify > forwarding to look under the VPN label if another label exists, then > someone needs to speak up. Otherwise it is a hypothetical problem for > which there is no known instance and we can move forward. > > Curtis > > > > > -----Original Message----- > > > From: Alia Atlas [mailto:aatlas@avici.com] > > > Sent: Friday, December 20, 2002 9:36 AM > > > To: curtis@fictitious.org > > > Cc: Shahram Davari; 'curtis@fictitious.org'; 'Kireeti Kompella'; > > > 'mpls@UU.NET' > > > Subject: Re: Last call on LSP Ping > > > > > > > > > At 04:04 PM 12/19/2002 -0500, Curtis Villamizar wrote: > > > > > 1) Use explicit null label even though the traffic is IP, > > > and detect > > > > LSP-ping > > > > > packets from S=0 in the VPN label. This may require HW > > > change, because > > > > curren > > > > > t implementations don't look at S-bit. > > > > > > > > > > 2) Only push the PSN label, and encode the VPN label in > > > the echo-request. > > > > > > > > > > 3) In echo-request set the TTL=0 for VPN label, and > > > detect the LSP-ping by > > > > > sending the TTL=0 packets to the OAM module. This may > > > also require HW > > > > change > > > > > as I am not sure current implementations check the TTL of > > > the VPN label. > > > > > > > > > > My suggestion was the 2nd one. What method do you suggest? > > > > > > > > > > Thanks, > > > > > -Shahram > > > > > > > > > > > >I was suggesting you set TTL=1 on the VPN label and include an > > > >explicit null label, also with TTL=1. Others can speak up if the > > > >change will be a problem. > > > > > > Currently the incoming TTL, which I believe is that checked > > > for the TTL > > > expiring, is based upon the top incoming label. I.e., if the > > > PSN label is > > > still on the packet when it reaches the egress, then its TTL > > > would be used, > > > rather than the TTL of the VPN label underneath. Of course, > > > if the PSN > > > label is not there, because of PHP, then the incoming TTL > > > would be that of > > > the VPN label, and this could work - but that requires PHP :-(. > > > > > > Alia > > > > > > > > > From owner-mpls@UU.NET Sat Dec 21 11:21: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 LAA08799 for ; Sat, 21 Dec 2002 11:21:10 -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 QQnufh04042 for ; Sat, 21 Dec 2002 16:24:10 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 QQnufh01832; Sat, 21 Dec 2002 16:22:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQnufh04424 for mpls-outgoing; Sat, 21 Dec 2002 16:22:27 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 QQnufh04417 for ; Sat, 21 Dec 2002 16:22: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 QQnufh03645 for ; Sat, 21 Dec 2002 16:20: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 QQnufh06645 for ; Sat, 21 Dec 2002 16:20:53 GMT Received: from mail.alcatel.be by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc250.alcatel.be [195.207.101.250]) id QQnufh06632 for ; Sat, 21 Dec 2002 16:20:51 GMT Received: from bemail05.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id gBLGKFK14916; Sat, 21 Dec 2002 17:20:15 +0100 Received: from alcatel.be ([138.203.137.3]) by bemail05.net.alcatel.be (Lotus Domino Release 5.0.11) with ESMTP id 2002122117201359:1297 ; Sat, 21 Dec 2002 17:20:13 +0100 Message-ID: <3E049482.777FA8FA@alcatel.be> Date: Sat, 21 Dec 2002 17:19:14 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: Optical Network Architecture (NTA - Antwerpen) X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jean Philippe Vasseur , sachin laddha , mpls@UU.NET, ccamp@ops.ietf.org Subject: Re: Multi-Area TE Protocol Extensions References: <4.3.2.7.2.20021210090846.06284110@paris.cisco.com> <4.3.2.7.2.20021210123021.0382fe10@paris.cisco.com> <3DF643DF.4F8AC12C@alcatel.be> <4.3.2.7.2.20021211114607.0513d0a0@paris.cisco.com> <4.3.2.7.2.20021212173514.03e31e98@paris.cisco.com> <3DFA3CFD.B26A5031@alcatel.be> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 12/21/2002 17:20:14, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 12/21/2002 17:20:19, Serialize complete at 12/21/2002 17:20:19 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit hi jean-philippe, i re-send the below e-mail, in brief i would rather suggest you provide a clear view on why rsvp as to be re-used for path query/response, but if you could elaborate a bit more wrt to the below discussion that wouldn't be completely useless for the ccamp community thanks, - dimitri. Dimitri Papadimitriou wrote: > > hi jean-philippe, > > see in-line... > > Jean Philippe Vasseur wrote: > > > > Hi Dimitri, > > > > At 23:25 12/12/2002 +0100, Dimitri.Papadimitriou@alcatel.be wrote: > > >your impression is too affirmative wrt to my next reply > > >(i've never said that the xro mechanisms are restricted > > >to ma-te or that this i-d should be entirely dedicated > > >to it) also the intention of opening a charter item > > >implies imho structuring the content of proposals that > > >are on the table and that may further come in, this in > > >order to achieve common mechanisms in the scope of the > > >ccamp wg - in whatever i-d btw as long as it reproduces > > >the consensus of the wg (taking a look back at gmpls > > >signalling for instance you will see that it is the > > >concatenation of many individual submissions coming > > >from various horizons) > > > > > >as said before, we have currently two methods > > > > We probably have more ... we can also add some methods consisting on > > leaking part of the topology info into the areas, .... > > i referred here to the "signalling" based methods (i should > have said before, sorry) hence, i think we should scope the > discussion to these two here for the time being > > > But I do agree with you that once the CCAMP charter explicitly includes the > > multi-area TE item, we will need to find a consensus and work on a single > > document. > > me too > > > >on the > > >table 1) constraint passing and 2) path queries, the > > >first beneficiate from the fact it is the logical > > >evolution from loose routing (the next step) the other > > >uses signalling for querying a server, as such there > > >is one fundamental question underlying the latter: > > >moving features from distributed entities to the > > >centralized ones for path computation purposes solves > > >an intermediate problem (when a unique server is > > >available) that comes back when several centralized > > >systems have to interoperate > > > > I guess you are referring to the problem of multiple central systems > > sharing the path computation requests that indeed need to be in sync. That > > of course seriously increases the level of complexity but I do not think > > this is required. In the case of multi-area TE, a determined ABR > > (statically configured or dynamically discovered) can the THE PCS serving > > the requests for the LSRs residing within a specific area. In case of > > failure, a backup PCS can be used. > > it is not "required" but your last sentence clearly > indicates it will become rapidly a "recommendation" > this clearly puts limits to the current applicability > of this method - see also here below - and i think it > would be wise to start thinking about scoping this > approach (in case). > > > >but also one fundamental > > >protocol aspect (which is due to the methods currently > > >proposed) using a signalling protocol like rsvp to > > >explicitly query a server is clearly questionable (*) > > > > Well, I would be more than happy to discuss this aspect of course, but not > > from a philosophical point of view ... > > when i say questionable, i don't want to enter into the > arcane of protocol philosophy but the protocol consistence > & evolution - imho i think this is part of our common > responsibility as ietf'ers - this said take this as a > technical discussion, please (no bad intentions here) > > > We have various options there: > > (1) try to extend an existing protocol like RSVP. Note that > > http://www.ietf.org/internet-drafts/draft-vasseur-mpls-computation-rsvp-03.txt > > requires to specify only one new message type and a single additional > > object (REQUEST-ID object). All the other objects are completely optional. > > All the LSRs have already an RSVP stack and this allows to reuse all the > > RSVP objects defined so far to pass the constraints to the PCS. So the idea is: > > - to slightly extend an existing protocol (with one new message > > type, one new object required) without impacting its scalability, > > this i-d describes in details the new messages, objects and > their usage but i don't see any detail about how RSVP works > in this case ? would you please go first by yourself into > the details of what's the use of the mandatory objects in > that context and their semantic wrt respect to their current > use ? this would help me really to understand the rationales > behind this method - the issue is as follows there is no > clear explanations on why rsvp re-use is a key in enabling > a path query between a client and a server, except from the > fact it is already used but for resource reservation - > > you've said "without impacting its scalability", first you > should clarify from which viewpoint since due to the above > point it is probably a method that complexifies when the > #pcs > 1 thus i would only consider that #pcs = 1 (in a > first approach) now, if you refer to the installed and > running distributed rsvp-te software on the routers and > other switches from the client side it seems the case since > you have to maintain a session (but do i have to call it a > session in this context ?) with one pcs and even if you have > several sessions (?) you would at most double or triple their > number so it is clearly limited, the problem is in the other > way around, where you have a factor n (at least), n being > the number of nodes; if each of these nodes maintains m flows > (with m>>1) well the question becomes that the dimensioning > of the number of lsp's is dependent of the capabilities of > the pcs (thus in addition, it seems you have introduced a > new issue in network dimensioning) imho scalability with > respect to the pcs (in particular wrt to rsvp usage) imho > would deserve more words in this i-d in particular when > running on the same device than the one(s) along the lsp. > > > - re use all the existing objects, > > this re-use is clearly what i refer to here, i clearly > understand the use of the new objects but what about the > , etc. what do they represent > in this context ? > > you will see that this discussion is exactly the one that > we would have in defining a new application, but where i > see another point here one start to use rsvp as p2p tunnel > to transport the info for such kind of applications > > > - not require any additional protocol running on the LSRs > > (2) re invent a new protocol from scratch ... > > I personally vote for the pragmatic approach (1), let see other inputs on > > the list. > > well you have really point out the two alternatives > sitting at the both end of the solution spectrum > > > I won't go in the philosophical aspects ... Note that IGPs/RSVP have not > > been designed to carry Optical/SDH/SONET/... > > well let me point out here they don't carry sdh, they > extend the set of bandwidth request encoding (as such > no change in the orientation of resource reservation > of this protocol) > > > infos either and I think one > > could mention many other examples like this and as a matter of fact they > > perfectly make the job. I personally think that if an exiting protocol can > > be slightly extended (without impacting its scalability, ... ) and can > > solve an actual problem, this option is preferable than trying to reinvent > > a new protocol from scratch. > > using your words: > > 1) constraint-passing would be then much more pragmatic > (since you don't have to implement one new message, only > new objects) and this without impacting existing approaches > > 2) if one has to implement a new message with new semantic > (outside of the scope of resource reservation even in a > generic sense) then we can legitimatelly "ask" the question > why not a dedicated protocol for it running over udp; > > and this is probably the way to go for this method use > all the object encoding, errors and s.o. without being > obliged to maintain backward semantic with rsvp itself > this is what the ccamp wg did with lmp and i don't think > this is unfeasible in this case, however i would say > that this would solve only the easy part of the problem > (the issue of what happens in case of multiple pcs that > runs in parallel is still for me an open issue) > > > Again I'll be more than happy to get more feed-backs on the list. > > > > >- i think this should be clarified in the kompella i-d > > > > What would you exactly want us to clarify in the i-d ? > > the following paragraph says: > " Once the path computation server computes the path, if the server is > not along the path, the server is no longer responsible for maintaining > the feasibility of the path (for one thing, the server may not even know > whether the LSR established the path in the first place)." > > the "if the server is not along the path" is not a > condition, this applies independently of the condition > the lsp is along the path, this should be clarified > otherwise the above paragraph requires that you have > to maintain the state of the computed path and the > actual lsp on abr's for instance! but this is this > may be what you intend to propose ? but in this case > i don't see this clearly this i-d (is my understanding > right here ?) > > > >since this is independent from the fact that the server > > >is collocated on an abr or along the lsp path - back > > >to previous method using constraint passing i would > > >say constraint-passing keeps the current philosophy > > >of rsvp-te since based on the implicit assumption > > >that each hop (in particular abr in ma-te context) are > > >capable to respond to the incoming request; is the > > >latter optimal, no of course; but i would say that at > > >the end the "simplest solution to this complex problem > > >will remain", well i think that rfc 3439 phrases this > > >principle much better than i do; > > > > > >(*) understand this as a general remark people have > > >the tendency to overload/over-generalize the features > > >supported by a protocol and its applicability scope > > > > I am also hopping we will move forward on this discussion with the input of > > Service Providers on which method(s) for inter-area TE better address their > > needs. > > of course, the whole ietf community is kindly invited > to provide comments and input ! > > thanks, > - dimitri. > > > Thanks. > > > > Cheers, > > > > JP. > > > > >thanks, > > >- dimitri. > > > > > >Jean Philippe Vasseur wrote: > > > > > > > > Hi, > > > > > > > > At 10:43 11/12/2002 -0500, Cheng-Yin Lee wrote: > > > > >Dimitri, JP, > > > > >While I think an applicability section/statement is fine, I'm not sure > > > > >if a mechanism > > > > >to compute inter-area TE path belong in this ID. > > > > > > > > This was exactly my impression. > > > > > > > > JP. > > > > > > > > >We did include applications in the first discussion of this ID and in the > > > > >slides > > > > >http://www.ietf.org/proceedings/02mar/slides/ccamp-6/index.html and in > > > > >addressing > > > > >Kireeti's suggestion to include a discussion on the impact of message > > > > >size, we provided > > > > >an inter-area example for illustration purposes. However, there have also > > > > >been > > > > >suggestions in the past to not discuss applications specifically in the > > > > >draft itself. > > > > >I am fine with either way. > > > > > > > > > >thanks > > > > >cheng-yin > > > > > > > > > >Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > > > > > > jp, > > > > > > > > > > > > > this ID does not propose a mechanism to compute inter-area TE path > > > > > > > > > > > > well i would say that either none of them does it, or all of > > > > > > them, more accurately route exclusions are applicable to any > > > > > > mpls network where full computation of the ero is not performed > > > > > > before the LSP is signaled, implying thus a "scope" for computed > > > > > > path thus among other applicable to multiple areas - nevertheless > > > > > > i agree that a next version of this i-d should probably include > > > > > > an applicability section covering this in a bit more details (see > > > > > > also section 4.1 for an example - > > > > > > > > > > > > this said and as for any other input or i-d provided on constraint- > > > > > > passing (as well as path query, btw) lot of work is still needed to > > > > > > achieve a decent first step in this effort; > > > > > > > > > > > > thanks, > > > > > > - dimitri. > > > > > > > > > > > > Jean Philippe Vasseur wrote: > > > > > > > > > > > > > > Hi Dimitri, > > > > > > > > > > > > > > cc'ing CCAMP - see in line, > > > > > > > > > > > > > > At 17:45 10/12/2002 +0100, Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > > >jp, > > > > > > > > > > > > > > > >in fact the below list should simply be as follows for > > > > > > > >signalling-based methods: 1) constraint-passing 2) loose > > > > > > > >routing and 3) path query; > > > > > > > > > > > > > > > >and the for constraint-passing we have a several i-d's > > > > > > > >such as, > > > > > > > > > > > > > > > >http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclu > > > de-r > > > > > oute-01.txt > > > > > > > > > > > > > > > > > > > > > > this ID does not propose a mechanism to compute inter-area TE path > > > > > > > > > > > > > > >constraint passing may also be extended using the crank- > > > > > > > >back as listed below; the usage scenarios of these methods > > > > > > > >are described in the following: > > > > > > > > > > > > > > > >http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea > > > -te- > > > > > 03.txt > > > > > > > > > > > > > > > >now probably it is worth spending some time in considering > > > > > > > >input coming from the tewg wrt to this effort, most of the > > > > > > > >input that you see listed above has been produced over the > > > > > > > >past year (and more) i can't imagine stepping in the protocol > > > > > > > >details without a clear consensus on what do we want to cover > > > > > > > >within the ccamp wg & w/o taking into account the tewg rec's > > > > > > > >(probably better to discuss this on the ccamp mailing list) > > > > > > > > > > > > > > Fully agree with you. Hopefully multi-area TE should be soon part > > > of the > > > > > > > CCAMP charter. > > > > > > > > > > > > > > JP. > > > > > > > > > > > > > > >thanks, > > > > > > > >- dimitri. > > > > > > > > > > > > > > > >Jean Philippe Vasseur wrote: > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > At 13:53 10/12/2002 +0530, sachin laddha wrote: > > > > > > > > > >Hi, > > > > > > > > > >'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as > > > > > > > > > >"Initial requirements are given here for protocol support of the > > > > > > > > multi-area > > > > > > > > > >TE methods, which include needs to support > > > > > > > > > > > > > > > > > > > >* path-computation-server (PCS) functionality > > > [kompella, lee, > > > > > > > > vasseur, > > > > > > > > > >te-qos-routing], > > > > > > > > > >* query functionality [query, vasseur], > > > > > > > > > >* crankback functionality [crankback], > > > > > > > > > > > > > > > > > > > >and, optionally, > > > > > > > > > > > > > > > > > > > >* TE feedback functionality [feedback], and > > > > > > > > > >* summary-LSA functionality [summary_lsa]." > > > > > > > > > >. > > > > > > > > > >I want to know whether cisco/juniper routers (standard ones) > > > > > supports > > > > > > > > all of > > > > > > > > > >the above extension. > > > > > > > > > >or if not,how many.......or Whether router is supposed to > > > > > support how many > > > > > > > > > >... > > > > > > > > > > > > > > > > > > I do not think any vendor supports all the method mentioned > > > > > above, but just > > > > > > > > > a subset. If you are running a network, your feed-backs on your > > > > > preferred > > > > > > > > > method is very welcome. > > > > > > > > > > > > > > > > > > JP. > > > > > > > > > > > > > > > > > > >Regards, > > > > > > > > > >---Sachin > > > > > > > > > > > > > > > >-- > > > > > > > >Papadimitriou Dimitri > > > > > > > >E-mail : dimitri.papadimitriou@alcatel.be > > > > > > > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > > > > > > >E-mail : dpapadimitriou@psg.com > > > > > > > >Public : http://psg.com/~dpapadimitriou/ > > > > > > > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > > > > > > >Phone : Work: +32 3 2408491 - Home: +32 2 3434361 > > > > > > > > > > > > -- > > > > > > Papadimitriou Dimitri > > > > > > E-mail : dimitri.papadimitriou@alcatel.be > > > > > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > > > > > E-mail : dpapadimitriou@psg.com > > > > > > Public : http://psg.com/~dpapadimitriou/ > > > > > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > > > > > Phone : Work: +32 3 2408491 - Home: +32 2 3434361 > > > > > >-- > > >Papadimitriou Dimitri > > >E-mail : dimitri.papadimitriou@alcatel.be > > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > >E-mail : dpapadimitriou@psg.com > > >Public : http://psg.com/~dpapadimitriou/ > > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > >Phone : Work: +32 3 2408491 - Home: +32 2 3434361 > > -- > Papadimitriou Dimitri > E-mail : dimitri.papadimitriou@alcatel.be > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > E-mail : dpapadimitriou@psg.com > Public : http://psg.com/~dpapadimitriou/ > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > Phone : Work: +32 3 2408491 - Home: +32 2 3434361 -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : Work: +32 3 2408491 - Home: +32 2 3434361 From owner-mpls@UU.NET Mon Dec 23 17:39:21 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 RAA16857 for ; Mon, 23 Dec 2002 17:39:20 -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 QQnunq10045 for ; Mon, 23 Dec 2002 22: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 QQnunq08140; Mon, 23 Dec 2002 22:41:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQnunq28621 for mpls-outgoing; Mon, 23 Dec 2002 22:40:56 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 QQnunq28616 for ; Mon, 23 Dec 2002 22:40:49 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 QQnunq16884 for ; Mon, 23 Dec 2002 22:40:09 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 QQnunq03612 for ; Mon, 23 Dec 2002 22:40:09 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 QQnunq03596 for ; Mon, 23 Dec 2002 22:40:08 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBNMefEt022874 for ; Mon, 23 Dec 2002 17:40:41 -0500 (EST) 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 RAA00363 for ; Mon, 23 Dec 2002 17:40:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBNMe6721240 for mpls@uu.net; Mon, 23 Dec 2002 17:40:06 -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 QQnunq28539 for ; Mon, 23 Dec 2002 22:38: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 QQnunq07298 for ; Mon, 23 Dec 2002 22:38: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 QQnunq19706 for ; Mon, 23 Dec 2002 22:38:44 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 QQnunq19679 for ; Mon, 23 Dec 2002 22:38:41 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 RAA03455; Mon, 23 Dec 2002 17:37:59 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212232237.RAA03455@workhorse.fictitious.org> To: mpls@UU.NET cc: curtis@fictitious.org Reply-To: curtis@fictitious.org Subject: suggested added text for multipath in draft-ietf-mpls-lsp-ping-01 Date: Mon, 23 Dec 2002 17:37:59 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk The long awaited part 3 of 3. Same format - diffs. This is not to say the document is done. I didn't address all the comments to the list as I would expect the authors of the document to do that. Curtis @@ -352,26 +451,28 @@ . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Types are defined below; Length is the length of the Value field in octets. The Value field depends on the Type; it is zero padded to align to a four-octet boundary. Type # Value Field ------ ----------- 1 Target FEC Stack 2 Downstream Mapping - 3 Pad - 4 Error Code + 3 Downstream Multipath Mapping + 4 Multipath Exercise + 65534 Pad + 65535 Error Code 3.1. Target FEC Stack A Target FEC Stack is a list of sub-TLVs. The number of elements is determined by the looking at the sub-TLV length fields. Sub-Type # Length Value Field ---------- ------ ----------- 1 5 LDP IPv4 prefix 2 17 LDP IPv6 prefix 3 20 RSVP IPv4 Session Query 4 56 RSVP IPv6 Session Query @@ -622,39 +723,179 @@ LSR X. If a packet with outermost label L and TTL n>1 arrived at X on interface I, X must be able to compute which LSRs could receive the packet with TTL=n+1, and what label they would see. (It is outside the scope of this document to specify how this computation may be done.) The set of these LSRs are the downstream routers (and their corresponding labels) for X with respect to L. The case where X is the LSR originating the echo request is a special case. X needs to figure out what LSRs would receive a labelled packet with TTL=1 when X tries to send a packet to the FEC Stack that is being pinged. -3.3. Pad TLV +3.3 Downstream Multipath Mapping + + The Downstream Multipath Mapping is an optional TLV in an echo + request. The Length is 4 octets plus the size of Multipath + Exercise TLVs and Downstream Mapping TLVs contained within the + Downstream Multipath Mapping TLV. + + The Downstream Multipath Mapping TLV contains one or more pairs of + Multipath Exercise TLVs and Downstream Mapping TLVs. The + Downstream Multipath Mapping TLV is used where multiple forwarding + paths exist. Each Multipath Exercise TLV provides information that + can be used to determine how to build test packets to exercise a + specific next hop. Each corresponding Downstream Mapping TLV + provides the downstream mapping information for that path. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Number of Multipaths | Type of Multipath | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Life Type | Shelf Life in Milliseconds | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Multipath Exercise TLV | + . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Downstream Mapping TLV | + . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ..... more Multipath Exercise / Downstream Mapping TLV pairs .... + . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The "Number of Multipaths" gives the number of multipaths and + determines the number of Multipath Exercise and Downstream Mapping + TLV pairs to follow unless TLV or packet size limits cause + truncation. + + The "Type of Multipath" gives the type of multipath split + performed at the branchpoint. The "Type of Multipath" is needed + to interpret the Multipath Exercise TLVs. Supported types are: + + Type of Multipath Meaning + ----------------- ------- + 1 Per packet split (use of this form of + multipath is highly discouraged). + 2 Seeded unspecified hash based on + underlying labels. + 3 Seeded unspecified hash based on IP + source and destination. + 4 Seeded unspecified hash based on IP + source and destination for stack depth + of one, based on underlying labels for + stack depth greater than one. + 5 Other or unspecified. + + The "Shelf Life in Milliseconds" allows the amount of time that + the multipath mapping will remain in effect to be specified, with + a range of 1 msec to 16,000 seconds to 4.5 hours. A value of zero + indicates the mapping will remain in place at least until a + topology change occurs. The "Life Type" field is a bit map. The + MSB (0x80) indicates that the given life time is expressed as a + maximum shelf life and that the remaining shelf life is not know. + + An Echo Request need not include description of all paths and may + be reduced in size by including only the path under test. If + packet size limit or TLV size limits (65535 bytes) would prevent + the entire set of paths from being listed in an Echo Response TLV, + the total number of paths should be listed in the "Number of + Multipaths" field and as many pairs of Multipath Exercise TLVs and + Downstream Mapping TLV as fit should be included. + +3.4 Multipath Exercise + + The Multipath Exercise TLV may appear only within a Downstream + Multipath Mapping TLV. The Multipath Exercise TLV is omitted when + "Type of Multipath" is equal to 1. The path is not deterministic. + The path cannot be determined solely by the packet encapsulation. + + The following encapsulation of the Multipath Exercise TLV is + applicable to "Type of Multipath" values 2-4. The size of the + Multipath Exercise TLV is 4 octets plus either an addtional 4 + octets per included "IP Address or Next Label" containing IPv4 + addresses or MPLS labels or an additional 16 octets for IPv6 + address. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Hash Key Type | Depth Limit | MP Index | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IP Address or Next Label | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + .... + + The "Hash Key Type" determines the interpretation of the following + "IP Address or Next Label" fields. The three formats of the "IP + Address or Next Label" are a 32 bit field containing an IPv4 + address, a 32 bit field containing a LSB justified 20 bit MPLS + label with top 12 bits reserved for future use and set to zero, or + a 128 bit IPv6 address. + + Hash Key Type: IP Address or Next Label + -------------- ------------------------ + 1 label 1 or more label + 2 IPv4 address 1 or more IPv6 address + 3 label range 1 or more low/high label pairs + 4 IPv4 address range 1 or more low/high address pairs + 5 no more labels (nothing) + 6 All IPv4 addresses (nothing) + 7 no match (nothing) + 8 IPv6 address 1 or more IPv6 address + 9 IPv6 address range 1 or more low/high address pairs + 10 IPv4 bitmap see encapsulation below + 11 label bitmap see encapsulation below + 12 IPv6 bitmap see encapsulation below + + The "Depth Limit" is applicable only to a label stack. It gives + the maximum number of labels considered in the hash or zero for + unspecified or unlimited. + + The "MP Index" is used to number the paths and provides a means to + refer to them. + + The bitmap types each include a single IPv4 address, MPLS label, or + IPv6 address, followed by sets of four octets interpreted as 32 bit + words. The IPv4 address, MPLS label, or IPv6 address should be the + first address equal to or numerically greater than the destination + address or label of the Echo Request with the lower 5 bits set to + zero (to avoid complex shift operations at a test ingress if the + union of bitmaps of multiple branch points must be determined). + Each bit starting with the least significant bit (MSB sent first) + is interpreted as one address. A zero in a given bit position + indicates that the address or label will not exercise this path, a + one idicates that the path will be exercised. The LSB of the first + 32 bit word corresponds to the address or label provided. + + Note that if a Downstream Multipath Mapping TLV cannot be fit in an + Echo Reply it is preferable to include less addresses or labels in + each Multipath Exercise TLV than omit information for some paths. + +3.5. Pad TLV The value part of the Pad TLV contains a variable number (>= 1) of octets. The first octet takes values from the following table; all the other octets (if any) are ignored. The receiver SHOULD verify that the TLV is received in its entirety, but otherwise ignores the contents of this TLV, apart from the first octet. Value Meaning ----- ------- 1 Drop Pad TLV from reply 2 Copy Pad TLV to reply 3-255 Reserved for future use -3.4. Error Code +3.6. Error Code The Error Code TLV is currently not defined; its purpose is to provide a mechanism for a more elaborate error reporting structure, should the reason arise. 4. Theory of Operation 4.1. Sending an MPLS Echo Request An MPLS echo request is a (possibly) labelled UDP packet. The IP header is set as follows: the source IP address is a routable address @@ -791,24 +1032,170 @@ + +4.9 Exercising Multipath + + A test traffic ingress upon receiving an Echo Reply containing a + Downstream Multipath Mapping TLV should try to exercise all paths + listed in the Downstream Multipath Mapping TLV. If the "Type of + Multipath" is 1, indicating "per packet split", or 5, indicating + "other or unspecified", then random addresses in the range of 127/8 + should be used. + + If the "Type of Multipath" in the Downstream Multipath Mapping TLV + is 2-4, then for test traffic should be sent for each Multipath + Exercise TLV with a label stack or a destination address determined + to exercise each path. + + When further testing an individual branch of a multipath, the + Downstream Multipath Mapping TLV in subsequent Echo Request packets + SHOULD contain only the Multipath Exercise TLV and Downstream + Mapping TLV for the path under test within the Downstream Multipath + Mapping TLV. + + If an addtional multipath branch is encountered downstream of one + or more multipath branches, an intersection of the Multipath + Exercise TLV of the branches under test and each of the branches at + the new branch point must be determined. If the intersection based + on the available information is the null set, each of the prior + branch points must be queried with the highest intersecting label + or address to obtain a new set of Multipath Exercise TLVs from a + different portion of label or address space. + + For example, consider a case where one branchpoint under test has + returned a bitmap of address in the range 127.0.0.0-127.0.4.255, a + destination address 127.0.0.7 is used and a second branch point + returns a sparse bitmap covering 127.0.1.32-127.0.5.31, is + returned, and for a specific path from the second branch point, + there is no intersection between the two bitmaps. An Echo Request + must then be sent with TTL set to deliver the packet to the first + branch point, with a destination address corresponding to the first + destination available in the second bitmap which was beyond the + range of the first bitmap. This process is repeated until there is + an intersection in the returned bitmaps. The intended path can now + be tested. 5. Reliable Reply Path One of the issues that are faced with MPLS ping is to distinguish between a failure in the forward path (the MPLS path being 'pinged') and a failure in the return path. Note that this problem exists with vanilla IP ping as well. In the case of MPLS ping, it is assumed that the IP control and data planes are reliable. However, it could be that the forwarding in the return path is via an MPLS LSP. In this specification, we give two solutions for this problem. One is to set the Router Alert option in the MPLS echo reply. When a From owner-mpls@UU.NET Thu Dec 26 15:33: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 PAA15395 for ; Thu, 26 Dec 2002 15:33: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 QQnuyk01676 for ; Thu, 26 Dec 2002 20:36: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 QQnuyj19584; Thu, 26 Dec 2002 20:27:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQnuyj29620 for mpls-outgoing; Thu, 26 Dec 2002 20:27: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 QQnuyj29615 for ; Thu, 26 Dec 2002 20:27:13 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 QQnuyj21530 for ; Thu, 26 Dec 2002 20:26: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 QQnuyj18671 for ; Thu, 26 Dec 2002 20:26:46 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 QQnuyj18657 for ; Thu, 26 Dec 2002 20:26:45 GMT Received: from lanmhs30.rd.francetelecom.fr ([10.193.21.61]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Dec 2002 21:26:30 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2AD1D.12818972" x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Subject: Comments about draft-vasseur-mpls-computation-rsvp-03.txt Date: Thu, 26 Dec 2002 21:26:29 +0100 Message-ID: <1FB136FD10CE33409C882630E299F5BED0F89B@lanmhs30.rd.francetelecom.fr> Thread-Topic: Comments about draft-vasseur-mpls-computation-rsvp-03.txt Thread-Index: AcKtHREOz5yGGPpbS0ip5jst0RbhaA== From: "LE ROUX Jean-Louis FTRD/DAC/LAN" To: Cc: X-OriginalArrivalTime: 26 Dec 2002 20:26:30.0257 (UTC) FILETIME=[12E6D610:01C2AD1D] Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C2AD1D.12818972 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi JP and all, I have several comments regarding = draft-vasseur-mpls-computation-rsvp-03.txt Except several points mentionned below, requiring several = clarifications,=20 this ID results IMHO a good base for PCC-PCS signaling. What is the current status of this draft ?=20 Has there already been a call for moving to WG document ? Here is a list of points that could require several clarifications: _____________________________________________________________________ *1*:=20 End of the Abstract (p 2) It is mentioned, that Path Computation messages could be used as a UNI = protocol between a CE and a PE.=20 There is no longer other reference to such application in the rest of = the draft, so what do you mean by UNI in such VPN context ? *2*:=20 3.3.1 page 9: T bit definition Processing of T bit requires several clarifications: -If the PCC requests a full path (T bit=3D1), and the PCS can only = compute a partial path, does it send a negative reply ? -If the PCC requests a partial path (T bit =3D 0) and the PCS can = compute a full path, does it replies only a partial path ?=20 And in that case which rules are applied for removing hops ? (for = instance remove all nodes except ASBR ?) It should be interesting to illustrate the use of T bit by an example ( = inter AS scenario...)=20 *3*: 3.3.1 page 9, reoptimization, It is mentioned that=20 "If the PCC has previously requested a Partial ERO, a reoptimization can = still be requested by the PCC, but this implies for the PCS to be = statefull (keep a trace of the previously computed path with the = associated list of strict hops)". Comments: -This assumes that the PCS could compute the full path. -In case the PCC knows the full path thanks to the RRO, Path state = maintaining is not required on the PCS. *4*: 3.3.4, NO_PATH_AVAILABLE object (p 14 & 15) It is mentioned: "Note that several NO_PATH_AVAILABLE" objects may be = included in the Path Computation Reply message, so that the PCS may = indicate the list of constraints for which no path has been found". But how to distinguish a set of independant blocking constraints from a = set of dependant blocking constraints.=20 -By set of independant blocking constraints, I mean a set of constraints = whose relaxation of only one constraint in the set is required to find a = path.=20 -By set of dependant blocking constraints, I mean a set of constraints = whose simultaneous relaxation of all constraints in the set is required = to find a path. A path may be found by relaxing only one blocking constraint at a time, = or by relaxing simultaneously multiple constraints. Example : PCC requests for a bidirectional path with bandwidth 10M Request =3Da,B=3D1, L=3D1 sender_tspec: bw=3D10M -Case 1, the PCS can only find a unidirectional path with bandwidth 10M = or a bidirectional path with bandwidth 9M. In that case a path can be found by relaxing only one constraint -Case 2, the PCS can only find a unidirectional path with bw 9M In that case a path can be found only if two constraints are relaxed With current spec there is no possibility to distinguish the two = replies. Indeed, in both cases it is: Reply =3Da, B=3D1, L=3D1 : Flag=3D0X01, constraint-type=3D 0x0001, = suggested-value=3D 9m : Flag=3D0X01, constraint-type=3D 0x0005, = suggested-value=3D unidir So this object should be modified to take into account constraints = dependancy =20 Proposal: The NO_PATH_AVAILABLE object is made of one or more subobjects = identifying a set of "dependant" constraints In that case we have the following replies: -Case 1: Reply =3Da, B=3D1, L=3D1 : Flag=3D0X01,=20 Subobject 1: constraint-type=3D 0x0001, suggested-value=3D 9m : Flag=3D0X01,=20 Subobject 1: constraint-type=3D 0x0005, suggested value=3D = unidir -Case 2: Reply =3Da, B=3D1, L=3D1 : Flag=3D0X01,=20 Subobject 1: constraint-type=3D 0x0001, suggested value=3D 9m, Subobject 2: constraint-type=3D 0x0005, suggested_value=3D unidir =20 *5*:=20 3.3.4 (p14 & 15): NB-PATH object, S bit definition It is mentioned that "-S=3D0: the PCC requests the computation of (potentially correlated) = number-path paths that SHARE THE SAME SET OF CONSTRAINTS. -S=3D1: the PCC requests the computation of number-path correlated = paths HAVING DIFFERENT SET OF CONSTRAINTS. The set of constraint of each = path is defined in a different Path computation request..." As I understood from the various provided examples :, -In case of global bandwidth request, S is set to 0 and N is set to 1, = because you don't know the number of paths and the bandwidth constraint = for each path, but only the global bandwidth. The answer is a set of paths with potentially distinct bandwidths.=20 Thus these paths don't share the same set of constraints (distinct = bandwidth), and this is not consistent with S=3D0 definition For instance see example 1 or 2 in 3.3.8 (p23 & 24): Path computation of a set of diversely routed paths sharing THE SAME set = of constraints. The reply consists of three paths with distinct = bandwidths x1, x2 and x3, thus not sharing the SAME set of constraints =20 The expression "share the same set of constraints" must be clarified, In example 1 and 2 it seems that bandwidth is not part of constraints. Other comments regarding the case S=3D0 : -What are the values of the tunnel id and LSP id, in SESSION and = Sender_Template objects in a request for multiple paths sharing the same = set of constraints ? This should be clarified in the draft. -The utilisation of Sender_TSpec bw value is not clear. Indeed when = S=3D0 and N=3D0 , It may represent individual path bandwidth or global = bandwidth (case of global bandwidth request). Ex:=20 Request 1: 4 paths sharing the same set of constraints, whose global = bandwidth is X =3D Global bandwidth request Request 2: 4 paths sharing the same set of constraints, whose individual = bandwidth (bw for one LSP) is X With current spec there is no mean to distinguish these two requests. In both cases the request is: =3D Flag: N=3D0, S=3D0, number-path=3D4, =20 sender_tspec: bw=3DX So it should be good to add a flag in order to distinguish request for n = potentially correlated path sharing the same set of constraints = (including bandwidth) , from a global bandwidth request with a fixed = number of paths.(see below, proposed G bit) *6*: (Similar to 5) 3.3.4 Example 3 (p24 & 25) Example 3 is not consistent with examples 1 and 2: Example 1&2: Global bandwidth request, paths share the same set of = constraints (S=3D0) =3D> result is a set of path with distinct = bandwidths. Thus it seems from these two examples that bandwidth is not taken into = consideration when you say "sharing the same set of constaints" Example 3: Global bandwidth request, paths not share the same set of = constraints (S=3D1) Does bandwidth is taken into consideration now when you say "not = sharing the same set of constraints" ? or do you mention other = constraints ? Further more the Request message is not conform to rules with S=3D1. Indeed it is mentioned -Page 16: when S=3D1, "the set of constraints of each path is defined = in a DIFFERENT path computation message, identified by the request ID = number" -Page 18: "If the PCC requests the computation of number-path = correlated paths having different set of constraints, the NB-PATH object = MUST just be present in the first of number-path requests" Here in example 3, S=3D1, but the Path Computation Request message = includes two requests and also one NB-PATH object per request. So it is = not conform to S=3D1 rules. There are two options to correct points 5 and 6 issues : -Option 1: Change S=3D1 rules to make example 3 (3.3.8) request and = reply messages conform, and modify S=3D0 definition -Option 2: Add a third field in NB-PATH flag to explicitely identifiy a = global bandwidth request=20 I suggest the second option, that seems semantically more relevant.=20 Proposed procedure : -Add a third field, G bit, in NB-PATH object flag, in order to = distinguish request for a set of (potentially correlated) paths, = sharing or not the same set of constraints, for which individual LSP = bandwidth are known, from a global bandwidth request, for which = individual LSP bandwidth are not known=20 -Restrict the use of S=3D0 to the Request of a set of paths sharing = exactly the same set of constraints, including bandwidth. G bit rules: G=3D0 : Computation of a set of (potenttialy correlated) paths, whose = bandwidth is known, sharing or not the same set of constraints (S=3D0 | = S=3D1)=20 When G=3D0, N must also be set to 0 G=3D1 : for global bandwidth request: Computation of a set of = (potentially correlated) paths, whose only global bandwidth (sum) is = known. When G=3D1, S must also be set to 1 because the set of path do not = necessarily have the same bandwidth Then there are four cases: 1-Global bandwidth request with fixed number of paths:=20 Computation of exactly N (potentially correlated) paths sharing the same = set of constraint except bandwidth, whose global bandwidth is X. =3D> G=3D1, S=3D1, L=3D0=20 2-Global bandwdith request with undetermined or maximal number of path: Computation of a maximum of N (potentially) correlated) paths sharing = the same set of constaint except bandwidth, whose global bandwidth is X. =3D> G=3D1, S=3D1, L=3D1=20 n may be undetermined ie =3D0xFFFF, in that case it is relevant to = specify min_bandwdith 3-Computation of exactly n (potentially correlated) paths sharing the = same set of constrains, including bandwidth, whose individual bandwidth = is X. =3D>G=3D0, S=3D0, L=3D0 4-Computation of exactly N correlated paths not sharing the same set of = constraints. =3D>G=3D0,S=3D1, L=3D1=20 To my mind this would simplify Path Computation Request processing on = the PCS. Examples 1: Computation of 4 diversly routed paths, sharing same set of = constraints, except bandwidth, whose global bandwidth is 10m=20 Request =3D a =3D Flag: G=3D1, S=3D1, N=3D0, number-path=3D4, = path-correlation=3D0x02 sender_tspec: bw=3D10m 2: Computation of a maximum of 4 diversly routed paths, sharing the same = set of constraints, except bandwidth, whose global bandwidth is 10m , = and minimum lsp bandwidth 2m: Request =3D a =3D Flag: G=3D1, S=3D1, N=3D1, number-path=3D4, = path-correalation=3D0x02 sender_tspec: bw=3D10m : minimum-bw=3D2m 3: Computation of 4 diversly routed paths sharing the same set of = constraints (including bandwidth) with individual bandwidth 10m Request =3D a =3D Flag: G=3D0, S=3D0, N=3D0, number-path=3D4, = path-correlation=3D0x02 sender_tspec: bw=3D10m 4: Computation of 2 diversly routed paths not sharing the same set of = constraints (bw 1 =3D 10M, bw 2=3D5M) Request 1 =3D a =3D Flag: G=3D0, S=3D1, N=3D0, number-path=3D4, = path-correlation=3D0x02 sender_tspec: bw=3D10m =3D a, b Request 2 =3D b sender_tspec: bw=3D5m ________________________________________________________________ ------_=_NextPart_001_01C2AD1D.12818972 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments about draft-vasseur-mpls-computation-rsvp-03.txt

Hi JP and all,

I have several comments regarding = draft-vasseur-mpls-computation-rsvp-03.txt

Except several points mentionned = below,  requiring several clarifications,
this ID results IMHO a good base for = PCC-PCS signaling.
What is the current status of this = draft ?
Has there already been a call for = moving to WG document ?

Here is a list of points that could = require several clarifications:

__________________________________________________________= ___________

*1*:
End of the Abstract (p 2)
It is mentioned, that Path Computation = messages could be used as a UNI protocol between a CE and a PE.
There is no longer other reference to = such application in the rest of the draft, so what do you mean by UNI in = such VPN context ?


*2*:
3.3.1 page 9: T bit definition

Processing of T bit requires several = clarifications:
-If the PCC requests a full path (T = bit=3D1), and the PCS can only compute a partial path, does it send a = negative reply ?

-If the PCC requests a partial path (T = bit =3D 0) and the PCS can compute a full path, does it replies only a = partial path ?

And in that case which rules are = applied for removing hops ? (for instance remove all nodes except ASBR = ?)

It should be interesting to illustrate = the use of T bit by an example ( inter AS scenario...)


*3*:
3.3.1 page 9, reoptimization,
It is mentioned that
"If the PCC has previously = requested a Partial ERO, a reoptimization can still be requested by the = PCC, but this implies for the PCS to be statefull (keep a trace of the = previously computed path with the associated list of strict = hops)".

Comments:
-This assumes that the PCS could = compute the full path.
-In case the PCC knows the full path = thanks to the RRO, Path state maintaining is not required on the = PCS.


*4*:
3.3.4, NO_PATH_AVAILABLE object (p 14 = & 15)

It is mentioned: "Note that = several NO_PATH_AVAILABLE" objects may be included in the Path = Computation Reply message, so that the PCS may indicate the list of = constraints for which no path has been found".

But how to distinguish a set of = independant blocking constraints from a set of dependant blocking = constraints.
-By set of independant blocking = constraints, I mean a set of constraints whose relaxation of only one = constraint in the set is required to find a path.

-By set of dependant blocking = constraints, I mean a set of constraints whose simultaneous relaxation = of all constraints in the set is required to find a path.

A path may be found by relaxing only = one blocking constraint at a time, or by relaxing simultaneously = multiple constraints.

Example :
 PCC requests for a bidirectional = path with bandwidth 10M

Request
<SESSION>
<REQUEST-ID>=3Da,B=3D1, = L=3D1
sender_tspec: bw=3D10M

-Case 1, the PCS can only find a = unidirectional path with bandwidth 10M or a bidirectional path with = bandwidth 9M.
In that case a path can be found by = relaxing only one constraint

-Case 2, the PCS can only find a = unidirectional path with bw 9M
In that case a path can be found only = if two constraints are relaxed

With current spec there is no = possibility to distinguish the two replies.
Indeed, in both cases it is:

Reply
<REQUEST-ID>=3Da, B=3D1, = L=3D1
<ERROR-SPEC>
<NO-PATH-AVAILABLE> : = Flag=3D0X01, constraint-type=3D 0x0001, suggested-value=3D 9m
<NO-PATH-AVAILABLE> : = Flag=3D0X01, constraint-type=3D 0x0005, suggested-value=3D unidir

So this object should be modified to = take into account constraints dependancy
 
Proposal: The NO_PATH_AVAILABLE object = is made of one or more subobjects identifying a set of = "dependant" constraints

In that case we have the following = replies:

-Case 1:
Reply
<REQUEST-ID>=3Da, B=3D1, = L=3D1
<ERROR-SPEC>
<NO-PATH-AVAILABLE> : = Flag=3D0X01,
        Subobject 1: constraint-type=3D 0x0001, = suggested-value=3D 9m
<NO-PATH-AVAILABLE> : = Flag=3D0X01,
         &nbs= p; Subobject 1: constraint-type=3D 0x0005, suggested value=3D = unidir

-Case 2:
Reply
<REQUEST-ID>=3Da, B=3D1, = L=3D1
<ERROR-SPEC>
<NO-PATH-AVAILABLE> : = Flag=3D0X01,
        Subobject 1: constraint-type=3D 0x0001, suggested = value=3D 9m,
        Subobject 2: constraint-type=3D 0x0005, = suggested_value=3D unidir
 

*5*:
3.3.4 (p14 & 15): NB-PATH = object,  S bit definition

It is mentioned that
 "-S=3D0: the PCC requests = the computation of (potentially correlated) number-path paths that SHARE = THE SAME SET OF CONSTRAINTS.

  -S=3D1: the PCC requests the = computation of number-path correlated paths HAVING DIFFERENT SET OF = CONSTRAINTS. The set of constraint of each path is defined in a = different Path computation request..."

As I understood from the various = provided examples :,
-In case of global bandwidth request, = S is set to 0 and N is set to 1, because you don't know the number of = paths and the bandwidth constraint for each path, but only the global = bandwidth.

The answer is a set of paths with = potentially distinct bandwidths.
Thus these paths don't share the same = set of constraints (distinct bandwidth), and this is not consistent with = S=3D0 definition

For instance see example 1 or 2 in = 3.3.8 (p23 & 24):
Path computation of a set of diversely = routed paths sharing THE SAME set of constraints. The reply consists of = three paths with distinct bandwidths x1, x2 and x3, thus not sharing the = SAME set of constraints

 
The expression "share the same = set of constraints" must be clarified,
In example 1 and 2 it seems that = bandwidth is not part of constraints.


Other comments regarding the case S=3D0 = :

-What are the values of the tunnel id = and LSP id, in SESSION and Sender_Template objects in a request for = multiple paths sharing the same set of constraints ?

This should be clarified in the = draft.

-The utilisation of Sender_TSpec bw = value is not clear. Indeed when S=3D0 and N=3D0 , It may represent  = individual path bandwidth or global bandwidth (case of global bandwidth = request).

Ex:

Request 1: 4 paths sharing the same set = of constraints, whose global bandwidth is X =3D Global bandwidth = request
Request 2: 4 paths sharing the same = set of constraints, whose individual bandwidth (bw for one LSP) is = X

With current spec there is no mean to = distinguish these two requests.
In both cases the request is:
<SESSION>
<REQUEST-ID>
<NB-PATH>=3D Flag: N=3D0, S=3D0, = number-path=3D4, 
sender_tspec: bw=3DX

So it should be good to add a flag in = order to distinguish request for n potentially correlated path sharing = the same set of constraints (including bandwidth) , from a global = bandwidth request with a fixed number of paths.(see below, proposed G = bit)


*6*: (Similar to 5)
3.3.4 Example 3 (p24 & 25)

Example 3 is not consistent with = examples 1 and 2:

Example 1&2: Global bandwidth = request,  paths share the same set of constraints (S=3D0) =3D> = result is a set of path with distinct bandwidths.

Thus it seems from these two examples = that bandwidth is not taken into consideration when you say = "sharing the same set of constaints"

Example 3: Global bandwidth = request,  paths not share the same set of constraints = (S=3D1)
Does bandwidth is taken into = consideration now when you say  "not sharing the same set of = constraints"  ? or do you mention other constraints = ?

Further more the Request message is not = conform to rules with S=3D1.
Indeed it is mentioned
        -Page 16: when S=3D1, "the set of constraints of = each path is defined in a DIFFERENT path computation message, identified = by the request ID number"

        -Page 18: "If the PCC requests the computation of = number-path correlated paths having different set of constraints, the = NB-PATH object MUST just be present in the first of number-path = requests"

Here in example 3, S=3D1, but the Path = Computation Request message includes two requests  and also one = NB-PATH object per request. So it is not conform to S=3D1 = rules.


There are two options to correct points = 5 and 6 issues :
        -Option 1: Change S=3D1 rules to make example 3 (3.3.8) = request and reply messages conform, and modify S=3D0 = definition

        -Option 2: Add a third field in NB-PATH flag to = explicitely identifiy a global bandwidth request

I suggest the second option, that seems = semantically more relevant.
Proposed procedure :
        -Add a third field, G bit, in NB-PATH object flag, in = order to distinguish request for a set of  (potentially correlated) = paths, sharing or not the     same set of constraints, = for which individual LSP bandwidth are known, from a global bandwidth = request, for which individual LSP bandwidth are  not known =

        -Restrict the use of S=3D0 to the Request of a set of = paths sharing exactly the same      set of = constraints, including bandwidth.

G bit rules:
G=3D0 : Computation of a set of = (potenttialy correlated) paths, whose bandwidth is known, sharing or not = the same set of constraints (S=3D0 | S=3D1)

When G=3D0, N must also be set to = 0

G=3D1 : for global bandwidth request: = Computation of a set of (potentially correlated) paths, whose only = global bandwidth (sum) is known.

When G=3D1, S must also be set to 1 = because the set of path do not necessarily have the same = bandwidth

Then there are four cases:

1-Global bandwidth request with fixed = number of paths:
Computation of exactly N (potentially = correlated) paths sharing the same set of constraint except bandwidth, = whose global bandwidth is X.

 =3D> G=3D1, S=3D1, L=3D0 =

2-Global bandwdith request with = undetermined or maximal number of path:
Computation of a maximum of N = (potentially) correlated) paths sharing the same set of constaint except = bandwidth, whose global bandwidth is X.

 =3D> G=3D1, S=3D1, L=3D1 =
n may be undetermined ie =3D0xFFFF, in = that case it is relevant to specify min_bandwdith

3-Computation of exactly n  = (potentially correlated) paths sharing the same set of constrains, = including bandwidth, whose individual bandwidth is X.

=3D>G=3D0, S=3D0, L=3D0

4-Computation of exactly N correlated = paths not sharing the same set of constraints.
=3D>G=3D0,S=3D1, L=3D1

To my mind this would simplify Path = Computation Request processing on the PCS.


Examples

1: Computation of 4 diversly routed = paths, sharing same set of constraints, except bandwidth, whose global = bandwidth is 10m

Request
<SESSION>
<REQUEST-ID>=3D a
<NB-PATH>=3D Flag: G=3D1, S=3D1, = N=3D0, number-path=3D4, path-correlation=3D0x02
sender_tspec: bw=3D10m

2: Computation of a maximum of 4 = diversly routed paths, sharing the same set of constraints, except = bandwidth, whose global bandwidth is 10m , and minimum lsp bandwidth = 2m:

Request
<SESSION>
<REQUEST-ID>=3D a
<NB-PATH>=3D Flag: G=3D1, S=3D1, = N=3D1, number-path=3D4, path-correalation=3D0x02
sender_tspec: bw=3D10m
<MIN-BW>: minimum-bw=3D2m

3: Computation of 4 diversly routed = paths sharing the same set of constraints (including bandwidth) with = individual bandwidth 10m

Request
<SESSION>
<REQUEST-ID>=3D a
<NB-PATH>=3D Flag: G=3D0, S=3D0, = N=3D0, number-path=3D4, path-correlation=3D0x02
sender_tspec: bw=3D10m

4: Computation of 2 diversly routed = paths not sharing the same set of constraints (bw 1 =3D 10M, bw = 2=3D5M)
Request 1
<SESSION>
<REQUEST-ID>=3D a
<NB-PATH>=3D Flag: G=3D0, S=3D1, = N=3D0, number-path=3D4, path-correlation=3D0x02
sender_tspec: bw=3D10m
<PATH_CORRELATED>=3D a, b

Request 2
<REQUEST-ID>=3D b
sender_tspec: bw=3D5m

__________________________________________________________= ______


------_=_NextPart_001_01C2AD1D.12818972-- From owner-mpls@UU.NET Mon Dec 30 03:14:14 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 DAA19932 for ; Mon, 30 Dec 2002 03:14:14 -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 QQnvlh14842 for ; Mon, 30 Dec 2002 08:17: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 QQnvlh13411; Mon, 30 Dec 2002 08:16:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQnvlh18510 for mpls-outgoing; Mon, 30 Dec 2002 08:16: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 QQnvlh18460 for ; Mon, 30 Dec 2002 08:16:04 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 QQnvlg23885 for ; Mon, 30 Dec 2002 08:14: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 QQnvlg11699 for ; Mon, 30 Dec 2002 08:14:27 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 QQnvlg11671 for ; Mon, 30 Dec 2002 08:14:25 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 gBU8EMe19569 for ; Mon, 30 Dec 2002 13:44:23 +0530 (IST) Received: from chn-snr-msg.wipro.com ([10.145.50.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 30 Dec 2002 13:44:17 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-75d728e2-123d-11d7-ba7f-006067005148" Subject: MPLS OAM Date: Mon, 30 Dec 2002 13:44:17 +0530 Message-ID: Thread-Topic: MPLS OAM Thread-Index: AcKv2+r86Y3sSd5DTX24G9fhzlElpg== From: "Deepak Sathyamurthy" To: X-OriginalArrivalTime: 30 Dec 2002 08:14:17.0812 (UTC) FILETIME=[72C6B940:01C2AFDB] Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPartTM-000-75d728e2-123d-11d7-ba7f-006067005148 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2AFDB.728E8198" ------_=_NextPart_001_01C2AFDB.728E8198 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 There are various proposals for supporting trace route and ping on MPLS. = IP ping and trace route use RFC 2925 MIB. Will there be any changes, = additions required to this MIB for supporting MPLS ping and trace route? =20 Regards, Deepak ------_=_NextPart_001_01C2AFDB.728E8198 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi,
 
There = are various=20 proposals for supporting trace route and ping on MPLS. IP ping and = trace route=20 use RFC 2925 MIB. Will there be any changes, additions required to this = MIB for=20 supporting MPLS ping and trace route?
 
Regards,
Deepak
------_=_NextPart_001_01C2AFDB.728E8198-- ------=_NextPartTM-000-75d728e2-123d-11d7-ba7f-006067005148-- From owner-mpls@UU.NET Mon Dec 30 10:39: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 KAA25721 for ; Mon, 30 Dec 2002 10:39:39 -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 QQnvmk07235 for ; Mon, 30 Dec 2002 15:42: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 QQnvmk00871; Mon, 30 Dec 2002 15:39:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQnvmk00104 for mpls-outgoing; Mon, 30 Dec 2002 15:38: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 QQnvmk00096 for ; Mon, 30 Dec 2002 15:38:38 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 QQnvmk16136 for ; Mon, 30 Dec 2002 15:38: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 QQnvmk16425 for ; Mon, 30 Dec 2002 15:38:18 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 QQnvmk16002 for ; Mon, 30 Dec 2002 15:38:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBUFcdEI015995 for ; Mon, 30 Dec 2002 10:38:40 -0500 (EST) 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 KAA23719 for ; Mon, 30 Dec 2002 10:38:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBUFc2N12595 for mpls@uu.net; Mon, 30 Dec 2002 10:38: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 QQnvmk29891 for ; Mon, 30 Dec 2002 15:36:38 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 QQnvmk15297 for ; Mon, 30 Dec 2002 15:35: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 QQnvmk28075 for ; Mon, 30 Dec 2002 15:35:50 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 QQnvmk28042 for ; Mon, 30 Dec 2002 15:35: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 KAA25049; Mon, 30 Dec 2002 10:33:30 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200212301533.KAA25049@workhorse.fictitious.org> To: "Deepak Sathyamurthy" cc: mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: MPLS OAM In-reply-to: Your message of "Mon, 30 Dec 2002 13:44:17 +0530." Date: Mon, 30 Dec 2002 10:33:30 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , "Dee pak Sathyamurthy" writes: > > Hi, > =20 > There are various proposals for supporting trace route and ping on MPLS. = > IP ping and trace route use RFC 2925 MIB. Will there be any changes, = > additions required to this MIB for supporting MPLS ping and trace route? > =20 > Regards, > Deepak Deepak, First of all, not all MIBs that are defined get used in practice. I know of no ISP that is using the ping MIB to drive pings or collect information. It is just too inefficient to do things that way. I don't think any routers implement it. I welcome any corrections. The tier one ISPs that I know have been and probably still are using pings are either doing ad-hoc testing or driving tests from pizza boxes (1U rackmounts) running *ix that do statistical collection and if applicable raise alarms by other means. In some cases one way measurements are made rather than use ping at all. Traceroute is almost always strictly ad-hoc testing or very customized information gathering such as the CAIDA skitter program (which doesn't use a MIB). If we end up doing an LSP-ping MIB, which too may go unused, then someone that thinks it will be used can write it. IMHO it can be a separate document. Curtis From owner-mpls@UU.NET Mon Dec 30 10:50: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 KAA25858 for ; Mon, 30 Dec 2002 10:50:41 -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 QQnvml08116 for ; Mon, 30 Dec 2002 15:53:43 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 QQnvml04858; Mon, 30 Dec 2002 15:52:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQnvml01447 for mpls-outgoing; Mon, 30 Dec 2002 15:51:33 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 QQnvml01432 for ; Mon, 30 Dec 2002 15:51:21 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 QQnvml03911 for ; Mon, 30 Dec 2002 15:51: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 QQnvml03003 for ; Mon, 30 Dec 2002 15:51:05 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 QQnvml02987 for ; Mon, 30 Dec 2002 15:51:04 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBUFpf8i017607 for ; Mon, 30 Dec 2002 10:51:41 -0500 (EST) 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 KAA24521 for ; Mon, 30 Dec 2002 10:51:03 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBUFp3d14743 for mpls@uu.net; Mon, 30 Dec 2002 10:51: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 QQnvml01357 for ; Mon, 30 Dec 2002 15:49:36 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 QQnvml26735 for ; Mon, 30 Dec 2002 15:47: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 QQnvml27740 for ; Mon, 30 Dec 2002 15:47:54 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 QQnvml27697 for ; Mon, 30 Dec 2002 15:47:53 GMT Received: from asimha-u10.cisco.com (asimha-u10.cisco.com [64.102.48.65]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBUFlUFp011091; Mon, 30 Dec 2002 07:47:30 -0800 (PST) Received: (asimha@localhost) by asimha-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA03344; Mon, 30 Dec 2002 10:47:30 -0500 (EST) Date: Mon, 30 Dec 2002 10:47:30 -0500 From: Ajay Simha To: Curtis Villamizar Cc: Deepak Sathyamurthy , mpls@UU.NET Subject: Re: MPLS OAM Message-ID: <20021230154730.GD3081@cisco.com> References: <200212301533.KAA25049@workhorse.fictitious.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200212301533.KAA25049@workhorse.fictitious.org> User-Agent: Mutt/1.4i Sender: owner-mpls@UU.NET Precedence: bulk On Mon Dec 30 10:33:30 2002, Curtis Villamizar wrote: > > In message , "Dee > pak Sathyamurthy" writes: > > > > Hi, > > =20 > > There are various proposals for supporting trace route and ping on MPLS. = > > IP ping and trace route use RFC 2925 MIB. Will there be any changes, = > > additions required to this MIB for supporting MPLS ping and trace route? > > =20 > > Regards, > > Deepak > > > Deepak, > > First of all, not all MIBs that are defined get used in practice. I > know of no ISP that is using the ping MIB to drive pings or collect > information. It is just too inefficient to do things that way. I > don't think any routers implement it. I welcome any corrections. Cisco routers support ping MIB. > > The tier one ISPs that I know have been and probably still are using > pings are either doing ad-hoc testing or driving tests from pizza > boxes (1U rackmounts) running *ix that do statistical collection and > if applicable raise alarms by other means. In some cases one way > measurements are made rather than use ping at all. Traceroute is > almost always strictly ad-hoc testing or very customized information > gathering such as the CAIDA skitter program (which doesn't use a MIB). > > If we end up doing an LSP-ping MIB, which too may go unused, then > someone that thinks it will be used can write it. IMHO it can be a > separate document. I agree it needs to be a seperate doc that the LSP Ping doc. Cheers.. -ajay > > Curtis From owner-mpls@UU.NET Mon Dec 30 13:01: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 NAA28498 for ; Mon, 30 Dec 2002 13:01:21 -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 QQnvmu12730 for ; Mon, 30 Dec 2002 18:04: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 QQnvmu09379; Mon, 30 Dec 2002 18:02:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQnvmu27903 for mpls-outgoing; Mon, 30 Dec 2002 18:01:53 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 QQnvmu27838 for ; Mon, 30 Dec 2002 18:01:36 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 QQnvmu28177 for ; Mon, 30 Dec 2002 18:01: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 QQnvmu15848 for ; Mon, 30 Dec 2002 18:01:06 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 QQnvmu15832 for ; Mon, 30 Dec 2002 18:01:05 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBUI1fDJ003140 for ; Mon, 30 Dec 2002 13:01:42 -0500 (EST) 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 NAA03048 for ; Mon, 30 Dec 2002 13:01:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBUI12U22639 for mpls@uu.net; Mon, 30 Dec 2002 13:01: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 QQnvmt17650 for ; Mon, 30 Dec 2002 17:59: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 QQnvmt12861 for ; Mon, 30 Dec 2002 17:57: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 QQnvmt12157 for ; Mon, 30 Dec 2002 17:57:30 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 QQnvmt12153 for ; Mon, 30 Dec 2002 17:57:29 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBUHvxNC002610; Mon, 30 Dec 2002 12:57:59 -0500 (EST) Received: from eosborne-u10.cisco.com (eosborne-u10.cisco.com [161.44.134.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA02769; Mon, 30 Dec 2002 12:57:21 -0500 (EST) Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA03830; Mon, 30 Dec 2002 12:57:21 -0500 (EST) Date: Mon, 30 Dec 2002 12:57:21 -0500 From: Eric Osborne To: Ajay Simha Cc: Curtis Villamizar , Deepak Sathyamurthy , mpls@UU.NET Subject: Re: MPLS OAM Message-ID: <20021230125720.V2319@eosborne-u10.cisco.com> References: <200212301533.KAA25049@workhorse.fictitious.org> <20021230154730.GD3081@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20021230154730.GD3081@cisco.com>; from asimha@cisco.com on Mon, Dec 30, 2002 at 10:47:30AM -0500 X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk > > First of all, not all MIBs that are defined get used in practice. I > > know of no ISP that is using the ping MIB to drive pings or collect > > information. It is just too inefficient to do things that way. I > > don't think any routers implement it. I welcome any corrections. > > Cisco routers support ping MIB. > ...and I've talked to one customer that uses it, but I think it's safe to say that ping MIB isn't the most popular networking tool known to man..:) eric > > > > The tier one ISPs that I know have been and probably still are using > > pings are either doing ad-hoc testing or driving tests from pizza > > boxes (1U rackmounts) running *ix that do statistical collection and > > if applicable raise alarms by other means. In some cases one way > > measurements are made rather than use ping at all. Traceroute is > > almost always strictly ad-hoc testing or very customized information > > gathering such as the CAIDA skitter program (which doesn't use a MIB). > > > > If we end up doing an LSP-ping MIB, which too may go unused, then > > someone that thinks it will be used can write it. IMHO it can be a > > separate document. > > I agree it needs to be a seperate doc that the LSP Ping doc. > > Cheers.. > > -ajay > > > > Curtis From owner-mpls@UU.NET Mon Dec 30 14:09: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 OAA00010 for ; Mon, 30 Dec 2002 14:09:43 -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 QQnvmy16130 for ; Mon, 30 Dec 2002 19:12: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 QQnvmy11092; Mon, 30 Dec 2002 19:10:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQnvmy29331 for mpls-outgoing; Mon, 30 Dec 2002 19:09:29 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 QQnvmy29314 for ; Mon, 30 Dec 2002 19:09:15 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 QQnvmy15020 for ; Mon, 30 Dec 2002 19:09: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 QQnvmy09381 for ; Mon, 30 Dec 2002 19:09:04 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 QQnvmy09363 for ; Mon, 30 Dec 2002 19:09:03 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBUJ9emW011175 for ; Mon, 30 Dec 2002 14:09:40 -0500 (EST) 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 OAA07612 for ; Mon, 30 Dec 2002 14:09:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBUJ92U27691 for mpls@uu.net; Mon, 30 Dec 2002 14:09: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 QQnvmy29284 for ; Mon, 30 Dec 2002 19:08:04 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 QQnvmy22835 for ; Mon, 30 Dec 2002 19:07: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 QQnvmy07405 for ; Mon, 30 Dec 2002 19:07:56 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 QQnvmy07391 for ; Mon, 30 Dec 2002 19:07: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 gBUJ8NUh011024; Mon, 30 Dec 2002 14:08:24 -0500 (EST) Received: from tnadeau-w2k.cisco.com (che-vpn-cluster-2-21.cisco.com [10.86.242.21]) by bucket.cisco.com (Mirapoint) with ESMTP id ACI40495; Mon, 30 Dec 2002 14:07:44 -0500 (EST) Message-Id: <5.2.0.9.2.20021230140547.08c1e860@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 30 Dec 2002 14:07:43 -0500 To: curtis@fictitious.org From: "Thomas D. Nadeau" Subject: Re: MPLS OAM Cc: "Deepak Sathyamurthy" , mpls@UU.NET In-Reply-To: <200212301533.KAA25049@workhorse.fictitious.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 10:33 AM 12/30/2002 -0500, Curtis Villamizar wrote: >In message , >"Dee >pak Sathyamurthy" writes: > > > > Hi, > > =20 > > There are various proposals for supporting trace route and ping on MPLS. = > > IP ping and trace route use RFC 2925 MIB. Will there be any changes, = > > additions required to this MIB for supporting MPLS ping and trace route? > > =20 > > Regards, > > Deepak > > >Deepak, > >First of all, not all MIBs that are defined get used in practice. I >know of no ISP that is using the ping MIB to drive pings or collect >information. It is just too inefficient to do things that way. I >don't think any routers implement it. I welcome any corrections. There are actually many of my customers using the standard and Cisco-proprietary version of the Ping MIB. However, as Curtis points out, on a large scale, use of the MIB directly is problematic for performance reasons. This is why many of our customers have moved to using a more automated (proprietary) system called SAA. >The tier one ISPs that I know have been and probably still are using >pings are either doing ad-hoc testing or driving tests from pizza >boxes (1U rackmounts) running *ix that do statistical collection and >if applicable raise alarms by other means. In some cases one way >measurements are made rather than use ping at all. Traceroute is >almost always strictly ad-hoc testing or very customized information >gathering such as the CAIDA skitter program (which doesn't use a MIB). > >If we end up doing an LSP-ping MIB, which too may go unused, then >someone that thinks it will be used can write it. IMHO it can be a >separate document. It can probably be written as a MIB that augments the existing one. --Tom From owner-mpls@UU.NET Mon Dec 30 22: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 WAA06633 for ; Mon, 30 Dec 2002 22:20:19 -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 QQnvof25278 for ; Tue, 31 Dec 2002 03:23:24 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 QQnvof22094; Tue, 31 Dec 2002 03:21:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQnvof06107 for mpls-outgoing; Tue, 31 Dec 2002 03:20: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 QQnvof06092 for ; Tue, 31 Dec 2002 03:20: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 QQnvof16310 for ; Tue, 31 Dec 2002 03:20: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 QQnvof19729 for ; Tue, 31 Dec 2002 03:20:04 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 QQnvof19657 for ; Tue, 31 Dec 2002 03:20:03 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBV3KdDB000553 for ; Mon, 30 Dec 2002 22:20:40 -0500 (EST) 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 WAA01984 for ; Mon, 30 Dec 2002 22:20:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBV3K1W22725 for mpls@uu.net; Mon, 30 Dec 2002 22:20:01 -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 QQnvof06032 for ; Tue, 31 Dec 2002 03:18:45 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 QQnvof11387 for ; Tue, 31 Dec 2002 03:18: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 QQnvof19977 for ; Tue, 31 Dec 2002 03:18:26 GMT Received: from aptab by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: [210.83.134.186]) id QQnvof19969 for ; Tue, 31 Dec 2002 03:18:24 GMT From: Batty Rathbun To: Subject: Repair of cells and metabolic functions a Date: Tue, 31 Dec 2002 11:19:52 -0800 Mime-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: base64 Message-Id: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5gV2hhdCdzIHNvIHVucGxlYXNlbnQgYWJvdXQgYmVp bmcgZHJ1bms/JzwvdGl0bGU+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4NCjwvaGVhZD4NCg0KPGJv ZHk+DQo8dGFibGUgd2lkdGg9IjYwMCIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iNCIgY2Vs bHNwYWNpbmc9IjAiPg0KICA8dHI+DQogICAgPHRkIHJvd3NwYW49IjIiIHZhbGlnbj0idG9w Ij48YSBocmVmPSJodHRwOi8vd3d3LnNob3BwaW5nYWxsdGhld2F5LmNvbS9oZ2gvd2VsY29t ZTIuaHRtbD9hZmZpZD1vODg4JmU9bXBsc0B1dS5uZXQiPjxpbWcgc3JjPSJodHRwOi8vMjEw LjIyLjE0NC4xOTgvZW1haWwuanBnIiBib3JkZXI9MD48L2E+PC90ZD4NCiAgICA8dGQgdmFs aWduPSJ0b3AiIGFsaWduPSJjZW50ZXIiPjxmb250IGNvbG9yPSIjRkYwMDAwIiBzaXplPSI0 IiBmYWNlPSJHZW5ldmEsIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPjxlbT48c3Ry b25nPlRoZSANCiAgICAgIEFudGktQWdpbmcgUG93ZXI6IEhHSCBQcm9kdWN0czwvc3Ryb25n PjwvZW0+PC9mb250PjwvdGQ+DQogIDwvdHI+DQogIDx0cj4NCiAgCTx0ZD48dGFibGUgYm9y ZGVyPSIyIiBib3JkZXJjb2xvcj0iIzAwMzM5OSIgY2VsbHBhZGRpbmc9IjMiIGNlbGxzcGFj aW5nPSIwIj4NCgkJICA8dHI+CQkJDQogICAgICAgICAgPHRkIGJnY29sb3I9IiMwMDMzNjYi PjxkaXYgYWxpZ249ImNlbnRlciI+PGZvbnQgY29sb3I9IiNGRkZGRkYiIGZhY2U9IkFyaWFs LCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPjxzdHJvbmc+PGZvbnQgc2l6ZT0iMyI+Q2xpbmlj YWxseSANCiAgICAgICAgICAgICAgVGVzdGVkIE5hdHVyYWwgSEdIIE9yYWwgU3ByYXkgQm9v c3RzIEVuZXJneSBhbmQgSW1tdW5pdHk8L2ZvbnQ+PC9zdHJvbmc+PC9mb250PjwvZGl2Pjwv dGQ+DQoJCSAgPC90cj4NCgkJICA8dHI+CQkJDQogICAgICAgICAgPHRkIGJnY29sb3I9IiNG RkZGOTkiIHZhbGlnbj0idG9wIj48Zm9udCBzaXplPSIxIiBmYWNlPSJWZXJkYW5hLCBBcmlh bCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIj5JbiANCiAgICAgICAgICAgIEFwcmlsIDIwMDIs IHRoZSBmaXJzdCBwbGFjZWJvLWNvbnRyb2xsZWQgc3R1ZHkgb2YgYSBuYXR1cmFsIEhHSCBv cmFsIA0KICAgICAgICAgICAgc3ByYXkgYXBwZWFyZWQgaW4gdGhlIEpvdXJuYWwgb2YgTG9u Z2V2aXR5LiBUaGlzIHN0dWR5IHJldmVhbGVkIHRoYXQgDQogICAgICAgICAgICB0aGUgc3By YXkgZW5jb3VyYWdlcyBwcm9kdWN0aW9uIG9mIHRoZSBib2R5J3MgIm1hc3RlciBob3Jtb25l IiwgYWxzbyANCiAgICAgICAgICAgIGtub3duIGFzIEhHSCBvciBIdW1hbiBHcm93dGggSG9y bW9uZS4gSW4gY29uY2x1c2lvbiwgdGhlIHJlc2VhcmNoZXJzIA0KICAgICAgICAgICAgZGlz Y292ZXJlZCB0aGF0IHRoZSBoaWdoIGFic29ycHRpb24gcmF0ZSBwcm92aWRlZCBieSB0aGUg b3JhbCBzcHJheSANCiAgICAgICAgICAgIHN5c3RlbSBpbmNyZWFzZWQgSEdIIGluIHRoZSBi b2R5IGJ5IDMwJSBpbiBvbmx5IHRocmVlIHdlZWtzLiBBbiBpbmNyZWFzZSANCiAgICAgICAg ICAgIG9mIEhHSCBwcm9kdWN0aW9uIHByb3ZlcyB0byBib29zdCBlbmVyZ3kgYW5kIHN0cmVu Z3RoZW4gaW1tdW5pdHkuIDwvZm9udD48L3RkPg0KCQkgIDwvdHI+DQoJCTwvdGFibGU+DQoJ PC90ZD4NCiAgPC90cj4NCiAgPHRyPg0KICAgIDx0ZCBjb2xzcGFuPSIiPjxkaXYgYWxpZ249 ImNlbnRlciI+PHN0cm9uZz48Zm9udCBjb2xvcj0iI0ZGMDAwMCIgc2l6ZT0iMyIgZmFjZT0i VmVyZGFuYSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiI+PGVtPlNwZWNpYWwhIA0K ICAgICAgICA8YnI+DQogICAgICAgIEZvciBsaW1pdGVkIHRpbWUgb25seSE8L2VtPjwvZm9u dD48Zm9udCBjb2xvcj0iI0ZGMDAwMCIgc2l6ZT0iMyIgZmFjZT0iVmVyZGFuYSwgQXJpYWws IEhlbHZldGljYSwgc2Fucy1zZXJpZiI+PGJyPg0KICAgICAgICA8Zm9udCBzaXplPSI0Ij48 YSBocmVmPSJodHRwOi8vd3d3LnNob3BwaW5nYWxsdGhld2F5LmNvbS9oZ2gvd2VsY29tZTIu aHRtbD9hZmZpZD1qZiI+QlVZIDIgR0VUIDEgRlJFRSE8L2E+PC9mb250PjwvZm9udD48L3N0 cm9uZz48L2Rpdj48L3RkPg0KCTx0ZCBhbGlnbj0iY2VudGVyIiB2YWxpZ249Im1pZGRsZSI+ PGEgaHJlZj0iaHR0cDovL3d3dy5zaG9wcGluZ2FsbHRoZXdheS5jb20vaGdoL3dlbGNvbWUy Lmh0bWw/YWZmaWQ9bzg4OCZlPW1wbHNAdXUubmV0Ij48aW1nIHNyYz0iaHR0cDovLzIxMC4y Mi4xNDQuMTk4L2VtYWlsLW9yZGVyLmpwZyIgd2lkdGg9IjIwMCIgaGVpZ2h0PSI4MSIgYm9y ZGVyPTA+PC9hPjwvdGQ+DQogIDwvdHI+DQogIDx0cj4NCiAgCTx0ZD48dGFibGUgd2lkdGg9 IjEwMCUiIGJvcmRlcj0iMiIgYm9yZGVyY29sb3I9IiM2Njk5RkYiIGJnY29sb3I9IiNGRkZG Q0MiIGNlbGxwYWRkaW5nPSI1IiBjZWxsc3BhY2luZz0iMCI+DQogICAgICAgIDx0cj4NCiAg ICAgICAgICA8dGQ+PGRpdiBhbGlnbj0iY2VudGVyIj48Zm9udCBjb2xvcj0iIzAwMzM5OSIg c2l6ZT0iMiIgZmFjZT0iVmVyZGFuYSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiI+ PHN0cm9uZz48Zm9udCBzaXplPSIxIj5NYWRlIA0KICAgICAgICAgICAgICBmcm9tIGFtaW5v IGFjaWRzIGFuZCBoZXJicywgbmF0dXJhbCBIR0ggY2FuIGhlbHAgeW91OiA8L2ZvbnQ+PC9z dHJvbmc+PC9mb250PjwvZGl2Pg0KICAgICAgICAgICAgPHVsPg0KICAgICAgICAgICAgICA8 bGk+PGZvbnQgY29sb3I9IiMzMzY2MDAiIHNpemU9IjEiPjxzdHJvbmc+PGZvbnQgZmFjZT0i VmVyZGFuYSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiI+PGVtPkluY3JlYXNlIA0K ICAgICAgICAgICAgICAgIEVuZXJneTwvZW0+PC9mb250Pjwvc3Ryb25nPjwvZm9udD48L2xp Pg0KICAgICAgICAgICAgICA8bGk+PGVtPjxmb250IGNvbG9yPSIjMzM2NjAwIiBzaXplPSIx Ij48c3Ryb25nPjxmb250IGZhY2U9IlZlcmRhbmEsIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMt c2VyaWYiPlN0cmVuZ3RoZW4gDQogICAgICAgICAgICAgICAgSW1tdW5pdHkgPC9mb250Pjwv c3Ryb25nPjwvZm9udD4gPC9lbT4NCiAgICAgICAgICAgICAgPGxpPjxlbT48Zm9udCBjb2xv cj0iIzMzNjYwMCIgc2l6ZT0iMSI+PHN0cm9uZz48Zm9udCBmYWNlPSJWZXJkYW5hLCBBcmlh bCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIj5HYWluIA0KICAgICAgICAgICAgICAgIExlYW4g TXVzY2xlIDwvZm9udD48L3N0cm9uZz48L2ZvbnQ+IDwvZW0+DQogICAgICAgICAgICAgIDxs aT48ZW0+PGZvbnQgY29sb3I9IiMzMzY2MDAiIHNpemU9IjEiPjxzdHJvbmc+PGZvbnQgZmFj ZT0iVmVyZGFuYSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiI+SW1wcm92ZSANCiAg ICAgICAgICAgICAgICBTbGVlcCBRdWFsaXR5IDwvZm9udD48L3N0cm9uZz48L2ZvbnQ+IDwv ZW0+DQogICAgICAgICAgICAgIDxsaT48ZW0+PGZvbnQgY29sb3I9IiMzMzY2MDAiIHNpemU9 IjEiPjxzdHJvbmc+PGZvbnQgZmFjZT0iVmVyZGFuYSwgQXJpYWwsIEhlbHZldGljYSwgc2Fu cy1zZXJpZiI+VHJpbSANCiAgICAgICAgICAgICAgICBZb3VyIFdhaXN0bGluZSA8L2ZvbnQ+ PC9zdHJvbmc+PC9mb250PiA8L2VtPg0KICAgICAgICAgICAgICA8bGk+PGVtPjxmb250IGNv bG9yPSIjMzM2NjAwIiBzaXplPSIxIj48c3Ryb25nPjxmb250IGZhY2U9IlZlcmRhbmEsIEFy aWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPlNtb290aCANCiAgICAgICAgICAgICAgICBZ b3VyIFNraW4gPC9mb250Pjwvc3Ryb25nPjwvZm9udD4gPC9lbT4NCiAgICAgICAgICAgICAg PGxpPjxlbT48Zm9udCBjb2xvcj0iIzMzNjYwMCIgc2l6ZT0iMSI+PHN0cm9uZz48Zm9udCBm YWNlPSJWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIj5TdHJlbmd0aGVu IA0KICAgICAgICAgICAgICAgIEhhaXIgJiBOYWlscyA8L2ZvbnQ+PC9zdHJvbmc+PC9mb250 PjwvZW0+IA0KICAgICAgICAgICAgPC91bD48L3RkPg0KICAgICAgICA8L3RyPg0KICAgICAg PC90YWJsZT48L3RkPg0KCTx0ZCB2YWxpZ249InRvcCIgYWxpZ249ImNlbnRlciI+PHA+PGZv bnQgc2l6ZT0iMSIgZmFjZT0iVmVyZGFuYSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJp ZiI+PHN0cm9uZz5SZWFkIA0KICAgICAgICB0aGVzZSB0ZXN0aW1vbmlhbHM6PGJyPjxicj4N CiAgICAgICAgPGVtPpNJIGFtIGhhdmluZyB0aGUgbW9zdCBpbmNyZWRpYmxlIHJlc3VsdHMg d2l0aCBIR0ggLiAuIC6UPC9lbT48YnI+DQogICAgICAgIDxmb250IGNvbG9yPSIjMzM2Njk5 Ij5DLiBDLiAoRmVtYWxlLCA1OCk8YnI+DQogICAgICAgIERlcyBNb2luZXMsIElBPC9mb250 Pjxicj4NCiAgICAgICAgPGJyPg0KICAgICAgICA8ZW0+k0hHSCBoYXMgZ2l2ZW4gbWUgZW5l cmd5LCBpbXByb3ZlZCBtZW1vcnksIGVuZHVyYW5jZS4uLiBrZXB0IHdlaWdodCANCiAgICAg ICAgb2ZmIGFuZCBjb250cm9sbGVkIG15IGFwcGV0aXRlLiBJdJJzIGhlbHBlZCBtZSBhIGxv dCGUIDwvZW0+PGJyPg0KICAgICAgICA8Zm9udCBjb2xvcj0iIzMzNjY5OSI+Um9iIFNtaXRo IChNYWxlLCAzNCk8YnI+DQogICAgICAgIE5ldyBZb3JrLCBOWTwvZm9udD48YnI+DQogICAg ICAgIDxicj4NCiAgICAgICAgPGVtPpNJIGhhdmUgZW5lcmd5LCBncmVhdCB3ZWxsLWJlaW5n LCBJknZlIGxvc3Qgd2VpZ2h0IGFuZCBpbmNoZXMgYW5kIA0KICAgICAgICBteSBtdXNjbGVz IGFyZSB0b25lZC4gUHJpb3IgdG8gSEdILCBJIGNvdWxkbpJ0IGxvc2Ugd2VpZ2h0IG5vciBl bmR1cmUgDQogICAgICAgIHdvcmtvdXRzLiBJIGZlZWwgd29uZGVyZnVsIGFsbCB0aGUgdGlt ZSGUPC9lbT48YnI+DQogICAgICAgIDxmb250IGNvbG9yPSIjMzM2Njk5Ij5MLiBTLiAoRmVt YWxlLCA1MSk8YnI+DQogICAgICAgIFdhbGRvcmYsIE1EPC9mb250Pjwvc3Ryb25nPjwvZm9u dD48L3A+DQo8cCBhbGlnbj0iY2VudGVyIj48YSBocmVmPSJodHRwOi8vd3d3LnNob3BwaW5n YWxsdGhld2F5LmNvbS9oZ2gvd2VsY29tZTIuaHRtbD9hZmZpZD1vODg4JmU9bXBsc0B1dS5u ZXQiPjxoMz48Zm9udCBmYWNlPVZlcmRhbmE+SSB3YW50IHRvIHN0YXJ0IGZlZWwgYmV0dGVy IHRvZGF5ITwvZm9udD48L2gzPjwvYT4NCiAgICAgIDwvdGQ+DQogIDwvdHI+DQogIDx0cj48 dGQgY29sc3Bhbj0iMiI+PGhyIHdpZHRoPSI5OSUiIHNpemU9IjEiPg0KDQogIDwvdGQ+PC90 cj4NCjwvdGFibGU+DQo8cD48Zm9udCBmYWNlPUFyaWFsIHNpemU9MT5Zb3UgcmVjZWl2ZWQg dGhpcyBlbWFpbCBiZWNhdXNlIHlvdSBzaWduZWQgdXAgd2l0aCBvbmUgb2YgUm9ja2V0IE1l ZGlhJ3Mgd2Vic2l0ZXMgb3IgeW91IHNpZ25lZCB1cCB3aXRoIGEgcGFydHkgdGhhdCBoYXMg Y29udHJhY3RlZCB3aXRoIFJvY2tldCBNZWRpYS4gVG8gdW5zdWJzY3JpYmUNCiBmcm9tIG91 ciBmdXR1cmUgbWFpbGluZywgcGxlYXNlIDxhIGhyZWY9Imh0dHA6Ly93d3cuc2hvcHBpbmdh bGx0aGV3YXkuY29tL3JlbW92ZS8iPmNsaWNrIGhlcmU8L2E+DQp3cWp0bmtxY2pnZmc8YnI+ DQoiV2h5IGFtIEkgaGVyZT8iDQo8L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= From owner-mpls@UU.NET Tue Dec 31 03:28: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 DAA19635 for ; Tue, 31 Dec 2002 03:28:16 -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 QQnvpa14175 for ; Tue, 31 Dec 2002 08:31:18 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 QQnvoz11004; Tue, 31 Dec 2002 08:29:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQnvoz00707 for mpls-outgoing; Tue, 31 Dec 2002 08:29: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 QQnvoz00698 for ; Tue, 31 Dec 2002 08:29: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 QQnvoz27175 for ; Tue, 31 Dec 2002 08:28:43 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 QQnvoz22535 for ; Tue, 31 Dec 2002 08:28:43 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 QQnvoz22501 for ; Tue, 31 Dec 2002 08:28:40 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 gBV8Sae23999 for ; Tue, 31 Dec 2002 13:58:37 +0530 (IST) Received: from chn-snr-msg.wipro.com ([10.145.50.99]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 31 Dec 2002 13:58:30 +0530 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="iso-8859-1" Subject: RE: MPLS OAM Date: Tue, 31 Dec 2002 13:58:25 +0530 Message-ID: Thread-Topic: MPLS OAM Thread-Index: AcKwNsdOGBOJzj97S32HIF5jmQRzSAAQ1rGw From: "Deepak Sathyamurthy" To: "Thomas D. Nadeau" , Cc: X-OriginalArrivalTime: 31 Dec 2002 08:28:30.0729 (UTC) FILETIME=[99914790:01C2B0A6] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA19635 -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Tuesday, December 31, 2002 12:38 AM To: curtis@fictitious.org Cc: Deepak Sathyamurthy; mpls@UU.NET Subject: Re: MPLS OAM At 10:33 AM 12/30/2002 -0500, Curtis Villamizar wrote: >In message >, >"Dee >pak Sathyamurthy" writes: > > > > Hi, > > =20 > > There are various proposals for supporting trace route and ping on > > MPLS. = IP ping and trace route use RFC 2925 MIB. Will there be any > > changes, = additions required to this MIB for supporting MPLS ping > > and trace route? =20 Regards, > > Deepak > > >Deepak, > >First of all, not all MIBs that are defined get used in practice. I >know of no ISP that is using the ping MIB to drive pings or collect >information. It is just too inefficient to do things that way. I >don't think any routers implement it. I welcome any corrections. There are actually many of my customers using the standard and Cisco-proprietary version of the Ping MIB. However, as Curtis points out, on a large scale, use of the MIB directly is problematic for performance reasons. This is why many of our customers have moved to using a more automated (proprietary) system called SAA. >The tier one ISPs that I know have been and probably still are using >pings are either doing ad-hoc testing or driving tests from pizza boxes >(1U rackmounts) running *ix that do statistical collection and if >applicable raise alarms by other means. In some cases one way >measurements are made rather than use ping at all. Traceroute is >almost always strictly ad-hoc testing or very customized information >gathering such as the CAIDA skitter program (which doesn't use a MIB). > >If we end up doing an LSP-ping MIB, which too may go unused, then >someone that thinks it will be used can write it. IMHO it can be a >separate document. It can probably be written as a MIB that augments the existing one. ---> Now I wonder if there will be any takers for this as I am hearing that Ping MIB isn't popular with implementers. But what are the reasons for Ping MIB's performance problem? (if at all somebody is attempting to augment it, the info will help in taking care of the issue). --Deepak --Tom From owner-mpls@UU.NET Tue Dec 31 09:20: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 JAA23681 for ; Tue, 31 Dec 2002 09:20: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 QQnvpx13615 for ; Tue, 31 Dec 2002 14:23:12 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 QQnvpx07790; Tue, 31 Dec 2002 14:19:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQnvpx16126 for mpls-outgoing; Tue, 31 Dec 2002 14:19: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 QQnvpx16121 for ; Tue, 31 Dec 2002 14:19:25 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 QQnvpx09357 for ; Tue, 31 Dec 2002 14:18: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 QQnvpx10661 for ; Tue, 31 Dec 2002 14:18:03 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 QQnvpx10646 for ; Tue, 31 Dec 2002 14:18:03 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBVEIe7P009594 for ; Tue, 31 Dec 2002 09:18:40 -0500 (EST) 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 JAA27605 for ; Tue, 31 Dec 2002 09:18:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gBVEI2f23510 for mpls@uu.net; Tue, 31 Dec 2002 09:18: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 QQnvpx16031 for ; Tue, 31 Dec 2002 14:17:21 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 QQnvpx06950 for ; Tue, 31 Dec 2002 14:16: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 QQnvpx10019 for ; Tue, 31 Dec 2002 14:16:54 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 QQnvpx10013 for ; Tue, 31 Dec 2002 14:16:54 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 gBVEHO4i009508; Tue, 31 Dec 2002 09:17:25 -0500 (EST) Received: from tnadeau-w2k.cisco.com (che-vpn-cluster-2-21.cisco.com [10.86.242.21]) by bucket.cisco.com (Mirapoint) with ESMTP id ACI48763; Tue, 31 Dec 2002 09:16:45 -0500 (EST) Message-Id: <5.2.0.9.2.20021231091524.08ec9c90@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 31 Dec 2002 09:16:40 -0500 To: "Deepak Sathyamurthy" From: "Thomas D. Nadeau" Subject: RE: MPLS OAM Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 01:58 PM 12/31/2002 +0530, Deepak Sathyamurthy wrote: >-----Original Message----- >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >Sent: Tuesday, December 31, 2002 12:38 AM >To: curtis@fictitious.org >Cc: Deepak Sathyamurthy; mpls@UU.NET >Subject: Re: MPLS OAM > > >At 10:33 AM 12/30/2002 -0500, Curtis Villamizar wrote: > > >In message > >, > >"Dee > >pak Sathyamurthy" writes: > > > > > > Hi, > > > =20 > > > There are various proposals for supporting trace route and ping on > > > MPLS. = IP ping and trace route use RFC 2925 MIB. Will there be any > > > changes, = additions required to this MIB for supporting MPLS ping > > > and trace route? =20 Regards, > > > Deepak > > > > > >Deepak, > > > >First of all, not all MIBs that are defined get used in practice. I > >know of no ISP that is using the ping MIB to drive pings or collect > >information. It is just too inefficient to do things that way. I > >don't think any routers implement it. I welcome any corrections. > > There are actually many of my customers using the standard and > Cisco-proprietary version of the Ping MIB. However, as Curtis points > out, on a large scale, use of the MIB directly is problematic for > performance reasons. This is why many of our customers have moved to > using a more automated (proprietary) system called SAA. > > >The tier one ISPs that I know have been and probably still are using > >pings are either doing ad-hoc testing or driving tests from pizza boxes > >(1U rackmounts) running *ix that do statistical collection and if > >applicable raise alarms by other means. In some cases one way > >measurements are made rather than use ping at all. Traceroute is > >almost always strictly ad-hoc testing or very customized information > >gathering such as the CAIDA skitter program (which doesn't use a MIB). > > > >If we end up doing an LSP-ping MIB, which too may go unused, then > >someone that thinks it will be used can write it. IMHO it can be a > >separate document. > > It can probably be written as a MIB that augments the existing one. > >---> Now I wonder if there will be any takers for this as I am hearing >that Ping MIB isn't popular with implementers. But what are the reasons >for Ping MIB's performance problem? (if at all somebody is attempting to >augment it, the info will help in taking care of the issue). Lets not put the cart before the horse. I think that we need to focus on the ping mechanism and get it working before we think about managing it. --Tom "The difficult, we do immediately. The impossible takes a little longer." -- Air Force Motto http://www.mkp.com/books_catalog/catalog.asp?ISBN=1-55860-751-X
Conference + Exhibition + = interoperability=20 Testbed

Less than two months before the opening of the MPLS = World=20 Congress 2003 next February 4th, Upper Side is pleased to announce an = important=20 growth of the number of registered delegates. The conference will also = benefit=20 by an extension of the exhibiton room.

MPLS World will = indeed=20 welcome 500 participants who will have the possibility to meet the top = industry=20 players in this area and benefit from the interoperability = platform=20 co-organised by the EANTC, The ETSI and the MPLS Forum.

Above = all, more=20 than 40 key speakers will bring them all the necessary = informations in=20 order to succeed their MPLS network roll-out.

More details at: = http://www.= upperside.fr/mplswc2003/mplswc03intro.htm=20